성능 지표 정의 — Latency·Throughput·Utilization 분석

#한 줄 요약

“Latency·Throughput·Utilization” 세 축으로 성능을 그립니다. 임베디드에서는 jitter·deadline이 추가됩니다.

#3 핵심 지표

#Latency

한 작업이 완료되기까지 걸리는 시간을 의미합니다.

단위는 µs, ms, s입니다. 측정 방식은 single request 시간이거나 분포(p50·p99·max)입니다.

#Throughput

단위 시간당 처리량을 의미합니다.

1
초당 요청 수 (req/s)
2
초당 byte 수 (MB/s, Gbps)
3
초당 프레임 수 (FPS)

단위는 req/s, bytes/s, ops/s입니다.

#Utilization

**자원 사용률(%)**을 의미합니다.

$U_{CPU} = \frac{t_{busy}}{t_{total}}, \quad U_{mem} = \frac{u}{m_{total}}, \quad U_{bus} = \frac{c_{active}}{c_{total}}$

100%에 도달하면 saturation 상태가 되고, queueing이 발생하면서 latency가 증가합니다.

#Latency vs Throughput — 상호 의존

작은 시스템에서는 보통 trade-off거나 직교 관계입니다.

1
초기 (utilization 낮음):  throughput↑ → latency 거의 변화 X
2
중간 (50-70%):           throughput↑ → latency 살짝 증가
3
포화 (90%+):             throughput 한계 → latency 폭증

Queueing Theory (Little’s Law)는 다음과 같습니다.

$L = \lambda \cdot W$

여기서 $L$은 평균 대기 수, $\lambda$는 도착률, $W$는 평균 대기 시간입니다.

자원 utilization이 100%에 근접하면 $W \to \infty$가 됩니다. 그래서 임베디드에서는 80% 한계를 권장합니다.

#Service Time vs Response Time

• Service Time은 실제 처리 시간입니다(queue 제외).
• Response Time은 대기와 처리를 합한 시간이며, 사용자가 체감하는 값입니다.

평균 service time이 좋아도 queue 적체가 일어나면 response time이 폭증합니다.

#임베디드 — Jitter

Latency의 변동성을 의미합니다.

1
주기적 1ms PID task:
2
실제 wake: 1.000, 1.001, 0.998, 1.003, 0.997 ...

$\text{Jitter} = \max - \min = 6\ \mu s$

평균이 양호한데 jitter가 크면 실시간 제어가 불가능합니다. Audio, motor, camera 동기처럼 동기화가 핵심인 영역에서는 치명적입니다.

#Jitter 측정

1
TickType_t xLastWake = xTaskGetTickCount();
2
while (1) {
3
    do_work();
4
    vTaskDelayUntil(&xLastWake, period);
5

6
    uint32_t actual = DWT->CYCCNT;
7
    uint32_t expected = xLastWake * CYCLES_PER_TICK;
8
    log_jitter(actual - expected);
9
}

Histogram을 누적하면서 분포를 분석합니다.

#임베디드 — Deadline

작업이 반드시 끝나야 할 시점을 의미합니다.

Latency 대신 deadline 만족 여부가 metric이 됩니다. 즉, *deadline 안에 들어왔는가? 몇 % 들어왔는가?*를 봅니다.

#Percentile 표기

1
p50 (median)  — 절반은 더 빠름
2
p90           — 10% 케이스만 더 느림
3
p99           — 1% 케이스만 더 느림
4
p999          — 0.1% (1000 중 1)
5
p9999         — 0.01%
6
max           — worst-case

Hard real-time은 max ≤ deadline을 요구합니다. Soft는 p99·p999 ≤ deadline이면 됩니다.

#Long Tail

Histogram:

• ▓▓▓▓▓▓▓▓
• ▓ ▓▓▓▓▓▓▓▓▓
• ▓ ▓ ▓▓▓▓▓▓▓▓▓ ▓ ▓ ▓ ← long tail
• 1 10 100 1000 ms

평균 10 ms, p99 100 ms, max 1 s인 분포입니다. 사용자 체감을 결정하는 것은 long tail입니다.

