TIL

Chapter 05. 마이크로벤치마킹과 통계

• JVM은 자유분방한 특성 탓에 성능 수치를 다루기가 만만치 않다.
• 작은 자바 코드 한 조각의 성능을 정확히 측정(마이크로벤치마킹)하기란 매우 어려운 일이다.

5.1 자바 성능 측정 기초

• 우리의 목표는 벤치마크로 공정한 테스트를 하는 것
  • 시스템의 한 곳만 변경하고 다른 외부 요인은 통제하는 것이 이상적
• 자바 플랫폼은 벤치마크할 때 자바 런타임의 정교함이 가장 큰 문제
  • JIT 컴파일러, 메모리 관리, 그 외 자바 런타임이 제공하는 서브시스템과 완전히 떼어놓고 생각할 수 없다.
  • OS, 하드웨어, 런타임 조건(부하 등)의 작용 또한 무시할 수 없다.

100,000개 숫자 정렬하는 벤치마크 코드 예제

public class ClassicSort {

	private static final int N = 1000;
	private static final int I = 150000;
	private static final List<Integer> testData = new ArrayList<>();

	public static void main(String[] args) {
		Random randomGenerator = new Random();
		for (int i = 0; i < N; i++) {
			testData.add(randomGenerator.nextInt(Integer.MAX_VALUE));
		}

		double startTime = System.nanoTime();
		
		for (int i = 0; i < I; i++) {
			List<Integer> copy = new ArrayList<>(testData)
			Collections.sort(copy);
		}

		double endTime = System.nanoTime();
		double timePerOperation = ((endTime - startTime) / (1000000000L * I));
		System.out.pringln("결과: " + (1 / timePerOperation) + " op/s");
	}
}

• 무작위 정수 배열 생성 후 벤치마크 시작 시간 로깅
• JVM 웜업을 고려해야한다.
  • JIT 컴파일러가 런타임에 인터프리티드 바이트코드를 최적화된 기계어로 변환
  • 벤치마크 도중 JVM이 메서드 호출을 최적화하느라 시간을 보냄
  • 따라서 성능을 캡쳐할 때도 JVM이 가동 준비를 마칠 수 있게 웜업 기간을 두는 게 좋다. (세부 캡쳐 하지 않은 상태로 대상 코드를 여러 번 반복 실행)
• GC를 고려해야 한다.
  • GC가 안일어나게 설정하고 가동하면 좋겠지만 GC는 불확정적
  • GC가 일어날 가능성이 큰 시기에는 타이밍을 캡쳐하지 않는 게 그나마 최선
  • 시행착오를 반복해 최적의 시점을 찾아야 한다.
• 테스트하려는 코드에서 생서된 결과를 실제로 사용해야 한다.
  • 위 코드에서 copy는 사실상 죽은 코드이기에 JIT 컴파일러가 우리가 벤치마크하려던 것을 최적화해버릴 수도 있다.
• 한 번 측정한 결과로는 평균을 내도 벤치마크가 어떻게 수행됐는지 전체 사정을 알 길이 없다.
  • 허용 오차를 구해 수집한 값의 신뢰도를 파악하는 것이 필요
  • 허용 오차가 큰 것은 통제 불능 변수가 있거나 개발된 코드 자체가 성능 기준에 미치지 못함을 의미
• 코드 복잡도가 높아지면(가령 멀티스레드 코드) 벤치마크는 더 까다로워진다.
• 하드웨어 설정치를 가볍게 웃돌 가능성도 있기에 하드웨어 역시 잘 살펴야 한다.
• 해결 방안
  • 시스템 전체를 벤치마크하여 저수준 수치는 무시한다.
  • 연관된 저수준 결과를 의미 있게 비교하기 위해 앞서 언급한 많은 문제를 공통 프레임워크를 이용해 처리

5.2 JMH 소개

5.2.1 될 수 있으면 마이크로벤치마크하지 말지어다

• 자바 성능 문제에서 개발자는 큰 그림을 못 보고 자기 코드가 성능을 떨어뜨렸을 거란 강박에 사로잡히는 경우가 많다.
• 작은 코드를 세세히 뜯어보는 수준으로 벤치마킹하는 건 몹시 어렵고 ‘베어 트랩’에 빠질 위험도 있다.

