성능 데이터 통계적 분석 — Percentile·Histogram·평균의 함정

#한 줄 요약

**“평균은 거짓말”**입니다. Latency 분포는 long tail을 가지므로, p99와 max가 진실에 가깝습니다.

#평균의 함정

1
Latency 측정 100회:
2
99회: 10 ms
3
 1회: 1000 ms
4

5
Average: (99 × 10 + 1 × 1000) / 100 = 19.9 ms
6
Median (p50): 10 ms
7
Max: 1000 ms

평균 20 ms만 보고 OK라고 판단하면, 1% 사용자가 1초를 기다린다는 사실을 놓칩니다. Real-time 시스템이라면 곧바로 fail입니다.

#Percentile — 분포의 점

Web service는 p99를 보장합니다. Real-time system은 max를 보장합니다.

#Histogram

분포를 시각화합니다. bucket 개수 × 카운트 형태로 표현합니다.

1
< 1 ms:    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓ (140)
2
1-2 ms:    ▓▓▓▓▓▓▓▓ (80)
3
2-5 ms:    ▓▓ (20)
4
5-10 ms:   ▓ (10)
5
10-50 ms:  ▓ (5)
6
> 50 ms:   ▓ (3)        ← long tail

평균은 보이지 않지만 분포는 눈으로 즉시 식별할 수 있습니다. Mode, skew, outlier가 모두 한눈에 들어옵니다.

#HdrHistogram — 정밀 분포

HdrHistogram은 Gil Tene이 Azul Systems에서 만든 도구입니다. Logarithmic bucket과 configurable precision을 제공합니다.

1
#include "hdr_histogram.h"
2

3
struct hdr_histogram *h;
4
hdr_init(1, 60 * 1000 * 1000, 3, &h);  // 1µs~60s, 3 significant digits
5

6
hdr_record_value(h, latency_us);
7

8
// 결과
9
int64_t p99 = hdr_value_at_percentile(h, 99.0);
10
int64_t p999 = hdr_value_at_percentile(h, 99.9);
11
int64_t max = hdr_max(h);

1 µs~60 s 범위에 3 자리 정밀도를 가지면서, 메모리는 수십 KB만 씁니다. Web과 database benchmark의 표준입니다.

#임베디드 — Fixed-Bucket Histogram

HdrHistogram이 너무 크면 고정 64-128 bucket log2 분포를 쓰면 됩니다.

1
#define BUCKETS 64
2
static uint32_t hist[BUCKETS];
3

4
void record(uint32_t us) {
5
    int idx;
6
    if (us == 0) idx = 0;
7
    else if (us >= (1u << (BUCKETS - 1))) idx = BUCKETS - 1;
8
    else idx = 32 - __clz(us);
9
    hist[idx]++;
10
}
11

12
void print(void) {
13
    for (int i = 0; i < BUCKETS; i++)
14
        if (hist[i]) printf("%d-%d us: %u\n", 1<<i, (1<<(i+1))-1, hist[i]);
15
}

64 bucket × 4 byte = 256 byte입니다. 임베디드에서도 충분합니다. p99와 max는 bucket을 누적해서 계산합니다.

#통계 지표 — 본질

Real-time에서는 max에 신경 써야 합니다. Mean과 stdev는 정규분포를 가정하지만, latency는 비대칭 long-tail이라 적합하지 않습니다.

#Outlier — 무시할까 분석할까

1
99회: 10 ms (정상)
2
 1회: 1000 ms (outlier)

1초 outlier의 원인이 cache miss나 context switch라면, 이는 시스템 자체의 특성입니다. random noise가 아니라 systematic인 현상입니다.

그래서 outlier 분석이야말로 핵심 가치입니다. 평균만 보면 해결해야 할 진짜 문제를 못 봅니다.

#Coordinated Omission

Gil Tene의 유명한 글입니다. Load generator가 측정 도중 멈추면 measurement 자체가 누락됩니다.

시스템이 1초 freeze:

• 그 동안 도착할 요청들이 측정 누락
• 측정 latency는 얼토당토 적게
• 실제 user latency는 훨씬 더 큼

해결책은 coordinated omission correction입니다. HdrHistogram에 내장 지원이 있습니다.

#Long Tail 원인 분류

각 원인은 다른 분포 패턴을 보입니다. histogram으로 시그니처를 식별할 수 있습니다.

#Sample Size

1
N=10:   잡음 큼, 결론 X
2
N=100:  대략적 분포
3
N=1000: 신뢰할 만
4
N=10000: 정밀
5
N=100000+: production grade

p99를 신뢰하려면 최소 N=1000 이상이 필요합니다(1% 케이스를 추정해야 하기 때문입니다).

#Box Plot

5-number summary를 시각화합니다. 여러 측정을 비교할 때 좋습니다.

#Latency vs Sustained Load

1
for (load = 10%; load <= 100%; load += 10%) {
2
    run_with_load(load);
3
    measure_p99(load);
4
}

Latency curve의 knee 지점이 capacity 한계입니다. 보통 80% 근처입니다.

#자주 하는 실수

⚠️ 평균만 보고 결정

위에서 본 것처럼 p99와 max가 필수입니다.

⚠️ N 너무 적음

10개 sample로 p99를 추정하면 noise만 남습니다. 최소 1000개가 필요합니다.

⚠️ Histogram bucket 너무 적거나 많음

10 bucket이면 정밀도가 부족하고, 1000 bucket이면 메모리가 과합니다. log2 기반 64-128이 sweet spot입니다.

⚠️ Stationarity 가정

시스템 부하가 변동하는 동안에는 전구간 평균이 의미가 없습니다. 시간대별로 분리해서 봅니다.

#정리

• 평균은 사용자 경험과 다릅니다. p99·p999·max가 진실에 가깝습니다.
• Histogram과 percentile이 분포 분석의 정석입니다.
• HdrHistogram은 web과 DB의 표준이며, 임베디드에서는 log2 64-bucket으로도 충분합니다.
• Coordinated omission이 흔한 측정 함정입니다.
• Long tail의 원인은 cache, context switch, bus contention, GC 등입니다.

다음 편은 실시간 성능 분석입니다. WCET와 jitter, deadline miss를 다룹니다.

#관련 항목

• 1-03: 측정의 기본
• 1-05: 실시간 성능 분석
• HdrHistogram