원인으로는 cache miss, GC, context switch, bus contention이 있습니다. RAS(Reliability·Availability·Serviceability) 도구로 추적합니다.

#Saturation 측정

80%를 넘으면 exponential하게 증가합니다. 그래서 70-80%가 안전 한계입니다.

#임베디드 추가 지표

#IPC (Instructions Per Cycle)

PMU CPU_CYCLES와 INST_RETIRED의 ratio입니다.

1
IPC = 0.5  — 스트레스 (memory bound, stall)
2
IPC = 1.0  — 정상
3
IPC = 2.0+ — 슈퍼스칼라 활용

IPC가 낮으면 왜 낮은지 분석합니다. 원인은 cache miss, branch mispredict, stall 등입니다.

#Cache Hit Rate

1
double hit_rate = 1.0 - (cache_miss / cache_access);

L1은 보통 95-99%, L2는 80-95%, L3는 60-80%입니다. *임베디드(1-2 KB L1)*에서는 작은 working set을 가정합니다.

#MIPS / DMIPS

옛 단위입니다. MIPS는 millions of instructions per second입니다. DMIPS는 Dhrystone MIPS 벤치마크입니다.

1
Cortex-M0+ @ 50 MHz: 45 DMIPS
2
Cortex-M4 @ 168 MHz: 350 DMIPS
3
Cortex-A53 @ 1.5 GHz: 3500 DMIPS

DMIPS는 아주 거친 비교에만 적합합니다. 더 정밀하게 비교하려면 CoreMark나 EEMBC를 씁니다.

#CoreMark

비영리 EEMBC가 만든 임베디드 표준 벤치입니다. Standardized integer workload를 측정합니다.

1
Cortex-M0+ @ 50 MHz:  100 CoreMark
2
Cortex-M4F @ 168 MHz: 850 CoreMark
3
RISC-V SiFive E31:     150 CoreMark

CoreMark/MHz가 효율(architecture 능력)을 비교하는 지표입니다.

#측정 — Time Source

#Latency 분포 측정 예

1
#define BUCKETS 64
2
static uint32_t hist[BUCKETS];
3
static uint32_t max_val = 0;
4

5
void log_latency_us(uint32_t us) {
6
    int idx;
7
    // log2 bucket
8
    if (us < 1) idx = 0;
9
    else if (us < 4096) idx = 32 - __clz(us);
10
    else idx = BUCKETS - 1;
11
    hist[idx]++;
12
    if (us > max_val) max_val = us;
13
}
14

15
// 주기적 출력
16
void print_hist(void) {
17
    for (int i = 0; i < BUCKETS; i++)
18
        if (hist[i]) printf("%d-%d us: %u\n", 1<<i, (1<<(i+1))-1, hist[i]);
19
    printf("max: %u us\n", max_val);
20
}

#자주 하는 실수

⚠️ 평균만 보고 OK 판정

Median이 좋아도 long tail은 보이지 않습니다. 항상 p99·max를 함께 봅니다.

⚠️ Utilization 90%+ 목표

Queueing latency가 폭증합니다. 70-80%가 한계입니다.

⚠️ Tick rate으로 µs 측정 시도

1 kHz tick으로 µs latency를 측정하면 0 또는 1 ms로만 보입니다. 이때는 DWT 또는 hw timer를 씁니다.

⚠️ Throughput만 최적화

Throughput을 2배 빠르게 했는데 p99 latency가 3배 느려지면 사용자에게는 오히려 느려진 셈입니다. Trade-off를 인지해야 합니다.

#정리

• 3 핵심 지표는 Latency, Throughput, Utilization입니다.
• 임베디드에서는 Jitter와 Deadline이 추가됩니다.
• Service time과 Response time은 다릅니다(queueing 영향).
• Percentile과 max로 long tail을 추적합니다.
• Utilization은 70-80%가 한계이며, 그 위에서는 queueing이 폭발합니다.
• IPC와 CoreMark가 아키텍처 효율을 비교합니다.

다음 편은 측정의 기본입니다. wall-clock, CPU cycle, instruction count를 다룹니다.

#관련 항목

• 1-01: 성능 분석 방법론
• 1-03: 측정의 기본
• 1-04: 통계적 분석