[ 자바성능튜닝교육 회고 ]
월요일(20171030), 화요일(20171031) 이틀간 회사내에서 '자바성능튜닝’에 대한 교육을 6시간에 걸쳐 수강하였다.
교육도 들었겠다 관련해서 간단히 들었던 내용과 생각을 정리해보려한다.
먼저 성능을 튜닝하기 위해서는 무작정 '튜닝할거야' 라고 달려드는게 아니다.
첫 번째로 튜닝을 하고자 하는 어플리케이션의 어떤 부분에서 병목이 발생하고 있는지 살펴볼 필요가 있다.
어떤 부분에서 병목이 발생하는지 발견했다면 튜닝을 하기전 요청에 대한 response time을 철저하게 체크하고 확인해보자.
추후 효율적으로 튜닝이 되었는지 확인을 위한 필수적인 부분이다.
일반적인 어플리케이션에서 병목이 발생하는 부분은 대부분 DB관련된 부분일 확률이 높다.
성능 튜닝에 있어서 기본은 throughput(처리량), response time(응답시간)이 척도가 될 수 있다.
먼저 throughput(처리량)의 경우 특정한 시간내에 얼마나 많은 transaction을 처리할 수 있느냐가 중요하다.
처리량은 보통 TPS, TPM, TPH로 표시한다.
TPS = Transaction Per Seconds
TPM = Transaction Per Minutes
TPH = Transaction Per Hours
3,600 TPH = 60 TPM = 1 TPS
일반적으로는 TPS를 가장 많이 사용하고 TPS는 높으면 높을 수록 좋다.
반면에 요청에 대한 response time(응답시간)은 당연히 짧으면 짧을 수록 좋다고 할 수 있다.
만약 성능측정툴(scouter, jmap, jvh)등을 통해서 어플리케이션 내부를 튜닝할 경우에는 실제로
cpu를 가장 많이 사용하는 모듈(메소드, 라이브러리)을 확인하고 코드 개선이 필요하다.
응답시간을 가장 많이 잡아먹는 메소드를 먼저 선행 튜닝하도록 하자.
다음과 같은 경우는 당연히 a 메서드에 대한 튜닝을 진행하는게 어플리케이션 전체 효율을 높이는데 효과적일 것이다.
또한 어플리케이션 개발 초기에 특정 프레임워크를 사용할 경우 먼저 선행 성능 측정이 필요하다.
만약 어플리케이션의 특정 프레임워크의 버전을 올려 배포해야 하는 상황이라면 기능 개선 작업과 함께
배포하여 테스트하는 것은 지양하는 것이 좋다. 실제로 문제가 발생했을 때 프레임워크 버전업으로 인한 문제인지
추가된 로직들에 의한 문제인지 확인이 힘들기 때문이다.
만약 간단하게 서버에 떠있는 자바 인스턴스에 대한 모니터링이 필요하다면 jvmtop 을 사용하는 것을 추천한다.
생각보다 손쉽게 해당 인스턴스의 CPU점유 및 쓰레드, 내부에서 동작하고 있는 메서드들에 대한 정보를 확인할 수 있다.
https://github.com/patric-r/jvmtop
JvmTop 0.8.0 alpha amd64 8 cpus, Linux 2.6.32-27, load avg 0.12
https://github.com/patric-r/jvmtop
PID MAIN-CLASS HPCUR HPMAX NHCUR NHMAX CPU GC VM USERNAME #T DL
3370 rapperSimpleApp 165m 455m 109m 176m 0.12% 0.00% S6U37 web 21
11272 ver.resin.Resin [ERROR: Could not attach to VM]
27338 WatchdogManager 11m 28m 23m 130m 0.00% 0.00% S6U37 web 31
19187 m.jvmtop.JvmTop 20m 3544m 13m 130m 0.93% 0.47% S6U37 web 20
16733 artup.Bootstrap 159m 455m 166m 304m 0.12% 0.00% S6U37 web 46
위의 내용 모두 중요하지만 가장 기본은 역시 코딩을 할 때 해당 코드가 어떻게 동작할지 어떻게 하면 메모리, cpu를 적게 사용할 수 있을지
고민하면서 효율적인 코드를 작성하는 것이다.
'좋은 코드가 좋은 시스템을 만든다’