<aside> 💡 부하테스트 결과
목표: 200여 명의 부스트캠프 캠퍼 전원이 서비스를 사용하는 데에 문제가 없을지 확인한다.
부하테스트 대상: 부하가 가장 많이 몰릴 것으로 예상되는, 대시보드와 제출 요청을 보내본다.
방법: 웹소켓 연결을 맺고 해당 요청을 보낸다. 가상사용자 수를 늘리며 서버가 감당 가능한 인원이 몇 명인지 확인한다.
결과: 200여 명의 부스트캠퍼 전원이 우리의 서비스를 사용하는 데에 문제가 없다.
한계: 300명이 넘는 인원의 경우 정상적인 서비스 사용에 어려움을 겪을 수 있다.
개선 사항: 일부 부하테스트의 경우 테스트에 실패했다. 다음 부하테스트 때에는 JMeter가 아닌 다른 부하테스트 툴을 사용한다.
대시보드:
200명이 대시보드 웹소켓에 연결해 5초마다 한 번씩 요청을 보내는 것에 대한 응답 처리는 아주 원활하게 되는 것을 확인했다. 응답은 거의 즉시 되었다. (평균 2ms)
DB가 아닌 Redis(메모리)로부터 데이터를 가져오기 때문에, 아주 좋은 성능을 보이는 것으로 추측할 수 있다.
다만, 유저 수가 300명이 넘어가니 일정 비율로 웹소켓 커넥션 오류가 발생했다.
코드 제출(채점):
120명이 0~10초 균등분포 단위로 1회 제출을 했을경우 채점 결과를 받기까지 평균 1.15초가 걸렸고, 최대 11.8초가 걸렸다.
200명이 0~20초 균등분포 단위로 1회 제출을 했을 경우, 채점 결과를 받기까지 평균 1.81초가 걸렸고, 최대 19.82초가 걸렸다.
다만, 200명을 대상으로 테스트를 진행했을 때에는 오류가 발생하는 경우가 꽤 있었다. (아래 문서 참고)
인원 수가 점점 늘어났을 때, 채점 대기 시간은 늘어나지만 채점을 하는 시간 자체에는 아주 큰 변동이 없는데, 우리가 예상한 대로 서버를 다운시키지 않기 위해 제출 요청이 대기 큐에 들어가 대기한 결과이다.
</aside>
처음에, JMeter로 할 수 있는 가장 쉬운 시험인 HTTP 요청을 날려보았다.
사용자 수는 100번, 1초에 1번 요청 날림, 요청 날리는 횟수는 1이다.
다음과 같이 평균 1.9초의 대기시간을 보여주었다.
사람 수를 300명 가까이 늘려보았다.
이 경우 평균 대기 시간이 6.9초까지 늘어났다.
하지만, 이런 극단적인 상황은 많이 없을 것이고, 너무 많은 요청을 날리는 경우에는 nginx에서 요청을 차단하는 기능이 있다고 하여 HTTP 테스트는 여기에서 마쳤다.
그 다음으로는 JMeter의 WebSocket 플러그인을 사용해 대시보드에 사람이 많이 몰렸을 때 성능이 어떻게 될지 알아보았다.
