성능 분석은 경험주의와 질퍽한 인간 심리학이 교묘히 어우러진 분야

👥 1.1 자바 성능 : 잘못된 방법

• JVM이 발전하면서 과거의 조언이 현재는 무의미한 경우가 많음
• 예) 초창기 메서드 디스패치 성능이 최악이었을 때에 메서드 호출을 줄이라는 조언 → 현재는 자동 인라이닝)
• 성능 팁보다 우수한 성능 목표를 달성하기 위해 여러 가지 단면 집중 조명
  • 전체 소프트웨어 수명주기의 성능 방법론
  • 성능과 연관된 테스트 이론
  • 측정, 통계, 툴링
  • (시스템 + 데이터) 분석 스킬
  • 하부 기술과 메커니즘(장치 수단)

🌹 1.2 자바 성능 개요

• 자바 성능의 본질을 이해하기 위한 자바 창시자의 제임스 고슬링 한마디
  • “자바는 블루칼라(주로 생산직에 종사하는 육체 노동자) 언어입니다. 박사 학위 논문 주제가 아니라 일을 하려고 만든 언어죠”
• 실용성 추구
• 자바 플랫폼의 성격은 여러 방면 드러남
  • 서브시스템이 가장 대표적
  • 개발자가 용량 관리 부담 줄이고
  • 저수준으로 제어 가능한 일부 기능 포기
• JVM 애플리케이션의 성능 측정값은 정규 분포를 따르지 않아서, 기초 통계 기법만으로는 처리 역부족
  • 예) JVM에서의 특이점(아웃라이어) 같은 중요 이벤트가 묻혀버릴 가능성

🌍 1.3 성능은 실험과학이다

• 자바/JVM 소프트웨어 스택 아주 복잡
• 무어의 법칙과 그로 인한 하드웨어 용량의 발전 때문
• JVM도 1990 후반 전에는 최상의 성능을 위해 수준 이상의 스킬 필요
• JVM 성능 튜닝: 기술, 방법론, 정량적 측정값, 툴을 망라한 개념
• 목표: 시스템 유저가 추구하는 측정 결과를 얻는 것
• 다음과 같은 활동으로 결과를 얻는 실험과학
  • 원하는 결과를 정의한다
  • 기존 시스템을 측정한다
  • 요건을 충족시키려면 무슨 일을 해야 할지 정한다
  • 개선 활동을 추진한다
  • 다시 테스트한다
  • 목표가 달성됐는지 판단한다
• 무엇을 측저할지 대상을 확정하고 목표를 기록하는 행위가 중요
• 이런 활동들이 프로젝트 아티팩트(결과물)와 제품 일부 형성

🍣 1.4 성능 분류

• 모든 지표가 동시에 최적화되는 경우는 거의 없음

1.4.1 처리율

• (서브)시스템이 수행 가능한 작업 비율을 나타낸 지표
• 보통 일정 시간 동안 완료한 작업 단위 수로 표시 (TPS)
• 수치를 얻은 기준 플랫폼에 대해서도 기술해야 의미 있음

1.4.2 지연

• 하나의 트랜잭션을 처리하고 그 결과를 반대편 수도관 끝에서 바라볼 때까지 소요 시간 == 종단시간
• 대개 그래프에서 워크로드에 비례하는 함수로 표시
• 수도관 비유: 1초에 100리터를 흘려보내는 수도관
  • 처리율: 100리터
  • 지연: 수도관 자체의 길이

1.4.3 용량

• 시스템이 보유한 작업 병렬성의 총량
• 시스템이 동시 처리 가능한 작업 단위 개수
• 시스템에 동시 부하가 증가할수록 처리율 저하 → 보통 용량은 처리율 또는 지연 값을 전제

1.4.4 사용률

• 시스템 리소스의 효율적 활용
• 워크로드에 따라 리소스별로 상이
  • CPU ↔ 메모리

1.4.5 효율

• 처리율을 리소스 사용률로 나눈 값으로 측정
• 대형 시스템에서는 원가 회계 형태로 측정

1.4.6 확장성

• 리소스 추가에 따른 처리율 변화
• 궁극적으로 리소를 투입한 만큼 처리율이 변경되는 형태 지향 → 완벽한 선형 확장

1.4.7 저하

• 더 많은 부하를 받았을 때, 처리율 및 지연 증가 현상

1.4.8 측정값 사이의 연관 관계

• 다양한 성능 측정값은 서로 연결돼 있음

🥗 1.5 성능 그래프 읽기

• 성능 엘보: 부하가 증가하면서 예기치 않게 저하 발생하는 형태

🍷 1.6 마치며

• 다음 장은 JVM 성능이 복잡한 이유

🦴 출처

• 자바최적화 - 벤저민 J. 에번스 , 제임스 고프 , 크리스 뉴랜드 저자(글) · 이일웅 번역