CH1 성능과 최적화

알아볼 내용

• 경험적 과학, 측정에 관한 기본적인 토픽들
• 성능 활동 수행 시 필요한 기본 용어들과 측정값에 대한 설명
• 성능 테스트를 하며 흔히 볼 수 있는 몇 가지 사례

 

1.1 자바 성능: 잘못된 방법

• 시간이 지나면서 가상 디스패치 성능은 엄청나게 좋아졌고, 특히 최신 JVM에서는 자동 인라이닝(automatic managed inlining) 덕분에 가상 디스패치조차 대부분의 호출부(call site)에서 사라지게 되었음
• 이 책에서는 우수한 성능 목표를 달성하기 위해 필요한 여러 가지 단면을 종합적으로 집중 조명하고자 함
  • 전체 소프트웨어 수명주기의 성능 방법론
  • 성능과 연관된 테스트 이론
  • 측정, 통계, 툴링(tooling)
  • (시스템 + 데이터) 분석 스킬
  • 하부 기술과 메커니즘(mechanism)
• 일반적인 원칙은 다음과 같다.
  • JVM을 더 빨리 작동시키는 '마법의 스위치' 같은 건 없다.
  • 자바를 더 빨리 실행하게 만드는 '팁, 트릭'은 없다.
  • 여러분이 못 보게 꼭꼭 숨겨둔 '비밀 알고리즘' 같은 것도 없다.

 

1.2 자바 성능 개요

• JVM 전반에 걸쳐 등장하는 '관리되는 서브시스템(managed subsystem)'은 그 존재 자체로 JVM 어플리케이션의 런타임 동작에 복잡도(complexity)를 유발함
• JVM 어플리케이션의 성능 측정값은 정규 분포를 따르지 않는 경우가 많아 기초 통계 기법(ex: 표준편차, 분산)만 갖고는 측정 결과를 제대로 처리하기에 역부족임
• 자바 성능 측정값 때문에 판단이 흐려지기 쉬우므로 조심해야 함
• 측정하는 행위 자체도 오버레드(과부하)를 일으키며, 너무 자주 샘플링하거나 매번 결과를 기록하는 것 역시 성능 결과 수치에 적잖은 영향을 끼침

 

1.3 성능은 실험과학이다

• JVM 성능 튜닝은 기술, 방법론, 정량적 측정값, 툴을 망라한 개념이고, 그 목표는 시스템 소유자/유저가 추구하는 측정 결과를 얻는 것
  
  • 즉, 성능은 다음과 같은 활동을 하면서 원하는 결과를 얻기 위한, 일종의 실험과학이라고 볼 수 있음
    • 원하는 결과를 정의한다.
    • 기존 시스템을 측정한다.
    • 요건을 충족시키려면 무슨 일을 해야 할지 정한다.
    • 개선 활동을 추진한다.
    • 다시 테스트한다.
    • 목표가 달성됐는지 판단한다.
• 성능 분석은 비기능 요건을 정의하고 달성하는 활동이고, 통계치에 근거해 적절히 결과를 처리하는 활동임

 

1.4 성능 분류

• 성능 지표란?
  • 성능 분석의 어휘집이자, 튜닝 프로젝트의 목표를 정량적인 단위로 표현한 기준
  • 다음은 가장 일반적인 기본 성능 지표임
    • 처리율, 지연, 용량, 사용률, 효율, 확장성, 저하
  • 알아둘 사항
    • 대다수 성능 프로젝트에서 이 모든 지표가 동시에 최적화되는 경우는 거의 없음 (성능 반복을 통해 많아야 두세 개 지표가 개선되는 정도)
    • 실제로는 어느 한 지표를 최적화하면 다른 지표들이 악화되는 경우도 흔함

 

1.4.1 처리율 (throughput)

• 시스템이 수행 가능한 작업 비율을 나타낸 지표
• 보통 일정 시간 동안 완료한 작업 단위 수로 표시함 (ex: 초당 처리 가능한 트랜잭션 수)
• 처리율이 실제 성능을 반영하는 의미 있는 지표가 되려면 아래 3가지를 유의해야 함
  • 수치를 얻은 기준 플랫폼에 대한 내용을 기술해야 한다.
    • ex: 하드웨어 스펙, OS 및 소프트웨어 스펙, 단일 서버 or 클러스터 환경 등
  • 트랜잭션(또는 작업 단위)은 테스트할 때마다 동일해야 한다.
  • 실행 간 워크로드(시스템이 주어진 시간 내에 처리해야 할 작업 할당량)를 일정하게 유지해야 한다.

 

