응답시간 백분위 계산기

응답시간(레이턴시) 측정값 목록을 붙여 넣으면 개수·최소·최대·평균과 함께 p50·p90·p95·p99 백분위를 즉시 계산합니다. 로드테스트 결과, 액세스 로그의 응답시간 컬럼, APM에서 내보낸 raw 데이터 등 밀리초(ms) 단위 숫자라면 무엇이든 분석할 수 있습니다. 줄바꿈·콤마·공백으로 구분된 값을 그대로 넣으면 됩니다.

평균만 보면 “괜찮아 보이는” 서비스도 p95·p99에서 사용자 체감 지연이 드러나는 경우가 많습니다. 이 응답시간 백분위 계산기로 꼬리 지연(tail latency)을 확인해 SLO 설정과 성능 회귀 판단의 근거로 활용하세요.

백분위 계산 방식 (nearest-rank)

이 도구는 nearest-rank 방식을 사용합니다. 값을 오름차순으로 정렬한 뒤, 백분위 p에 대해 순위 ceil(p / 100 × N) 번째 값을 선택합니다(N은 표본 개수). 구현상 0부터 시작하는 배열 인덱스 ceil(p / 100 × N) - 1에 해당합니다. 보간(interpolation)을 쓰지 않으므로 결과는 항상 실제 측정값 중 하나이며, 모니터링 도구에서 흔히 쓰는 정의와 일치합니다.

예를 들어 100개의 표본에서 p95는 정렬된 값의 95번째(인덱스 94)가 됩니다.

평균보다 p95·p99가 중요한 이유

평균(mean)은 소수의 빠른 응답이 느린 응답을 가려 버립니다. 사용자 한 명의 한 번의 요청이 느리면 그 사용자는 “느리다”고 느끼지만, 평균은 여전히 양호하게 보일 수 있습니다. 백분위는 이 꼬리를 직접 드러냅니다.

• p50(중앙값): 전형적인 사용자가 겪는 응답시간.
• p90 / p95: 상위 10% / 5%의 느린 요청. 일반적인 SLO 기준선.
• p99: 가장 느린 1%. 페이지에 여러 백엔드 호출이 있으면 p99 지연이 누적돼 다수 사용자가 체감합니다.

요청을 여러 번 합성하는 화면일수록 꼬리 지연의 영향이 커집니다. 호출 10개로 구성된 페이지라면 각 호출의 p99가 한 번이라도 걸릴 확률이 높아져, 실제 “느린 화면” 비율은 단일 호출의 p99보다 훨씬 커집니다.

입력 형식과 처리

• 값은 밀리초(ms)로 가정합니다. 줄바꿈·콤마·공백 중 무엇으로 구분해도 됩니다.
• 숫자로 해석되지 않는 토큰(헤더, 단위 문자 등)은 자동으로 무시합니다.
• 소수점과 음이 아닌 값을 지원합니다. 모든 계산은 브라우저 안에서만 수행됩니다.

개별 측정값을 직접 수집하려면 응답시간 측정으로 특정 URL의 응답시간을 잰 뒤, 그 값들을 모아 이 백분위 계산기에 넣어 꼬리 지연을 분석할 수 있습니다.

직접 따라 해 보는 계산 예시

다음 10개의 응답시간(ms)을 넣었다고 가정해 봅시다: 120, 95, 130, 600, 110, 105, 1500, 125, 100, 115. 정렬하면 95, 100, 105, 110, 115, 120, 125, 130, 600, 1500이 됩니다(N = 10).

평균은 300ms로 “느리지만 견딜 만한” 수준처럼 보이지만, p90은 600ms, p95·p99는 1500ms입니다. 표본이 10개뿐이라 p95와 p99가 같은 값(가장 느린 한 건)을 가리킨다는 점에 주목하세요 — 이것이 작은 표본에서 흔히 생기는 함정입니다.

SLO 목표 참고표 (서비스 유형별)

흔한 실수 / 함정

• 백분위를 평균 내지 마세요. 여러 서버나 시간 구간의 p99를 다시 평균(또는 합산)하면 수학적으로 틀린 값이 나옵니다. 백분위는 합산·평균이 불가능합니다 — 정확히 하려면 raw 측정값을 모두 모아 한 번에 다시 계산해야 합니다.
• 표본이 너무 적으면 p99는 의미가 없습니다. 100개 미만의 표본에서 p99는 사실상 “최댓값”과 같아져 한 건의 이상치에 좌우됩니다. p99를 신뢰하려면 최소 수백~수천 건이 필요합니다.
• 단위 혼동. 초 단위(예: 0.12)와 ms 단위(예: 120)를 섞어 넣으면 계산이 무너집니다. 입력 전에 모두 ms로 통일하세요.