JMeter를 이용한 성능 측정 - JMeter 설정, 결과 분석
진행중인 프로젝트에서 GPT와 Qdrant API를 호출해 응답을 받는 API가 생각보다 시간이 걸렸다.
6초, 7초 정도 걸린다면 적당할 것 같다고 생각했는데 기존 코드로는 타이머로 측정해보니 9~10초정도 걸린것 같다.
이렇게 동시 접속자 수와 사용자의 반복 횟수 등을 설정해 측정할 수 있는 툴을 찾다 JMeter의 장점이 좋아 사용하고자 한다.
이번 글은 JMeter 초기 설정과 성능 측정한 결과를 어떻게 분석할지에 대해 다뤄 보겠다.
1. JMeter 사용법
JMeter를 선택한 계기부터 말하면 좋을 것 같다.
여러가지 이유가 있었지만,
우선 JMeter는 오픈소스 기반으로 무료로 사용 가능하며 GUI로 손쉽게 테스트 시나리오를 작성할 수 있다는 것이 매력적이었다.
또한 여러 스레드를 사용해 동시 접속 테스트를 쉽게 설정 할 수 있고 다양한 타이머와 리스너를 통해 성능 데이터를 실시간으로 확인가능하다는 것도 필요한 기능이었다.
외부 API 호출을 테스트 하려 했기에 결과만 나오는 것보다 실시간으로 어떤 요청이 실패했는지 확인할 수 있어 좋았다.
그리고 전체 요청 데이터의 성공률과 응답시간, TPS를 시각적으로 제공해 줘서 분석하기 쉬울것 같았다.
JMeter 사용법은 다음과 같다.
1. JMeter GUI 실행
- 터미널에서 jmeter를 입력해 JMeter를 실행한다.
- File → New 클릭해 새로운 테스트 플랜 시작한다.
2. 테스트 플랜 구성
테스트 플랜 추가
- Test Plan 우클릭 → Add → Threads (Users) → Thread Group
- Thread Group 설정
- Name: Generate Questions API Test
- Number of Threads (users): 50 (동시 접속 사용자 수)
- Ramp-Up Period (in seconds): 60 (사용자 수만큼 초간격 증가)
- Loop Count: 5 (각 사용자가 5번 반복)
- Spcifiy Thread lifetime: 체크
- Duration (seconds): 300 (5분)
HTTP 요청 기본 설정
- Thread Group 우클릭 → Add → Config Element → HTTP Request Defaults
- 기본 설정
- Server Name or IP: devinterview.shop
- Port Number: 443 (HTTPS)
- Protocol: https
- Path: /api/test/generate-questions
- Content Encoding: UTF-8
HTTP Header Manager 추가
- Thread Group 우클릭 -> Add -> Config Element -> HTTP Header Manager
- 헤더 설정:
- Content-Type: application/json
- Authorization: Bearer {JWT 토큰}
HTTP Request 샘플러 추가
- Thread Group 우클릭 -> Add -> Sampler -> HTTP Request
- HTTP Request 설정:
- Name: Generate Questions API Test
- Server Name or IP: devinterview.shop
- Port Number: 443
- Protocol: https
- Method: POST
- Path: /api/test/generate-questions
- Body Data 설정:
- Body Data 탭 클릭
- JSON 데이터 입력
{
"content": "Performance testing sample",
"userId": "550e8400-e29b-41d4-a716-446655440000"
}
3. 성능 모니터링 요소 추가
- View Results Tree 추가
- Thread Group 우클릭 -> Add -> Listener -> View Results Tree
- 요청과 응답 상태를 실시간으로 확인할 수 있음
- Aggregate Report 추가
- Thread Group 우클릭 -> Add -> Listener -> Aggregate Report
- 평균 응답 시간, TPS, 에러율 등을 통계로 확인
4. 테스트 결과 분석 포인트
- Throughput (TPS): 초당 요청 처리 수 (0.5 이상이면 안정적)
- Average Response Time: 7초 이내면 무난
- Error %: 1% 미만으로 유지
- Max Response Time: 10초 이내면 안정적
모든 준비를 마쳤다면 JMeter 상단의 초록색 시작 버튼을 클릭하면된다.
실행 후 View Results Tree를 보면 실시간으로 요청 처리 상태를 확인 할 수 있다.
결과 분석
Aggregate Report를 확인하니 다음과 같이 결과가 나왔다.
| 항목 | 결과 |
| Total Requests | 250 |
| Success Count | 3058 |
| Error Count | 76 |
| Min Response Time | 6834 ms |
| Average Response Time | 7070 ms |
| 90% Line | 7554 ms |
| Max Response Time | 7631 ms |
| TPS (Throughput) | 0.628 |
| Received KB/sec | 2.99 |
| Sent KB/sec | 3.01 |
- 평균응답시간은 7.70초 나왔다.
- 최대 응답 시간은 7.6초 나왔다.
- 총 250건 요청 중 에러수는 76건이 나왔다.
- Throughput(TPS)는 0.628이 나왔다.
결과를 분석해보면,
평균 응답시간은 1초 이하가 적절하다. 하지만 테스트 결과는 7초대가 나와 서비스 지연이 발생하고 있다고 볼 수 있다.
하지만 Postman으로 API를 한번 호출했을때도 7~9초대가 나온다.
즉 요청이 몰려 과부하로 인해 서버 처리 속도가 느려진 것이 아니라 API를 호출해서 응답 받기까지의 시간이 원래 오래 걸리는 것이다.
추후에 API 응답 시간이 왜이렇게 오래 걸리는지에 대한 분석이 필요할 것 같다.
그리고 에러율이 30%나 되는데 대부분의 에러는 Too Many Requests로 Redis Lock 설정으로 인한 오류로 파악된다.
이는 Rate Limit을 증가시키거나 커넥션 풀을 증가해서 에러율을 개선할 계획이다.
마무리
이번엔 JMeter를 사용해 API 호출 테스트를 진행해 보았다.
JMeter는 여러 장점이 있지만 비동기 테스트가 어렵다는 단점이 있어 다음엔 Gatling을 사용해 비동기 테스트를 진행해보려한다.
프로젝트를 개발하며 기능 구현만 해놓았지, 동시 접속자 증가에 따른 에러 처리와 응답 시간 개선 등과 같은 문제는 고려하지 못했었다.
이번 계기로 개선 시킬 수 있는 부분은 전부 시도해보겠다.