실서비스를 준비하는 데 있어서 서버의 성능 테스트는 매우 중요한 부분이다.
(여기서 성능 테스트란 단순히 Performance test 만을 말하지는 않는다. 자세한건 다음을 참조 -
그렇다면 성능 테스트를 어떻게 할 것이고 어떻게 병목현상을 해결하여 개선을 이루어낼 것인가가 관건이며, 이를 위해서는 단순히 코드를 효율적으로 짜는 것 이상의 학습이 필요하다.
"성능" 에 대한 이해와 "테스트" 에 대한 이해, Performance Engineering 에 대한 이해가 모두 필요한 것이다.
그렇다면 먼저 서버의 성능 측정에 앞서 알아두어야할 용어들을 정리해보자.
(1) Response Time : 클라이언트의 요청을 서버에서 처리하여 응답해주는데까지 걸리는 전체 시간을 말한다.
실제 요청이 들어간 시점부터 네트워크를 거치고 비즈니스 로직의 처리가 끝난 후 다시 클라이언트가 응답을 받는 시점까지 걸리는 시간을 말한다.
(2) Think Time : 사용자가 다음 Request 를 보내기 전까지 활동하는 시간을 말한다. 실제 별도의 서버 요청을 하지않고 웹문서를 보거나 컨텐츠를 즐기는 시간을 Think time 으로 분류한다.
첫번째 요청에서 다음 요청을 보낼때까지의 시간이므로 Request Interval 로 부르기도 한다.
(3) Concurrent Users : 말그대로 동시에 서비스를 사용하는 유저를 말한다. 웹서버 / 세션서버 등 서버의 종류에 따라 유저의 행동양식에 대한 분류는 매우 다양해지게 된다.
일반적으로 Concurrent User 는 Active User 와 Inactive User 로 분류한다.
- Active User : 실제 Request 를 보내고 Response 를 대기 혹은 Connection 을 잡고 있는 유저를 말한다.
일반적으로는 Request 에 대해 실제 Transaction 을 발생시키는 유저에 대해 언급한다.
여기서 포함되는 유저들의 목록에는 실제로 서버에서 클라이언트의 요청을 받을 시, Connection Pool 을 모두 가져가는 유저들과, Connection Pool 의 할당을 대기하고 있는 Pending User 들 역시 Active User 에 포함된다는 점이다.
- Inactive User : 실제 Request 를 수행하지 않고 대기중인 유저를 말한다. 서버의 종류에 따라 연결을 유지하고 있는 유저의 경우에도 Inactive User 로 보기도 한다.
웹서버의 경우 대부분의 Inactive User 는 Think time 을 갖는 유저로 간주된다.
(4) Throughput : 서버가 클라이언트에 송신한 데이터량
(5) Vuser : Virtual User - 주로 퍼포먼스 테스트를 위해 만드는 가상 유저
(6) MRT : Mean Response Time 의 약자로 유저들에 대한 평균 응답시간을 말한다.
(7) TPS : Transaction Per Second 의 약자로 주로 서버 성능의 척도가 된다. 초당 트랜잭션 처리 수를 의미한다.
일반적으로 TPS = AU / MRT 라는 공식에 따라 Active User 의 수에 비례하고 유저들에 대한 평균 응답시간(MRTT)에 반비례한다.
(8) Scenario : 테스트를 위한 시나리오를 말한다. 정확한 TPS 측정을 위해서 가장 중요한 부분 중 하나로, 실제 서비스에서 유저가 어느정도 비율로 어떤 API 를 호출할지 예측하는 과정이 필수적이다.
Service Architecture 를 잘 이해하고 있어야됨은 물론이고, 이에 따라 API 호출의 비율과 그에 맞는 튜닝으로 서비스의 질을 향상시켜야 한다.
위의 용어를 이해했으면 다음으로 퍼포먼스 테스트를 위한 프로세스를 정리해보자.
1. 먼저 서비스의 목표와 그를 위한 규모를 측정해야 한다.
2. 서비스 내에서 사용자의 요청 빈도 수를 예측하고, 그에 알맞게 테스트 시나리오를 만든다.
3. 테스트 시나리오에 맞게 다양한 방향으로 테스트를 진행한다.
여기서 테스트는 Stress Test / Performance Test / Load Test 가 복합적으로 진행되어야 한다. 각 테스트별 한계값 임계치를 측정하는 것이 중요하며, 각각의 테스트 결과는 서로에 영향을 미치게 될 것이다.
4. Stress Test / Load Test / Performance Test 를 통해 현재 시스템의 부하 한계치, 퍼포먼스 등이 측정이 되었다면, 모듈별로 분석해서 튜닝하는 작업이 필요하다.
비즈니스 로직 뿐 아니라 Database / Network / Middleware / Infrastructure 등을 모두 튜닝하는 것이 중요하다.
5. 튜닝을 통해 테스트를 다시 수행하며 서비스의 한계치를 다시 측정한다. 목표에 이를 때까지 4~5 과정을 반복한다.
위의 테스트 Process 를 거치면 실제 생각했던것과 다른 상황을 많이 마주치게 된다.
가령, 우리는 응답시간이 큰 변동폭이 없을 것이며, 가용 자원량 만큼 TPS 가 올라갈 것이라 예측하고 한계점을 측정하겠지만, 실제로는 가용자원의 양은 처음에 급격이 증가하되, 어느정도 TPS 이상이 확보되면 일정해지며 응답시간은 TPS 증가에 따라 기하급수적으로 올라가게 된다.
이는 주로, Service architecture 가 Caching 을 하기 때문에 가용자원에 대한 부분을 상당 부분 부담해주기 때문이며, 응답시간의 경우 부하가 쌓이는 만큼 Connection Pool 에서 유저의 요청에 대한 Pending 이 생기기 때문이다.
아직 Performance Engineering 에 대해서는 지식이 짧아 정리하지 못했는데, 계속해서 공부를 해보면서 추가 포스팅 하도록 해야겠다.
(포스팅의 글이 너무 좋아 참조하였습니다.
https://bcho.tistory.com/787, http://www.jidum.com/jidums/view.do?jidumId=562dumId=562)
iLiFO 지덤 :: 테지덤 성능테스트 – Little’s law 포함
I. 성능테스트의 개요와 원리 Little’s law 가. 시스템 테스트의 정의 사용자가 시스템을 사용하기에 성능상 문제가 있는 지를 검증하여 개선하기 위한 테스트 나. 소프트웨어 성능 테스트의 기본 원리 Little’s law ‘공간 내에 머무는 객체 수(L)’는 ‘객체의 공간유입량(λ)’과 ‘객체가 머무는 시간(W)’에 비례한다. 즉 L = λW이다. 시스템의 성능(TPS)는 트랜잭션을 발생시키는 사용자(Active User)를 평균응답시간(Mean
www.jidum.com
성능 엔지니어링 대한 접근 방법 (Performance tuning)
성능 엔지니어링에 대한 접근 방법 조대협 성능 개선, Performance Tuning, 용량 선정 과 같은 튜닝 관련 용어들은 모든 개발자나 엔지니어에게 모두 흥미가 가는 주제일 것이다. 그 만큼 소프트웨어에서 고성능을..
bcho.tistory.com
'Server > Basic' 카테고리의 다른 글
| 동적 컨텐츠(Dynamic Contents)와 정적 컨텐츠(Static Contents) 그리고 캐싱 (0) | 2019.08.28 |
|---|---|
| Scaling 의 종류에 대한 정리 (0) | 2019.06.02 |
| load testing 과 stress testing, performance testing 에 대한 비교 (0) | 2019.05.16 |
| Message Oriented Middleware 및 Message Queue 에 대한 설명 (0) | 2019.03.13 |
| COMET 이란? (0) | 2019.01.23 |