Jmeter 맛보기
자바 플랫폼 성능 분석 도구
🤔 Jmeter?
간단하게 이해하자면 내가 구축한 서버가 어느 정도의 트래픽을 버텨낼 수 있는지 측정할 수 있게 해주는 툴이다.
비슷한 툴로 네이버가 개발한 nGrinder 등이 있다.
내가 이 Jmeter를 검색해서 실행해보게 된 계기는 HikariCP 때문이었다.
회사에서 스프링 부트를 사용하다 보니 DBCP는 HikariCP로 설정돼있었는데,
피크타임에 DB에 병목이 생기는 경우가 종종 있어서 찾아보게 됐다.
이때 HikariCP의 커넥션 풀 사이즈가 200으로 설정돼있었고,
나도 평소에
“풀사이즈? 그거 하드웨어가 허락하는 한 클수록 좋은 거 아니야?”
라는 단순한 생각을 갖고 있었는데,
DB병목 관련 이것저것 찾아보다 HikariCP 문서를 다시 한번 세심하게 보게 됐다.
📜 Documentation
여기서 maximumPoolSize 옵션에 대한 하위 문서를 보고 약간의 충격을 받았다.
내용에 대해 말해보자면, 만 명의 사용자가 DB커넥션을 요청하는 사이트의 경우 대략적으로 20,000 TPS가 발생한다고 한다.
이때 히카리의 커넥션 풀 사이즈가 얼마나 되어야 효율적이냐는 질문에 오히려 얼마나 적어야 효율적인지 물어야 한다고 한다. (엥?🤔)
그러면서 그 이유로 CPU의 멀티쓰레딩에 대해 이야기한다.
하나의 CPU 코어가 수십 또는 수백 개의 쓰레드를 동시에 처리할 수 있다고 하나, 이는 실제로는 CPU가 한번에 처리하는 작업은 쓰레드 하나에 국한되며 단지 이 속도가 말도안되게 빨라 동시에 진행되는 것처럼 보이고, 이렇게 하나의 코어가 여러개의 쓰레드를 처리하는 환경에선 소위 컨텍스트 스위칭이라고 하는 작업이 많이 발생하여 큰 오버헤드가 생기기에 비 효율적이라고 설명하고 있다.
히카리의 풀 사이즈를 결정하는 요소에는 세 가지가 있다.
CPU 코어디스크네트워크
정말 간단하게 디스크와 네트워크를 배제하고 이야기하면,
8코어 CPU를 사용한다고 하면 커넥션 풀 사이즈가 8개일 때 최고의 효율을 발휘한다고 한다.
그 이상 적용하면 컨텍스트 스위칭으로 인해 오히려 성능 저하가 발생하기 시작할 것이라는 설명이다.
다만 디스크와 네트워크를 배제할 수 없기 때문에 히카리의 커넥션 풀 기본 사이즈가 10인 걸로 추정된다.
히카리의 풀 사이즈로 어느 정도의 크기가 적당 하겠느냐에 대해 아래와 같은 공식을 예제로 보여준다.
The calculation of pool size in order to avoid deadlock is a fairly simple resource allocation formula:
pool size = Tnx (Cm\- 1) + 1Where Tn is the maximum number of threads, andCmis the maximum number ofsimultaneous connectionsheld by a single thread. For example, imagine three threads (Tn=3), each of which requires four connections to perform some task (Cm=4). The pool size required to ensure that deadlock is never possible is:
pool size = 3 x (4 - 1) + 1 = 10Another example, you have a maximum of eight threads (Tn=8), each of which requires three connections to perform some task (Cm=3). The pool size required to ensure that deadlock is never possible is:
pool size = 8 x (3 - 1) + 1 = 17
🚀 Test
아무튼 진짜 본론으로 들어가서
이러한 이유들로 인해 풀 사이즈가 어느 정도여야 가장 좋은 효율을 낼 수 있을까?라는 의문으로 시작해
열심히 구글을 뒤지다가 Jmeter를 알게 됐고, 정말 실험 같지도 않은 간단한 실험을 해보게 됐다.
관련 문서를 보고 Jmeter를 설치, 설정하고 테스트를 시작했다.
결과가 정말 놀라운데
실험 컴퓨터 CPU: 6코어QPS: 10,000y축 한 칸: 2,000 TPS파란색: 커넥션 풀 사이즈분홍색: 요청 성공빨간색: 요청 실패
히카리의 기본 세팅인 10에서 가장 좋은 퍼포먼스를 보였고 역시 6코어이기 때문에 디스크와 네트워크 등의 요청으로 인해 커넥션이 부족해 풀사이즈 6에서 많은 실패가 발생했다.
놀라운 부분은 풀사이즈 100에서 미친듯한 요청 실패가 발생했다.
100에서 저러니 200에선 얼마나 더 큰 오버헤드가 발생할 것이며, 어떤 실패들이 발생할지 대략 짐작이 됐다.
아무튼 결론적으로 풀사이즈를 재조정해서 배포했고 나름 효과를 보았던 것 같다.
주니어 개발자고 백오피스를 담당하고 있어서 아직 대용량 트래픽에 맞아본 경험은 없지만, 이런 유용한 도구들이 있다는 배경지식정도는 정말 알아두는게 큰 도움이 된다는 생각이 든다.
나중에 비슷한 문제가 발생하면 관련 키워드를 금방 떠올릴 수 있을것이고, 알맞은 솔루션을 조금 더 빠른 시간내에 도출해 낼 수 있을거란 기대 때문이다.
