StyleLab의 여덟 번째 노트: 상품 목록 조회 성능 테스트

카테고리별 상품 목록 조회 API의  성능을 테스트하기 위한 목적입니다.

모든 테스트는 10분 동안 500명의 가상 유저를 사용하여 성능 테스트를 진행하였습니다.

 

목차

1. 2C, 4G single instance
2. 2C, 4G two instance L7 Load Balance
3. 4C, 8G single instance
4. 앞으로 해야 할 일

 

테스트를 위해 사용된 application server, pinpoint server, nGrinder server, L7 Load Balance는 Naver Cloud Platform을 사용하였으며, 코드는 아래 깃헙 링크에서 보실 수 있습니다.

 

https://github.com/rbsks/StyleLab

GitHub - rbsks/StyleLab

 

1. 2C, 4G single instance

 

cpu 사용률

 

pinpoint

아래 사진에서 scatter chart를 보시면 초록색 점들이 골고루 찍혀있는 것을 볼 수 있습니다.

요청에 대한 응답이 빠르다면 대부분의 점들은 맨 밑에 많이 찍히게 됩니다. 이 말은 응답을 늦게 받은 요청들이 많다는 거겠죠.

 

getConnection() 메서드에서 병목현상 발견

아래 Transaction list의 Call tree 사진을 보시면

응답이 느린 요청들을 보시면 대부분 getConnection() 메서드에서 병목현상이 발견되었습니다. 그 외 다른 부분들은 실행 시간이 굉장히 빠른 것을 볼 수 있죠. 이런 병목현상을 로깅을 보고 찾기에는 굉장히 번거로운 작업이 될 수 있기 때문에 성능 테스트를 하기 전에는 꼭 APM을 도입 후 진행하는 것을 추천드리겠습니다.

getConnection() 메서드에서 병목현상 발견

 

nGrinder

 

2. 2C, 4G two instance L7 Load Balance

 

cpu 사용률

 

pinpoint

여기서 드는 의문점은 두 개의 인스턴스가 CPU 사용율도 같고 Round Robin Load Balancing을 사용하여 요청의 비율을 50:50으로 나누었는데 scatter chart가 극심한 차이를 보인다는 것이었습니다. 이 의문점의 원인을 파악하지 못하였지만 지속적으로 성능 테스트를 해보면서 원인 파악을 해보도록 하겠습니다.

 

nGriner

 

3. 4C, 8G single instance

 

cpu 사용률

 

pinpoint

2C, 4G의 인스턴스 보다 CPU 사용률도 낮고 scatter chart의 분포도가 밑으로 많이 내려온 것을 볼 수 있습니다.

 

nGrinder

 

4. 앞으로 해야 할 일

1. Hikari CP에 대한 공부와 서버 자원에 적정 connection pool size에 대해서 분석.
2. tomcat의 thread pool에 대해서 분석.
3. 같은 스펙의 인스턴스에서 scatter chart의 극심한 차이가 나타나는 이유 분석.