[자바 최적화] 성능과 최적화

자바 최적화 책 정리

자바 최적화(Optimizing Java) | 벤저민 J. 에번스 - 교보문고

 

자바 성능: 잘못된 방법

✅ 잘못된 조언

한동안 구글에서 'Java Performance Tuning'이라 검색하면 97 ~ 98년에 작성된 글 3개가 상위권을 차지했다.

그러나, 이들은 지금은 더 이상 안 맞는, 심지어 애플리케이션에 악영향을 끼칠 만한 내용으로 가득 차 있다.

ex)

자바 초창기에 메서드 디스패치(어떤 메소드를 호출할 것인가를 결정하는 과정) 성능은 최악이었다.

-> 따라서, 메서드를 잘게 나누지 말고 하나의 덩치 큰 메서드로 작성하는게 좋다는 의견이 있었다.

그러나, 최신 JVM의 가상 디스패치 성능은 엄청나게 좋아졌고, 자동 인라이닝 덕분에 가상 디스패치조차 점점 사라지게 되었다.

-> '모든 코드를 한 메서드에 욱여넣어라'는 현대 JIT 컴파일러와는 어울리지 않는다.

 

✅ 책의 방향성

이 책은 코드에 바로 써먹을 수 있는 성능 팁을 나열하는 것이 아닌,

우수한 성능 목표를 달성하기 위해 필요한 여러 가지 단면을 보고, 책 끝부분에 코드 수준의 테크닉을 소개한다.

 

---

 

자바 성능 개요

✅ 자바는 블루 칼라(주로 생산직에 종사하는 육체 노동자) 언어

자바 창시자인 '제임스 고슬링'이 한 말이다. 즉, 자바는 일을 하려고 만든 언어라는 것이다.

자바는 처음부터 지극히 실용적인 언어였다.

-> 개발 생산성이 높아지는 대가로 어느 정도의 성능 희생은 감수할 만하다는 입장이다.

-> 자바 환경이 고성능 컴퓨팅 애플리케이션에 적합한 수준에 이른 건 비교적 최근에 핫스팟 같은 정교한 JVM이 성숙했기 때문이다.

 

✅ 서브시스템

실용성을 추구하는 자바 플랫폼의 성격은 서브 시스템에서 드러난다.

ex) 메모리 관리

가비지 수집 서브시스템으로 메모리를 자동 관리하는 덕분에 프로그래머는 메모리를 의식할 필요 없지만,

이는 시스템 입장에서 런타임 동작에 복잡도를 유발한다.

 

---

 

성능은 실험과학이다

✅ 실험과학?

JVM 성능 튜닝의 목표는 시스템 소유자/유저가 추구하는 측정 결과를 얻는 것이다.

-> 즉, 원하는 결과를 얻기 위한 일종의 실험과학이라고 볼 수 있다.

 

---

 

성능 분류

기본적인 성능 지표를 소개한다.

대다수 성능 프로젝트에서 아래 소개하는 모든 지표가 동시에 최적화되는 경우는 거의 없다.

 

처리율

✅ throughput

시스템이 수행 가능한 작업 비율을 나타낸 지표.

ex. 초당 처리 가능한 트랜잭션 수

 

지연

✅ latency

1초에 100리터를 흘려보내는 수도관의 처리율은 100리터라면, 지연은 수도관 자체의 길이에 해당한다. (시간)

 

용량

✅ capacity

시스템이 동시 처리 가능한 작업 단위(트랜잭션) 개수.

 

사용률

✅ utilization

시스템 리소스를 효율적으로 활용하는 것.

ex) CPU 리소스를 놀게 하는 것이 아닌, 실제 작업 단위를 처리하는 데 사용할 수록 사용률이 높다.

 

효율

✅ efficiency

처리율 / 사용률

 

확장성

✅ scalability

리소스를 투입한 만큼 처리율이 변경되는 형태.

ex) 서버 클러스터를 2배로 늘렸을 때, 트랜잭션 처리량도 2배 늘었다면 -> '완벽한 선형 확장'

 

저하

✅ degradation

시스템이 많은 부하를 받는데, 풀 가동된 상태라 처리율은 늘어나지 않아, 지연이 증가하는 양상.

 

측정값 사이의 연관 관계

다양한 성능 측정값은 어떤 식으로든 서로 연결돼 있다. 또, 시스템이 풀 가동 중인지 여부에 따라 달라진다.

-> 시스템에 상당한 부하가 걸려 있는 상태면 부하가 조금만 늘어도 다른 측정값이 크게 요동칠 수 있다.

ex) 핫스팟 JIT 컴파일러

• 부하가 적을 때, 인터프리티드 모드
• 부하가 많을 때, JIT 컴파일 대상 -> 오히려 더 빨라질 수 있다.

 

---

 

성능 그래프 읽기

✅ 성능 엘보

다음은 부하가 증가하면서, 예기치 않게 지연이 발생한 그래프이다.

이런 형태를 보통 성능 엘보라고 한다.

 

성능 엘보

 

 

✅ 준-선형적 확장

이와 반대로, 클러스터에 장비를 추가함에 따라, 거의 선형적으로 처리율이 확장되는 운이 아주 좋은 케이스

ex) 세션 어피니티(세션 고정)가 필요 없는 무상태(stateless) 프로토콜을 확장하는 경우

 

✅ 확장성 제약

암달의 법칙: 프로세서를 아무리 병렬화 시켜도 더 이상 성능이 향상되지 않는 한계가 존재한다는 법칙

 

그 이유는 아무리 높은 비율로 병렬화를 해도, 순차 비율이 조금이라도 있으면 선형 확장은 처음부터 불가능하기 때문이다.

ex) 순차 비율이 (겨우) 5%인 알고리즘도 12배 시간을 단축하려면 프로세서가 32개나 필요하다.