1.4.2 지연 (latency)

• 하나의 트랜잭션을 처리하고 결과를 응답하기까지 소요된 시간
• 대개 그래프에서 워크로드에 비례하는 함수로 표시함

 

1.4.3 용량 (capacity)

• 시스템이 보유한 작업 병렬성의 총량, 즉 시스템이 동시 처리 가능한 작업 단위(트랜잭션) 개수
• 처리율과 밀접한 연관이 있어 보통 어떤 처리율 또는 지연 값을 전제로 가능한 처리량으로 표시함

 

1.4.4 사용률 (utilization)

• 리소스(ex: CPU, 메모리 등) 사용률

 

1.4.5 효율 (efficiency)

• 전체 시스템의 효율 = (처리율 / 리소스 사용률) 로 측정함
  • 같은 처리율에 대해 더 많은 리소스가 필요하다면 효율이 낮은 것

 

1.4.6 확장성 (scalability)

• 리소스 추가에 따른 처리율 변화는 시스템/어플리케이션의 확장성을 가늠하는 척도임
• 시스템 확장성은 궁극적으로 리소스를 투입한 만큼 처리율이 변경되는 형태를 지향함
  • 보통 시스템 확장성은 하나의 단순한 상수 인자가 아닌, 여러 가지 인자들의 영향을 받음
  • 리소스를 어느 정도까지 늘리면 거의 선형적으로 확장되지만, 대부분 부하가 높아지면 완벽한 확장을 저해하는 한계점에 봉착함

 

1.4.7 저하 (degradation)

• 시스템이 더 많은 부하를 받으면 throughput(처리율) 또는 latency(지연) 측정값에 변화가 생김
• 해당 변화는 시스템 사용률에 따라 다른데, 시스템이 풀 가동된 상태라면 처리율이 더는 늘어나지 않는, 즉 지연이 증가하는 양상을 띔
• 이런 현상을 부하 증가에 따른 저하라고 함

 

1.4.8 측정값 사이의 연관 관계

• 다양한 성능 측정값은 어떤 식으로든 서로 연결돼 있고, 구체적인 상호 관계는 시스템의 풀 가동 여부에 따라 달라짐
• 예시
  • 1) 일반적으로 시스템 부하가 증가하면 사용률도 달라지지만, 시스템을 많이 사용하지 않는 경우에는 부하가 늘어도 사용률은 눈에 띄게 증가하지 않을 수도 있음
  • 2) 확장성을 감안하면 부하가 늘 때 가용 리소스도 함께 늘려야 하는데, 시스템이 이렇게 확장한 리소스를 제대로 활용하지 못할 수도 있음
    • 부하 변화로 인해 시스템 일부가 리소스를 집중적으로 소모하는 고성능 모드로 전환되면, 더 많은 요청이 시스템에 유입돼도 오히려 지연이 감소할 수 있음
  • 3) 핫스팟 JIT 컴파일러
    • JIT 컴파일 대상이 되려면 대상 메서드는 충분히 빈번하게 인터프리티드 모드(interpreted mode)로 실행돼야 함
    • 부하가 많아 메서드 호출 빈도가 증가하면 JIT 컴파일 대상이 되어 동일한 메서드여도 나중에 호출하는 게 처음보다 훨씬 빨리 실행됨
  • 4) 워크로드 종류에 따라서도 달라짐

 

1.5 성능 그래프 읽기

성능 테스트에서 자주 등장하는 패턴을 소개한다.

 

• 부하가 증가하면서 예기치 않게 저하(지연)가 발생한 그래프
• 이런 형태를 보통 '성능 엘보' 라고 함

 

• 위와 반대로 위의 그래프는 클러스터에 장비를 추가함에 따라 거의 선형적으로 처리율이 확장되는 좋은 케이스를 나타냄
• 이렇게 이상적인 모습에 가까운 결과는 환경이 극단적으로 순조로울 때(ex: 서버 하나에 세션 고정이 필요없는, 무상태 프로토콜을 확장하는 경우) 가능함

 

• 암달의 법칙이란?
  • 프로그램은 병렬처리가 가능한 부분과 불가능한 순차적인 부분으로 구성되므로 프로세스를 아무리 병렬화 시켜도 더 이상 성능이 향상되지 않는 한계가 존재한다는 법칙
• 위의 그래프는 태스크를 처리할 때 프로세서 개수를 늘려도 실행 속도를 최대 어느 정도까지 높일 수 있는지를 나타냄