Apache JMeter로 NGNIX의 로드밸런싱 성능 테스트

https://nginxstore.com/blog/nginx/nginx-%EC%84%B1%EB%8A%A5-%ED%99%95%EC%9E%A5%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%84%A4%EA%B3%84-%EB%B0%A9%EB%B2%95/

NGINX는 Master Process아래 여러 worker와 helper가 있다.

# ps -ef --forest | grep nginx
root     32475     1  0 13:36 ?        00:00:00 nginx: master process /usr/sbin/nginx 
                                                -c /etc/nginx/nginx.conf
nginx    32476 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32477 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32479 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32480 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32481 32475  0 13:36 ?        00:00:00  _ nginx: cache manager process
nginx    32482 32475  0 13:36 ?        00:00:00  _ nginx: cache loader process

나는 이 NGINX의 process와 worker의 효과를 Apache JMeter를 통해서 테스트 해보려고 한다.

- Apache JMeter 설치

brew install jmeter

위 명령어를 통해 JMeter를 설치할 수 있다.

jmeter

위 명령어로 JMeter를 켜주자.

- JMeter 설정

Thread Group 만들기

Test Plan은 테스트를 해볼 계획이라고 생각하면 된다.

우클릭 -> Add -> Threads -> Thread Group을 눌러서 새로운 Thread Group을 생성해준다.

그러면 새로운 스레드 그룹을 만들 수 있는데,

여기에 해당하는 옵션들을 보자.

 

Number of Threads

말 그대로 스레드의 수이다. HTTP요청을 하는 유저의 수라고 생각하면 되겠다.
1000으로 설정하면 1000명의 유저가 HTTP요청을 하는 것이라고 생각하면 된다.

Ramp-up peroid

스레드가 생성되는 시간을 뜻한다.
즉, Number of Threads = 1000, Ramp-up = 10이면
1000명의 유저가 생성되는데 10초가 걸린다.
즉 1초에 100회의 HTTP요청이 일어날 것이다.

나는 Ramp-up을 0으로 접속해서 1000명의 유저가 동시접속하는 테스트를 해볼 것이다.

Loop Count

반복 횟수이다.
한 스레드가 해당 작업을 반복할 횟수를 뜻한다.
Number of Threads = 1000, Loop Count =10 이면 총 10000번 요청이 생성된다.

 

HTTP Request 만들기

이제 만들었던 Thread Group 우클릭 -> Add -> Sampler -> HTTP Request를 눌러서 Request 설정을 해주자.

여기다가 HTTP 요청을 테스트할 Request 설정을 적어넣으면 되겠다.

 

 

Listener 만들기

이제 HTTP 요청을 통해 만들어지는 결과를 분석할 자료를 보기 위해 Listner를 만들어줘야한다.

원하는 결과에 따라서 선택하면 된다(여러개를 만들 수 있다).

이제 모든 준비는 완료됐다. Start버튼을 누르면 테스트를 해볼 수 있다.

테스트 하기전에 이전 기록들을 지우고 테스트 하자.

 

 

 

- 성능 테스트

Settings

CPU : AWS t2.medium - 2 vCPU
Framework : Django
Protocol : uWSGI

Request:

총 10000명의 유저가 html, js, css파일 세 개를 받는다고 가정해서 Loop Count를 3으로 정했다.
모든 유저가 동시 접속을 한다.

 

 

 

case 1.

[NGINX]
worker_processes : 1
worker_connections : 1024

[uWSGI]
processes : 5

 

- 결과

무려 32%, 약 1/3이 Error를 받은 것을 볼 수 있다. Error 로그는 Socket Closed였다.

동시 접속이 가능한 수를 초과했기 때문에 소켓이 닫힌 것이다.

유저가 많이 몰리는 초반, 응답 시간이 약 3000ms(3초)대인 것을 볼 수 있다.

초반 유저가 처리된 이후로는 1000ms(1초)이내를 머물다가 안정화된 모습을 볼 수 있다.

 

 

 

case 2.

[NGINX]
worker_processes : 2
worker_connections : 1024

[uWSGI]
processes : 5

 

process를 하나 더 늘렸다.

- 결과

Error가 32% -> 28%로 조금 줄어든 모습을 볼 수 있다.

효과가 그렇게 많이 달라지진 않았다. 오히려 응답시간이 늘어나긴 했지만, 비슷하다고 보면 될 것 같다.

case 3.

[NGINX]
worker_processes : 2
worker_connections : 4000

[uWSGI]
processes : 5

worker를 4000으로 늘렸다.

 

- 결과

Error가 약 13%로 나왔다. 많이 줄어든 것을 볼 수 있다.

응답 속도가 1600ms(약 1.6초) 정도에 최대를 찍었지만, 응답 속도가 많이 좋아진 것을 볼 수 있다.

case 4.

[NGINX]
worker_processes : 2
worker_connections : 4000

[uWSGI]
processes : 10

uwsgi의 process를 늘렸다.

 

- 결과

 

Error가 많이 줄었다.

응답 시간은 전과 비슷했다.

 

 

 

- 결과

 

표로 정리해보면 대략 이렇다.

	[NGINX] processes : 1 connections : 1024 [uWSGI] processes : 5	[NGINX] processes : 2 connections : 1024 [uWSGI] processes : 5	[NGINX] processes : 2 connections : 4000 [uWSGI] processes : 5	[NGINX] processes : 2 connections : 4000 [uWSGI] processes : 10
Error (%)	32	28	12	3
Max Response Time	3.2s	4.8s	1.4s	1.7s

 

여기서 눈여겨 볼 것이 있다.

 

1. NGINX의 process가 1 -> 2로 늘어났음에도 왜 Error나 Response Time이 눈에 띄게 개선되지 않았을까?

 

 

NGINX process는 모든 request를 비동기로 처리한다.

 

따라서, worker의 개수가 하나여도 서버는 최대한의 성능을 사용하여 처리한다.

 

worker의 개수를 늘리는 것이 성능 향상에 효과가 없다.

 

2. NGINX의 connections가 1024 -> 4000으로 늘어날 때 성능이 향상됐다.

 

connections는 동시에 접속 가능한 connection의 수를 뜻한다.

 

따라서, 최대 연결 수는 다음과 같다.

Max Connections = worker_processes * worker_connections

 

이로써 process가 늘어나도 성능이 향상되지 않았고,

connections가 늘어났음에 따라 최대 connection이 늘어났으므로, 동시 접속에 대한 요구량 충족이 많아졌기 때문에 성능이 향상된 것으로 볼 수 있다.