deuxksy Knee — 점진 VU 탐색
지표 용어 (혼용 금지): 판정·기록의 처리량은 전부 Req/s (req/s) — 개별 HTTP 요청 기준 (Transaction parent 제외). **TPS (tx/s)**는 업무 루프(Transaction) 완주 수/초로,
TPS = Req/s ÷ 루프당 HTTP 수(JMX 스텝 수)환산값만을 그 라벨로 쓴다. 상세 정의는 run 스킬 '지표 정의' 참조.
부하 발사 원칙 (절대 — spec §3): 부하는 항상 원격 부하원(keco-train-01/02 등 master→workers)에서만 발사한다. 래더의 각 포인트 실행도 run 스킬의 원격 실행 절차를 그대로 따른다. 로컬 jmeter는
-g(jtl→HTML 리포트) 후처리 전용 — 로컬에서 부하를 발사하지 않는다.
인자
jmx, vu_start(기본 2), step_policy(기본 geo2: 2,4,8,16,… / list:10,30,50 형식), ramp(60), duration(120)
보간 래더 재개(중간 VU부터): 남은 포인트만 list:로 지정하고, 판정 기준이 될 직전 포인트 Req/s를 인자와 함께 전달한다 (2026-08-28 실측 — 세션 중단 후 list:16,50,100 재개, 직전 8VU 1,544.9 기준 평탄 판정). 기존 세션의 인접 포인트(예: 1차 캠페인 30VU)도 참조해 교차검증한다.
사이클 (포인트마다 — run 스킬의 실행·집계를 재사용)
- 현재 VU로 run 실행 +
../run/aggregate.py집계 - 아래 판정표로 단일 판정 (첫 매칭 채택)
| 우선순위 | 판정 | 조건 (직전 대비) | 동작 |
|---|---|---|---|
| 1 | 이상 종료 | Err ≥ 5% 또는 절대 p95 ≥ 1s | 즉시 종료 |
| 2 | 이상 종료 | Req/s 하락(>5%) + p95 ≥ 직전 2배 | 종료 — 직전 피크가 MAX Req/s |
| 3 | 이상 재시 | Err 1~5% (1회만) | 동일 VU 재실행, 재발 시 종료 |
| 4 | 평탄 | Req/s ±5% 이내 (하락 5% ~ 상승 5%) | 확인 2포인트 추가 후 종료 (잔여 스텝 생략) |
| 5 | 진행 | Req/s +5% 초과 + Err < 1% + p95 < 1s | 다음 스텝 |
상승 구간(5)에서는 p95 배수 미적용. 첫 포인트(직전 없음)는 무조건 진행.
계열별 예외·공백 보완 (2026-08-29 도그푸드 확정):
- 4-x 계열(vLLM): 응답시간이 본래 초 단위라 판정 1의 "절대 p95 ≥ 1s"와 판정 5의 "p95 < 1s"를 모두 적용하지 않는다 — 진행·종료 모두 Req/s 추세 + Err + p95 배수(판정 2)로만 판정한다 (2026-08-30 2-Way 검증 반영 v1.17.6 — 판정 5만 남으면 Req/s 상승+p95≥1s 포인트가 어떤 판정에도 매칭되지 않는 dead state였음).
- **하락 >5% + p95 <직전 2배 (판정표 공백)**: 1포인트 더 실행해 추세를 확인한다 — 연속 하락이면 직전 피크를 MAX Req/s로 종료, 회복·상승이면 변동으로 보고 진행한다 (5-3 사례: 4VU 150.7 -> 6VU 133.6 -> 8VU 122.6 연속 하락으로 종료).
- 평탄 후 이분탐색 knee 수렴 (2026-08-29 3-4 도그푸드): 판정 4 평탄을 만나면 상방 확인보다 MAX 후보 피크와 직전 포인트의 중간 VU를 먼저 실행한다 — 피크가 두 포인트 사이에 숨어 있을 수 있다 (실측: 32VU가 피크로 보였으나 중간 24VU에서 실제 피크가 더 높았음). 이후 인접 측정 간 Req/s 차이가 ±5% 이내가 될 때까지 이분탐색으로 수렴한다: 보간 결과가 기존 후보보다 ±5% 초과로 높으면 새 후보로 삼고 그 아래(직전 포인트와의 중간)를, 낮으면 후보 유지하고 그 위(후보와의 중간)를 실행한다. ±5% 이내 플래토 또는 상하 인접점이 모두 낮은 극대 확인 시 종료 (실측 수렴: 32 → 24 → 20, 3런으로 24VU 확정).
- 평탄 확인 상방 생략 (2026-08-29 3-4 도그푸드): 평탄 확인 1점(±2% 이내) + p95가 VU 비례 상승 추세면 상방 2점째 확인은 생략 가능하다 — 유지·하락이 예측 가능하므로. 생략 시 summary에 생략 사유를 기록한다. 하락 가속(판정 2 소급)이 의심되면 실행한다.
포인트 집계 호출 (run 스킬이 만든 결과 폴더 대상, 로컬 수집본):
python3 ../run/aggregate.py results/<OUT>/result.jtl <ramp>
런 간 드레인 게이트 (다음 포인트 전)
최소 120s 대기 + 잔여 확인 — sum(rate(nginx_ingress_controller_requests[1m])) < 1, hikaricp_connections_pending == 0 (인스턴트), 4-x 계열 후 vllm:num_requests_waiting == 0. 미통과 시 30s 간격 재확인(최대 10회 후 경고하고 진행). 쿼리 창구는 jmeter.json metrics.
curl -s "<metrics_url>/api/v1/query" --data-urlencode 'query=sum(rate(nginx_ingress_controller_requests[1m]))'
curl -s "<metrics_url>/api/v1/query" --data-urlencode 'query=hikaricp_connections_pending'
curl -s "<metrics_url>/api/v1/query" --data-urlencode 'query=vllm:num_requests_waiting' # 4-x 계열 후
# metrics URL이 로컬에서 직접 닿지 않으면 부하원 ssh 경유:
ssh <master> "curl -s '<metrics_url>/api/v1/query' --data-urlencode 'query=...'"
산출
VU-Req/s 곡선 표 + knee(VU)·MAX Req/s 판정 + 각 포인트 summary.md 누적(run이 처리). 종료 시 MAX TPS (tx/s) = MAX Req/s ÷ 루프당 HTTP 수(JMX 스텝 수)를 함께 기록한다 — 지표 정의(Throughput·Transaction·Request)는 run 스킬 참조, "TPS" 라벨에 req/s 값 병기 금지