의미있는 성능테스트

개요

성능테스트를 진행하면 어떤 환경에서 진행하는 게 의미 있을까?

그리고 각 용어는 어떤 것을 의미하고 어떤 값으로 세팅하는 게 적절할까?

성능테스트의 병목지점은 어떻게 확인할 수 있을까?

 

1000명의 vUser를 세팅하고, 3000명의 vUser를 세팅하는 등 성능테스트를 진행해 보았지만 몇 명의 vUser가 적절한지 그리고 local환경에서 진행하는 것과 aws 환경에서 진행하는 것의 차이 등에 대해 알아보는 시간을 가지려고 합니다.

 

성능 테스트 무엇이 목적일까?

https://nesoy.github.io/articles/2018-08/Testing-Performance

서버는 갑자기 사용자가 많아지면 점점 느려지고, 제대로 동작하지 않을 수 있습니다.

 

성능 테스트를 위해 이를 방지하기 위해 아래와 같은것들을 파악합니다.

API의 성능을 측정하고 병목지점이 발생한다면 이를 파악 및 튜닝

CPU 사용률, 메모리 사용률, 네트워크 지연 등과 같은 병목 현상 및 리소스 사용량 확인

최악의 상황에서는 어떤 동작을 하는가

 

성능테스트와 환경구성

성능테스트를 수행할 때 Local 환경에서 IDE로 프로그램을 기동 하고, nGrinder 또한 docker로 띄워서 테스트하곤 했습니다.

 

하지만 이렇게 되면 하나의 환경에 2개의 프로세스가 구동하기 때문에 vUser 스레드등을 다르게 설정하는 경우에 어떤 것 때문에 영향을 받는지 정확하게 측정하기 어렵습니다.

 

예를 들어 vUser를 100으로 수행했을 때와 1000으로 수행했을 때의 Local에서 사용하는 CPU와 메모리가 다를 수 있습니다.

그러면 자연스럽게 IDE 프로그램에 할당되는 CPU와 메모리가 제한되면서 정확한 테스트가 어려울 수 있습니다.

 

이에 따라 하나의 환경은 AWS로 관리하는 것이 좋을 것 같습니다.

 

용어 정리

Concurrent User: 잠재적으로 언제든지 부하를 줄 수 있는 사용지

Active User: 실질적으로 부하를 주고 있는 사용자

vUser: 동시에 접속하는 가상 사용자의 수입니다.  (Thread의 수)

Think Time: 하나의 요청에 응답을 수신하고 다음요청을 보낼 때까지 시간

Latency: 요청을 보낸 후 데이터를 받기 시작할 때까지 시간

Response Time/ Load Time: 요청을 보낸 후 응답이 완료되어 사용자 화면에 출력될 때까지의 시간

Ramp-up Period: 목표하는 Thread 생성까지 걸리는 시간

Throughput: 단위 시간당 대상서버등에서 처리되는 요청의 수 (Transaction Per Second)

 

vUser는 어느 정도가 적정할까?

가장 많이 하는 질문 중 하나로 "몇 명의 가상 사용자를 시물레이션 해야 하나요?"입니다.

분명한 대답은 "얼마나 많은 사람이 동시세 시스템에 액세스 할 것으로 예상합니까?"입니다.

 

Load Testing Calcuators를 활용할 수 있습니다.

http://www.webperformance.com/library/tutorials/CalculateNumberOfLoadtestUsers/

Load Testing Calculators - How Many Virtual Users Do I Need? - Web Performance

 

예를 들어 가장 바쁜 시간대의 웹사이트 순 방문자 수(hour)와 평균 방문 시간(minutes)을 입력하면 필요한 가상 사용자 수를 추정할 수 있습니다.

 

20000명(한 시간), 평균 방문 시간: 3분(minutes)으로 설정 시 1000명의 vUser가 적절하다고 나옵니다.

다만 선착순 이벤트를 진행한다면 실제 동시에 접근할 수 있는 유저정도로 테스트해야 할 것 같습니다.

 

nGrinder를 예시로 1,000개의 스레드라면 1,000명의 가상사용자가 동시에 접근하는 것을 의미합니다.

2 Core와 6G 메모리로 2대의 agent machines가 존재한다면 10,000 vUser를 사용할 수 있습니다.

단, system.conf 파일의 agent.max.vuser를 5,000으로 수정해주어야 합니다 (기본 세팅 3,000)

 

process와 Thread 설정

에이전트의 메모리가 4GB 미만인 경우 프로세스가 10개 이상이면 메모리 스왑에 의한 쓰래싱이 발생하기 쉽습니다.

10개 미만으로 설정하는 것이 좋고 스레드 수를 200개 이상으로 늘리면 이 문제가 발생할 수 있습니다.

 

 

다음글로는 테스트를 수행하고 병목지점을 찾는 방법을 기록해 보겠습니다.

 

 

참고자료

https://naver.github.io/ngrinder/

nGrinder

https://github.com/naver/ngrinder/wiki/How-to-add-custom-monitor-data

How to add custom monitor data