[JAVA] 성능 최적화 측정 방법: 벤치마크와 프로파일링

성능 최적화 측정 방법: 벤치마크와 프로파일링

개요

성능 개선은 숫자로 증명하지 않으면 효과를 판단하기 어렵습니다. 특히 지연 시간과 처리량이 동시에 변할 수 있어, 한쪽 지표만 보는 방식은 위험할 수 있습니다. 이 글은 성능 최적화 측정 방법을 기준으로 벤치마크 설계와 프로파일링 흐름을 정리합니다. 변경전/변경후 코드로 측정 차이를 확인하고, 지표 해석 기준을 함께 제공합니다.

---

벤치마크 중심 성능 최적화 측정 방법

벤치마크는 동일 조건에서 성능을 비교하기 위한 도구입니다. 핵심은 입력, 워밍업, 반복 횟수를 고정해 재현성을 확보하는 것입니다. 간단한 측정이라도 변경전/변경후의 조건이 조금만 달라지면 비교가 무의미해집니다. 따라서 벤치마크를 할 때는 시간 측정 방식과 입력 크기, 반복 횟수를 명확히 기록하는 편이 좋습니다. 관련한 파이프라인 설계는 텍스트 처리 파이프라인 설계에서도 참고할 수 있습니다.

다음 예시는 동일한 작업에 대해 변경전/변경후 측정 기준을 통일하는 흐름을 보여줍니다.

// 간단한 벤치마크 비교 예시
// 변경전: 워밍업 없이 단일 측정
long start1 = System.nanoTime();
for (int i = 0; i < 1_000_000; i++) {
    sum += i;
}
long elapsed1 = System.nanoTime() - start1;
System.out.println(elapsed1);

// 변경후: 워밍업 + 반복 측정
for (int w = 0; w < 3; w++) {
    for (int i = 0; i < 1_000_000; i++) sum += i; // 워밍업
}
long total = 0;
for (int r = 0; r < 5; r++) {
    long start2 = System.nanoTime();
    for (int i = 0; i < 1_000_000; i++) sum += i;
    total += System.nanoTime() - start2;
}
System.out.println(total / 5);

Output:

1245321
812345

 

벤치마크는 지연 시간과 처리량을 함께 기록해야 해석이 안정됩니다.

---

프로파일링 기반 성능 최적화 측정 방법

자바 프로파일링은 시간과 자원이 어디에서 소비되는지 확인하는 과정입니다. 측정 결과가 나쁜 이유를 찾아야 다음 개선 단계가 의미를 갖습니다. 예를 들어 GC 시간이 늘어났는지, 특정 메서드가 반복 호출되는지, IO 대기가 증가했는지 확인해야 합니다. 그래서 프로파일링은 벤치마크 결과와 함께 사용해야 정확한 원인을 추정할 수 있습니다. 검색 품질 개선 흐름은 검색 품질 개선 전략에서도 유사한 접근을 다룹니다.

GC 시간이 늘어났는지 확인하려면 로그와 지표를 함께 봅니다. 예를 들어 -Xlog:gc(JDK 9+) 로그에서 Pause 시간 합계를 비교하거나, JFR(Java Flight Recorder)에서 GC Pause와 GC CPU 지표를 확인합니다. 같은 부하에서 변경전/변경후의 GC 총 시간, GC 빈도, 최대 Pause가 증가했는지 비교하면 원인 추정이 쉬워집니다.

Pause 시간은 GC가 애플리케이션 스레드를 멈추고 메모리를 정리하는 동안의 정지 시간을 의미합니다. JVM은 각 GC 이벤트마다 정지 구간을 측정해 로그로 남기며, 이 값은 지연 시간의 꼬리(p95/p99)를 악화시키는 주요 원인이 됩니다. 측정은 GC 로그에 기록된 각 이벤트의 Pause 값을 합산하거나, JFR에서 이벤트 단위의 GC Pause를 집계하는 방식으로 수행합니다.

샘플 데이터(동일 부하, 10분):

구분	GC 총 시간(ms)	GC 빈도(회)	최대 Pause(ms)
변경전	4,200	180	220
변경후	6,800	260	480

이 경우 GC 총 시간과 최대 Pause가 증가해, 지연 시간 꼬리가 늘어날 가능성이 커집니다.

아래 예시는 단순 로그 기반으로 핫스팟을 찾는 변경전/변경후 흐름입니다.

// 간단한 프로파일링 로그 예시
// 변경전: 전체 작업 시간만 기록
long start = System.currentTimeMillis();
processAll();
System.out.println(System.currentTimeMillis() - start);

// 변경후: 단계별 시간을 분리 기록
long t1 = System.currentTimeMillis();
loadData();
long t2 = System.currentTimeMillis();
transformData();
long t3 = System.currentTimeMillis();
saveData();
long t4 = System.currentTimeMillis();
System.out.println("load=" + (t2 - t1) + ", transform=" + (t3 - t2) + ", save=" + (t4 - t3));

 

Output:

1820
load=300, transform=1200, save=320

 

핵심은 병목을 구간별로 분리해 개선 우선순위를 잡는 것입니다.

---

지연 시간과 처리량 해석 기준

지연 시간은 단일 요청의 응답 시간을 의미하고, 처리량은 단위 시간당 처리 가능한 요청 수를 의미합니다. 두 지표는 동시에 개선되기보다 트레이드오프가 생기는 경우가 많습니다. 그래서 지연 시간은 p50, p95, p99 같은 분포를 함께 보고, 처리량은 일정한 부하에서 안정적으로 유지되는지 확인하는 방식이 필요합니다. 평가 기준을 고정한 뒤 변경전/변경후를 비교하는 것이 가장 안전합니다. 관련한 정량 지표 설계는 자바 코리안 토크나이저에서 다룬 방식과 결이 비슷합니다.

샘플 데이터(응답 시간, ms):

구분	p50	p95	p99
변경전	120	450	980
변경후	110	320	600

이 예시는 p50은 소폭 개선되지만, p95/p99가 크게 줄어 꼬리 지연이 개선되는 상황을 보여줍니다.

---

맺음말

성능 최적화 측정 방법은 벤치마크로 비교 기준을 만들고, 프로파일링으로 원인을 추적하는 구조에서 효과가 커집니다. 지연 시간과 처리량을 동시에 관리하고, 변경전/변경후 조건을 고정하면 재현 가능한 개선 흐름을 구축할 수 있습니다. 다음 단계로는 자동화된 성능 리그레션 테스트를 추가해 보세요.