- 모든 성능 문제는 한 가지 정답이 있는 게 아니라 여러 개 정답이 있다. 가능한 해결책을 찾고 그중 요건에 가장 알맞은 해결책을 조합하는게 바로 기술이다.
- 자바 초창기에 메서드 디스패치 성능은 최악이였지만, 최신 자바 가상 머신에서는 자동 인라이닝 덕분에 가상 디스패치조차 대부분의 호출부(콜 사이트)에서 사라지게 됐다.
- 자바는 블루 칼라(주로 생산직에 종사하는 육체 노동자) 언어이다. 박사 학위 논문 주제가 아니라 일을 하려고 만든 언어다. - 제임스 고슬링 -
- 성능 분석은 닭을 해부해보거나 점을 치는 과정이 아니라, 통계치에 근거해 적절히 결과를 처리하는 활동이다.
- 가장 일반적인 기본 성능 지표들: 처리율, 지연, 용량, 사용률, 효율, 확장성, 저하
- 처리율(throughput)
- (서브)시스템이 수행 가능한 작업 비율을 나타낸 지표이다. 보통 일정 시간 동안 완료한 작업 단위 수로 표시한다.(예: 초당 처리 가능한 트랜잭션 수)
- 처리율이 실제 성능을 반영하는 의미 있는 지표가 되려면 수치를 얻은 기준 플랫폼에 대해서도 내용을 기술해야 한다. 그리고 트랜잭션(또는 작업 단위)은 테스트할 때마다 동일해야 한다.
- 처리율을 테스트할 때 실행 간 워크로드(시스템이 주어진 시간 내에 처리해야 할 작업 할당량) 역시 일정하게 유지해야 한다.
- 지연(latency)
- 성능 지표는 수도 배관에 빗대어 설명할 때가 많다. 1초에 100리터를 흘려보내는 수도관의 처리율은 바로 1초에 처리되는 부피(100리터)이다. 이때 지연은 수도관 자체의 길이에 해당한다.
- 즉, 하나의 트랜잭션을 처리하고 그 결과를 반대편 수도관 끝에서 바라볼 대까지 소요된 시간이다.
- 용량(capacity)
- 시스템이 보유한 작업 병렬성의 총량, 즉 시스템이 동시 처리 가능한 작업 단위 개수를 말한다.
- 용량은 처리율과 밀접한 연관이 있어서 시스템에 동시 부하가 증가할수록 처리율(그리고 지연)도 당연히 영향을 받는다.
- 이런 이유로 보통 용량은 어떤 처리율 또는 지연 값을 전제로 가능한 처리량으로 표시한다.
- 사용률(utilization)
- 사용률은 워크로드에 따라서 리소스별로 들쑥날쑥할 수 있다.
- 이를테면, 계산 집약적 워크로드(예: 그래픽 처리, 암호화)를 주면 CPU 사용률은 100%에 육박하지만, 메모리 사용률은 얼마 안 나온다.
- 효율(efficiency)
- 전체 시스템의 효율은 처리율을 리소스 사용률로 나눈 값으로 측정한다.
- 같은 처리율을 더 많은 리소스를 쏟아부어야 달성할 수 있다면 분명 효율이 낮은 것이다.
- 확장성(scalability)
- 리소스 추가에 따른 처리율 변화는 시스템/애플리케이션의 확장성을 가늠하는 척도이다.
- 시스템 확장성은 궁극적으로 정확히 리소스를 투입한 만큼 처리율이 변경되는 형태를 지향한다.
- 보통 시스템 확장성은 하나의 단순한 상수 인자가 아니라, 여러 가지 인자들의 영향을 받는다. 리소스를 어느 정도까지 늘리면 거의 선형적으로 확장되지만, 대부분 부하가 높아지면 완벽한 확장을 저해하는 한계점에 봉착하게 된다.
- 저하(degradation)
- 시스템을 덜 사용하고 있으면 측정값이 느슨하게 변하지만, 시스템이 풀 가동된 상태면 처리율이 더는 늘어나지 않는, 즉 지연이 증가하는 양상을 띄는데 이런 현상을 부하 증가에 따른 저하라고 한다.
- 처리율(throughput)
- 워크로드에 반드시 순차 실행되어야 할 작업 조각이 하나라도 있으면 선형 확장은 처음부터 불가하며 확장 가능한 한계점도 뚜렷하다.