백분위 지연 시간(p95·p99)

백분위 지연 시간(Percentile latency)은 응답 시간을 평균이 아니라 순위로 표현합니다. p95는 요청의 95%가 그 값 이하로 끝난 시간이며, 가장 느린 5%만 그보다 오래 걸렸다는 뜻입니다. p50은 중앙값으로 일반적인 사용 경험을 나타냅니다. p99와 p99.9는 꼬리(tail), 즉 가장 느린 요청을 나타내며, 사용자가 알아차리고 불만을 제기하는 것은 대개 이런 요청입니다.

백분위수가 평균보다 나은 이유

요청 100개 중 90개는 100 ms, 10개는 2,000 ms가 걸렸다고 합시다.

통계값	값
평균	290 ms
p50(중앙값)	100 ms
p95	2,000 ms
p99	2,000 ms

평균 290 ms는 실제로 일어난 어떤 요청도 설명하지 못합니다. 수용 가능해 보이지만, 실제로는 사용자 열 명 중 한 명이 2초를 기다렸습니다. 백분위수는 두 가지 사실을 모두 보여 줍니다. 대부분의 요청은 빠르고, 꼬리 구간은 매우 느립니다. 또한 평균은 소수의 극단적인 이상값에 크게 흔들리지만 중앙값은 그렇지 않습니다.

꼬리 구간은 생각보다 중요합니다. 페이지 하나를 로드할 때 백엔드 호출이 여러 번 일어나고 사용자 세션 하나에는 여러 번의 페이지 로드가 포함되므로, 방문 중에 p99 수준으로 느린 요청을 적어도 한 번 겪는 사용자의 비율이 상당히 높습니다.

테스트에서 백분위수 사용하기

성능 목표와 게이트는 백분위수로 작성해야 합니다. k6에서는 다음과 같습니다.

export const options = {
  thresholds: {
    http_req_duration: ['p(50)<200', 'p(95)<500', 'p(99)<1500'],
  },
};

여러 백분위수(p50, p95, p99, 최댓값)를 처리량, 오류율과 함께 보고하십시오. 각 지표가 서로 다른 측면을 말해 주기 때문입니다.

흔한 실수

• 백분위수를 평균 내기. 서버 10대의 p95 값을 평균한 값은 전체 p95가 아닙니다. 백분위수는 합친 원시 데이터나 병합 가능한 히스토그램으로 계산해야 합니다.
• 표본이 너무 적음. 요청 200개로 구한 p99는 데이터 포인트 두 개에 기대고 있습니다. 꼬리 구간에 의미 있는 표본이 쌓일 만큼 충분히 오래 실행하십시오.
• 오류 무시. 5 ms 만에 빠르게 실패하는 요청은 지연 시간을 실제보다 좋아 보이게 만듭니다. 지연 시간은 항상 오류율과 함께 읽으십시오.
• 조정된 누락(coordinated omission). 느린 응답을 기다린 뒤에야 다음 요청을 보내는 부하 도구는 성능이 저하되는 동안 요청을 조용히 덜 보내게 되고, 그 결과 꼬리 지연 시간을 과소평가합니다. 도착률 기반(오픈 모델) 부하 생성 방식을 쓰면 이 문제를 줄일 수 있습니다.