저번 글의 말미에서 puma의 worker와 thread의 최적화된 숫자를 찾는 것이 중요하다 말했다.
이번 글에서는 우리 서비스의 puma 설정 파일 튜닝 과정을 공유하고자 한다. 상세한 수치는 빼고 어떤 식으로 진행했는지를 중점으로 이야기해 보겠다.
백그라운드
puma의 default 설정을 그대로 사용하고 있었으므로 single mode에서 5개의 threads가 돌아가고 있었다. 이전 글에서도 말했듯이 1개의 프로세스로는 루비의 GVL로 인해 병렬처리에 한계가 있다.
성능 테스트 툴인 Jmeter를 사용하여 10분간 가상 유저 10명이 지속적으로 request를 보내는 상황을 시뮬레이션 해보았다.
테스트를 시작하고 약 5분 정도 경과한 이후에 htop으로 CPU 현황을 살펴본 결과, 로드를 가하는 상황이었음에도 CPU가 약 60% 정도만 사용되고 있었다.
리소스 사용 최적화를 위해 puma의 설정을 튜닝할 필요가 있다고 판단하여 최적점을 찾기 위해 worker와 thread 수를 변경해가며 테스트를 해보았다.
Jmeter Load Test
jmeter 사용법은 따로 설명하지 않겠다. 구글에 검색해 보길 바란다.
Jmeter 설정값은 위에서 공유한 사진과 동일하다. 또한 우리 서비스에서 가장 중요한 api를 테스트해보았다. 아래 캡쳐화면에서 보듯이 protocol(http인지 https인지)과 서비스 url 혹은 ip 주소를 적어주면 된다.
테스트해본 조합은 아래와 같다.
single mode - 5 threads
single mode - 10 threads
2 workers - 5 threads
2 workers - 7 threads
2 workers - 10 threads
3 workers - 5 threads
3 workers - 7 threads
3 workers - 10 threadsThroughput 추이
Avg response time 추이
분석
single mode와 cluster mode 간에는 현저한 차이가 있지만, cluster mode에서 worker 및 thread 수를 조정한 테스트 결과는 모두 엇비슷하다.
약간의 차이지만 그 중 가장 성능이 좋은 조합은 2wkrs-7thd와 3wkr-7thd 일 때 이다.
thread를 5 → 7 로 증가시키면 더욱 많은 리퀘스트를 처리할 수 있는 것으로 보인다. 하지만 10개로 증가시 2 workers, 3workers의 경우 모두 소폭 감소하게 된다. 즉, GVL로 인한 thread간 경합이 심해지는 포인트가 trhead 10개 지점임을 알 수 있다.
결론
2wkrs-7thd 조합으로 결정했다. 우리 서비스 코드가 메모리 최적화된 상황이 아니기에 3 workers를 사용해가며 메모리에 부담을 주고 싶지 않았기 때문이다.