5.2.2 휴리스틱: 마이크로벤치마킹은 언제 하나?

• 작은 자바 코드 조각보다 자바 애플리케이션 전체를 대상으로 성능 분석을 하는 편이 항상 더 수월하다.
• 코드 조각 하나를 직접 분석해야 하는 경우
  • 사용 범위가 넓은 범용 라이브러리 코드를 개발할 때
  • OpenJDK 또는 다른 자바 플랫폼 구현체를 개발할 때
  • 지연에 극도로 민감한 코드를 개발할 때
• 일반적으로 마이크로벤치마크는 가장 극단적인 애플리케이션에 한하여 사용하는 것이 좋다.
  • 총 코드 경로 실행 시간이 적어도 1밀리초, 실제로는 100마이크로초 보다 짧아야 한다.
  • 메모리 할당률을 측정하는데 그 값은 1MB/s 미만 가급적 0에 가까워야 한다.
  • 100%에 가깝게 CPU를 사용하여 시스템 이용률은 낮게 (10% 미만) 유지해야 한다.
  • 실행 프로파일러로 CPU를 소비하는 메서드들의 분포를 이해해야 한다. 분포 그래프에서 지배적인 영향을 끼치는 메서드는 많아야 두세 개 정도다.

5.2.3 JMH 프레임워크

JMH는 자바를 비롯해 JVM을 타깃으로 하는 언어로 작성된 나노/마이크로/밀리/매크로 벤치마크를 제작, 실행, 분석하는 자바 도구다.

• 벤치마크 프레임워크는 컴파일 타임에 벤치마크 내용을 알 수 없기에 동적이어야 한다.
  • 리플렉션을 사용해도 되지만 그러면 벤치마크 실행 경로에 JVM 서브시스템이 하나 더 끼어들게 된다.
  • JMH는 벤치마크 코드에 애너테이션을 붙여 자바 소스를 추가 생성하는 식으로 작동한다.
• 벤치마크 프레임워크가 유저 코드를 반복 호출할 경우 루프 최적화를 수행
  • 벤치마크 코드를 실행하는 실제 프로세스가 결과 신뢰도에 영향을 미칠 가능성이 있다.
  • JMH는 벤치마크 코드가 루프 최적화에 걸리지 않을 정도로 반복 횟수를 설정한 루프 안에 감싸 넣는다.

5.2.4 벤치마크 실행

• JMH 설정을 마친 프로젝트에서 실행시킬 벤치마크 메서드에 @Benchmark를 붙인다.

    public class MyBenchmark {
      
    	@Benchmark
    	public void testMethod() {
    		// 코드 스텁
    	}
      
    }
  

  • 벤치마크 실행을 설정하는 매개변수는 명령줄에 넣거나 main() 메서드에 세팅한다.

    public class MyBenchmark {
      
    	public static void main(String[] args) throws RunnerException {
    		Option opt = new OptionBuilder()
    				.include(SortBenchmark.class.getSimpleName())
    				.warnupIterations(100)
    				.mesurementIterations(5).forks(1)
    				.jvmArgs("-server", "-Xms2048m", "-Xmx2048m").build();
      		
    		new Runner(opt).run();
    	}
      
    }
  

  • 명령줄의 매개변수가 우선순위가 더 높기에 main() 메서드에 세팅한 매개변수를 오버라이드한다.
• @State로 상태를 제어하는 기능도 제공한다.
  • Benchmark, Group, Thread의 세 상태가 있는 Scope enum을 받는다.
  • @State를 붙인 객체는 벤치마크 도중 엑세스할 수 있어 어떤 설정을 하는 용도로 쓸 수 있다.
