⏰💡 JMeter 구성 요소 해석해보기

1️⃣ 내가 만든 JMeter 트리는 무엇을 의미할까?

내 JMeter 구조는 이렇게 해석하면 된다.

가상 사용자 300명이 동시에 접속해서

1. 대기열 등록을 한 번 하고
2. 1초마다 30번 ‘내 순번 조회’를 반복한다.

즉, 실제 사용자 시나리오를 자동으로 재현한 실험이다.

---

2️⃣ JMeter 구성 요소 하나씩 해석하기

✅ HTTP Request Defaults

여기에 설정한 값:

• Protocol: http
• Server: localhost
• Port: 8080

이건 “모든 요청의 기본 서버 주소”를 설정한 것이다.

그래서 개별 요청에서는 경로(Path)만 쓰면 된다:

• /api/lectures/1/queue
• /api/lectures/1/queue/me

✅ 01_enqueue (POST /queue)

이 요청은 “대기열에 줄 서기” 행동을 의미한다.

실제 동작:

• userKey(UUID) 생성
• Redis ZSET에 등록
• position 반환

즉, JMeter의 가상 사용자가
“줄 서기 버튼”을 한 번 누른 상황이다.

✅ JSON Extractor (userKey 추출)

enqueue 응답 예시:

{
  "status": "QUEUED",
  "userKey": "8a55-....",
  "position": 3
}

설정:

• 변수 이름: userKey
• JSON Path: $.userKey

의미:

응답 JSON에서 userKey 값을 추출해서
JMeter 변수 ${userKey}에 저장한다.

왜 필요할까?

다음 폴링 요청에서 “내 상태”를 조회하려면
userKey가 필요하기 때문이다.

즉,

• 01_enqueue에서 userKey를 뽑고
• 02_poll_me에서 그 userKey를 사용한다.

✅ Loop Controller (30)

Loop Count = 30

의미:

한 명의 가상 사용자가 “내 순번 조회”를 30번 반복한다.

✅ 02_poll_me (GET /queue/me)

이건 “폴링” 행동이다.

폴링이란?

기다리는 동안 계속 서버에 물어보는 것
“나 이제 입장 가능해?”
“내 순번 몇 번이야?”

요청 파라미터:

• name: userKey
• value: ${userKey}

즉, 방금 발급받은 userKey로 내 상태를 조회하는 것이다.

✅ Constant Timer (1000ms)

1000ms = 1초

의미:

반복 요청을 연속으로 보내지 않고
1초 간격으로 실행한다.

실제 서비스에서 폴링을 1초마다 하는 것과 동일한 환경이다.

✅ Summary Report / View Results

• View Results in Table → 각 요청 성공/실패 상세
• Summary Report → 평균 응답시간, 최대값, 에러율, 처리량

---

3️⃣ 내가 실제로 무엇을 테스트했는가?

한 문장으로 요약하면:

동시 사용자 300명이
“줄서기 1번 + 1초마다 30번 폴링” 했을 때
서버가 안정적으로 응답하는지 테스트했다.

이것이 바로 “폴링 부하 테스트”다.

---

4️⃣ 테스트 결과 해석

결과 요약

• enqueue: Samples 401, Avg 3ms, Max 11ms, Error 0%
• poll_me: Samples 12003, Avg 1ms, Max 31ms, Error 0%
• TOTAL: Samples 12404, Avg 1ms, Max 31ms, Error 0%

✅ #Samples (총 호출 횟수)

poll_me가 12003번 호출되었다.

 

300명 × 30번 ≈ 9000번이 기본 계산이지만,
Ramp-up, 실행 시간 차이 등으로 조금 늘어날 수 있다.

 

핵심은:

수천~만 단위 요청을 처리했다는 점이다.

✅ Average / Max 응답 시간

• 평균: 1ms
• 최대: 31ms

의미:

요청이 매우 많았는데도
대부분 1ms 수준으로 빠르게 응답했고
최악의 경우도 31ms에 불과했다.

Redis 기반 폴링 구조가
충분히 빠르게 동작한다는 증거다.

✅ Error %

0%

즉, 1만 건 이상의 요청에서도:

• 500 (서버 오류)
• 429 (요청 제한)
• 404 (경로 오류)

등이 전혀 발생하지 않았다.

서버가 안정적으로 동작했다는 의미다.

✅ Throughput (TPS)

TOTAL Throughput ≈ 19~20 req/sec

 

이 수치는 전체 테스트 구간 평균이기 때문에
순간 피크 TPS보다 낮게 나올 수 있다.

 

Ramp-up, Timer, Loop 구조의 영향을 받는다.

 

📌 자소서나 포트폴리오에서는
TPS보다 다음이 더 중요하다:

• Error 0%
• 최대 지연시간 낮음
• 응답시간 안정성

---

5️⃣ 이 테스트가 증명한 것

✅ (1) 폴링 구조가 실제로 동작한다

• enqueue에서 userKey 추출
• 그 userKey로 반복 폴링
• 시나리오 기반 테스트 완료

✅ (2) 동시 사용자 300명 폴링에도 서버는 안정적이다

• Error 0%
• Max 31ms
• 평균 1ms 응답

즉,

“폴링 때문에 서버가 터질까?”라는 우려를 실험으로 검증했다.

---

🔥 최종 결론

선착순 시스템에서 가장 우려했던 부분은
“폴링 트래픽 폭증”이었다.

하지만 JMeter 실험 결과:

• 대량 폴링 요청에서도
• Redis 기반 조회는 매우 빠르고
• 서버는 안정적으로 응답했다.

이 테스트를 통해
설계에 대한 확신을 얻었다.