[Issue] Locust를 사용하여 부하 테스트 진행 후 성능 최적화

명령어 입력

locust -f 파일명.py

 

이후 localhost:8089로 접속

 

첫번째 Number of users: 최종 트래픽을 유발할 유저 - 500명으로 테스트

두번째 Ramp up: 유저가 투입되는 시간 (초단위) - 1초마다 투입

세번째 Host: 테스트를 진행할 메인 uri - 기본 로컬 uri인 localhost:8080로 지정

 

이제 1구역(district_id = 1)에 해당하는 모든 좌석(seat)의 칼럼들을 불러오는 테스트를 수행하겠다.  

테스트 결과

 

 

500명에 도달하니까 districts/1/seats의 GET 요청 응답시간이 15초로 너무 긴 것을 확인할 수 있다.

또한, 처리 requests의 개수는 45190개이고 Max(ms)가 31628, 즉 31초나 걸린다.

성능 최적화를 위해 레코드의 모든 칼럼을 스캔하는 것에서 PK만 스캔하는 것으로 성능 튜닝을 해볼 것이다.

 

이제 1구역(district_id = 1)에 해당하는 모든 좌석(seat)의 pk인 seat_id만 모두 불러오겠다.

 

첫 번째 성능 튜닝 후 테스트 결과

 

 

레코드의 모든 칼럼을 스캔하는 것에서 PK만 스캔하는 것으로 성능 튜닝한 결과이다.

이전에는 응답 시간이 15초였던 것을 2초로 줄였다. 즉, 약 7.5배가 빨라졌다.

처리 requests의 개수는 45190개에서 164339개로 늘었고 Max(ms)가 8461, 즉 아까 31초나 걸렸던 것이 8초로 줄었다.

 

더 빨라지게 하려면 district_id에 인덱스를 걸어주는 식으로도 가능하다.

다음과 같이 seat 테이블에 인덱스를 걸어주자.

 

 

 

옵티마이저의 실행계획으로 idx_district_id 인덱스가 사용이 될 것이라는 것도 잘 확인했다.

 

이제 1구역(district_id = 1)에 해당하는 모든 좌석(seat)의 pk인 seat_id만 모두 불러올 때, districit_id를 인덱스로 스캔하겠다.

 

두 번째 성능 튜닝 후 테스트 결과

 

 

districit_id에 인덱스를 걸어주고 성능 튜닝한 결과이다.

이전에는 평균 최대 응답시간이 3초정도였는데, 이번에는 1.5초이다.

맨 처음에 테스트했던 응답시간은 15초였는데 이젠 1.5초가 되었다. 즉, 약 10배가 빨라졌다.

처리 requests의 개수는 164339개에서 235870개로 늘었고 Max(ms)가 4461ms, 즉 아까 8초나 걸렸던 것이 4초로 줄었다.

맨 처음과 비교해서 처리 request의 개수는 45190개에서 235870개로 늘었고, Max(ms)가 31628ms(31초)에서 4461ms(4초)로 줄었다.

 

 

내 노트북의 cpu 성능은 별로 좋지 않은 것을 감안해도 이정도면 성능 튜닝이 꽤나 성공했다고 볼 수 있을 것 같다.