API 성능 실험
서버 장비는 맥북 M1 RAM 8GB이다. 데스크탑에서 노트북으로 요청을 보냈다. 직접 서비스에 접근하지 않고 API Gateway와 서비스 디스커버리를 통하여 target 서비스를 찾고 request를 처리한다.
초당 10개의 request에서 초당 700개의 request로 점점 request 양을 늘리면서 실험했으며 Mongodb가 동적으로 min connection pool size(default 0)에서 max connection pool size(500으로 setting해서 실험, 그러나 default인 100일 때와 차이가 별로 없음)로 connection pool 크기가 늘어나는 것을 확인할 수 있다. 아래는 해당 시점에 새로운 connection이 순차적으로 늘어나는 것을 확인할 수 있는 로그이다.
노란색 그래프가 active user 그래프인데 어느 순간부터 request 양에 비해 request 처리가 따라가지못해서 active user가 급격하게 늘어나는 것을 볼 수 있다. 그러면서 API가 전부 fail나는 것을 볼 수 있다.
Connection pool이 늘어나면서 살짝 response가 느려졌었다는 것을 그래프로 확인해 볼 수 있다.
Time out이 나기 시작하면서 connection close가 되기전에 계속 다른 thread가 request 시도를 하게되면서 address already in use 에러가 발생한 것으로 추측된다.
Connection pool 외에 timeout 설정과 queue 설정을 튜닝해보지 못했다. 해당 설정들을 튜닝하여 최대 초당 request 수를 늘릴 수 있는지 확인해볼 예정이다.
팀원 코드 분석
JPA Entity에서 @Embeded를 사용하여 1:N 구현 방식을 처음 접했다. 새로운 방식을 배울 수 있어서 좋았다. 1:N 관계를 단순하게 List로만 표현하지 않고 embeded를 사용하여 해당 1:N 관계 자체에 객체 지향적으로 다룰 수 있다는 것을 알게 되었다. 해당 관계 자체에 대해서 객체 지향적으로 처리할 비즈니스 로직이 존재한다면 embeded 객체로 표현하고 해당 로직을 캡슐화하는 것은 좋은 방식일 수 있겠다 생각하게 되었다.
팀원 모듈 API 성능 테스트
MySQL만 연결되어 있는 모듈이다.
실험 환경은 위와 동일하며 많아진 request 에서 팀원의 API도 비슷한 구간에서 같은 원인으로 API fail이 난다.
Reference
https://www.mongodb.com/docs/manual/administration/connection-pool-overview/
https://www.mongodb.com/docs/manual/tutorial/connection-pool-performance-tuning/
