부하테스트
기능은 완성되었고 부하테스트를 진행해보겠다, API를 만들었다면 기본적으로 해야하는 것 중에 하나가 부하테스트 인데 부하테스트는 말 그대로 프로그램에 부하를 줘서 얼마나 퍼티는지 테스트를 하는 것이다.
성능 좋은 API 기준
관련해서 자료를 찾아보니 결론적으로 사용자가 몇 명이든 응답시간이 빠르면 좋다가 결론이었다.
관련 자료를 하단에 소개하겠다.
-
구글 : 3초 이상의 페이지 로딩시간이 걸릴 경우, 53%의 모바일 사용자가 이탈한다.
https://www.thinkwithgoogle.com/consumer-insights/consumer-trends/mobile-site-load-time-statistics/ -
구글 : 0.5초의 추가 페이지 로딩 시간이 20%의 트래픽 손실을 발생시킨다.
http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html -
아마존 : 페이지 로드시간이 100ms 증가 → 1%의 매출 감소
https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales -
월마트 : 페이지 로드 시간이 1초 개선될 때마다 전환율이 2% 증가
https://www.cloudflare.com/ko-kr/learning/performance/more/website-performance-conversion-rates/
이처럼 IT 빅테크 기업들은 서비스의 품질과 응답속도를 위해 목숨을 거는 것도 충분히 이해가 가는 부분이다.
얼마나 빨라야 할까?
클라우드 빅테크 가업중에 하나인 cloudflare는 고객의 47%는 웹페이지가 2초 이내에 로드되기를 기대한다고 의견을 냈다.
https://www.cloudflare.com/ko-kr/learning/performance/more/website-performance-conversion-rates/
그래서 내가 만든 프로젝트는 평균 응답시간을 1000ms 1초 이하로 하는 것으로 잡았다.
성능 테스트
성능테스트에는 다양한 툴이 존재 하는데 JMater, ngrinder, k6등 다양한 툴이 있지만 찾아보니 postman으로도 성능테스트를 할 수 있다는 것을 알게 되었다.
1. 테스트 준비
이번 테스트의 가상유저는 일단 100명으로 잡고 테스트를 진행하고 지연없이 100명의 가상 유저들이 초당으로 요청하는 것으로 하겠다.
2. 테스트 결과
테스트 결과 내가 예상한 것 보다 훨씬 좋게 나왔다.
정리하지면 100명의 가상의 유저가 초당 평균 86.93회 요청을 보냈고 응답시간은 평균
13ms로 상상한 것보다 훨씬 빠르게 응답을 해주었고 에러도 없었다.
앞으로의 계획
현재는 100명 정도는 감당이 가능하다는걸 알았으니 다음목표는 300명이 동시에 접속해도 문제가 없는지 테스트 하고 문제가 없으면 인원을 늘려보고 문제가 있으면 유지보수 하는 것이 앞으로의 목표이다.
(API 주소)
https://url.mlistapi.link/kr/michelin-list?row=100&starCnt=1&year=2024참고 사이트
