응답시간 백분위 계산기

전체 요청의 99%가 그 시간 안에 끝났다는 뜻입니다. p99가 210ms라면 100번 중 99번은 210ms 안에 응답했고 한 번은 더 걸렸다는 의미입니다. 평균은 느린 요청 몇 개에 끌려가거나 반대로 묻혀 버리기 때문에, 사용자가 실제로 겪는 느림을 보려면 백분위를 봐야 합니다.

백분위 계산법이 하나가 아니기 때문입니다. 정렬한 값에서 몇 번째를 고를지 정하는 방식이 여럿이라, "가장 가까운 순위"는 실제로 관측된 값만 내고 "선형 보간"은 이웃한 두 값을 비례로 섞어 관측되지 않은 값을 내기도 합니다. 1부터 100까지의 자료에서 p50이 각각 50과 50.5로 갈립니다. 표본이 적을수록 차이가 큽니다.

꼬리 쪽에 값이 열 개는 들어가야 흔들리지 않는다고 보면 p99에 1,000개, p99.9에 10,000개가 필요합니다. 100개를 재서 p99를 말하면 사실상 가장 느린 값 하나를 말하는 것이라, 그 한 번이 우연히 느렸는지 늘 그런지 구별할 수 없습니다.

화면 하나를 그리는 데 여러 번 부르기 때문입니다. API를 100번 부른다면 그중 하나라도 p99에 걸릴 확률이 1 − 0.99¹⁰⁰ = 63%입니다. 사용자 셋 중 둘이 느림을 겪는다는 뜻이고, 평균만 보고 있으면 절대 드러나지 않습니다. 마이크로서비스를 열 단계 타는 경우에도 9.6%의 요청이 어딘가에서 p99를 밟습니다.

되지 않습니다. 서버마다 요청 수가 다르고, 백분위는 원래 분포에서 다시 계산해야 하는 값이기 때문입니다. 여러 대의 값을 합치려면 히스토그램이나 t-digest 같은 요약 자료구조를 합친 뒤 거기서 백분위를 내야 합니다. 대시보드에서 p99를 평균해 보여주는 그래프는 실제 p99보다 낮게 나옵니다.

각 호출의 느림이 서로 무관하다는 가정 위의 값입니다. 실제로는 서버가 한꺼번에 느려지거나 특정 사용자의 요청만 무거운 경우가 많아, 느림이 이 계산보다 몰려서 나타납니다. 확률의 크기보다는 "호출이 늘수록 꼬리가 빠르게 쌓인다"는 방향을 보시는 것이 맞습니다.

전송되지 않습니다. 모든 계산은 브라우저 안에서만 이루어지고, 넣으신 응답시간은 이 기기를 벗어나지 않습니다.