• JMH는 벤치마크 코드가 JVM 런타임 최적화의 영향을 최소화하기 위해 블랙홀을 사용한다.
  • 런타임에 죽은 코드를 제거하는 최적화를 못하게 한다.
    • 일반적으로 JVM은 코드가 부수 효과를 일으키지 않으면서 결과를 사용하지 않으면 해당 메서드를 삭제하지만 JMH는 이를 방지하기 위해 결과값을 암묵적으로 블랙홀에 할당한다.
  • 반복되는 계산을 상수 폴딩하지 않게 만든다.
    • 상수 폴딩: 컴파일러가 컴파일 타임에 미리 계산 가능한 표현식을 상수로 바꾸어 처리하는 최적화 과정
  • 값을 읽거나 쓰는 행위가 현재 캐시 라인에 영향을 끼치는 잘못된 공유 현상 방지
  • 쓰기 장벽으로부터 보호한다.
    • ‘장벽’이란 리소스 포화로 인한 병목을 초래하는 지점을 가리키는데 쓰기 장벽에 이르면 캐시에 영향을 미치고 쓰기 전용 버퍼가 오염될 수 있다.

5.3 JVM 성능 통계

모든 측정은 오차를 수반하며 자바 성능 분석 시 흔히 맞딱뜨리는 주요 오차 유형이 있다.

5.3.1 오차 유형

• 랜덤 오차 (random error)
  • 측정 오차 또는 무관계 요인이 어떤 상관관계 없이 결과에 영향을 미침
  • ‘정밀도’ - 랜덤 오차를 나타내는 용어로 높으면 랜덤 오차가 낮은 것
  • 원인을 알 수 없거나 예기치 못한 운영 환경 때문에 발생하는 경우가 많다.
• 계통 오차 (systematic error)
  • 원인을 알 수 없는 요인이 상관관계 있는 형태로 측정에 영향을 미침
  • ‘정확도’ - 계통 오차의 수준을 나탄내는 용어로 높으면 계통 오차가 낮은 것
  • ex) 테스트 대상 서버가 런던에 있는데 부하 테스트를 인도에서 해버린 경우 왕복 네트워크 지연 시간이 응답 시간에 포함되어 모든 api 응답 시간이 180밀리초로 일정해져버림. 실제로 서비스가 반응한 시간은 120밀리초에 못미치기 때문에 오차가 발생
• 허위 상관
  • “상관은 인과를 나타내지 않는다.”
  • 두 변수가 비슷하게 움직인다고 해서 이들 사이에 연결고리가 있다고는 볼 수 없다.
  • JVM 성능 분석 영역에서도 그럴싸해 보이는 상관관계만 보고 측정값 간의 인과관계를 넘겨짚지 않도록 조심해야 한다.

5.3.2 비정규 통계학

자바 성능에서 특이점은 곧 느린 트랜잭션과 짜증난 고객

• 고객 상당수가 불만을 제기하는 상황이 아니라면 평균 응답 속도 단축이 목표가 될 일은 거의 없다.
• 현실적으로 이상적인 메서드(또는 트랜잭션) 시간 분포 그래프 (긴 꼬리형 비정규 분포)

• 모든 관련 코드가 이미 JIT 컴파일 돼서 GC 사이클 없는 핫 패스의 존재를 시사
• 최상의 시나리오로서 이보다 빠른 호출은 있을 수 없다.
• 정규 분포와 배치되는 이런 모습 때문에 비정규 분포를 생각하지 않을 수 없다.
• 비정규 분포로 나타나는 자바 성능 측정 값을 시각화하여 파악하고 싶을 때 HdrHistogram이 유용하다.

5.4 통계치 해석

• 웹 애플리케이션 응답 유형마다 응답 시간 분포는 다르다.

• 클라이언트 오류

  

  • 매핑되지 않은 URL로 클라이언트가 요청하면 서버는 곧장 404를 응답

• 서버 오류

  

  • 서버 에러는 장시간 요청을 처리하다가 발생
  • 리소스가 장시간 부하를 받거나 타임아웃

• 성공 요청

  

  • 성공 요청은 긴 꼬리형 분포를 보이지만 실제로는 극댓값이 여럿인 다봉분포를 나타낸다.

• 전체적인 응답 분포

  

• 이처럼 일반적인 측정값을 보다 유의미한 하위 구성 요소로 분해하는 개념은 아주 유용하다.
  • 결과값으로 결론을 도출하기 전에 데이터 및 도메인을 충분히 이해해야 한다.
  • 데이터를 더 작은 집합으로 쪼개야할 수도 있다.