올해와서는 자바를 주로 만지고 있기는 하지만 공부는 책위주로 하고 필요한 것들은 검색위주로 하다보니 특별히 Java쪽 커뮤니티나 사이트들을 다니는 곳들이 없었는데 블로깅을 하다가 세미나 정보각 눈에 띄어서 신청했다.(그러고나서 보니 내가 놓친 괜찮은 세미나들이 많더군... 난 주로 MS나 Sun등의 업체들이 하는 세미나 위주로 다녔었는데 커뮤니티들에서도 괜찮은 세미나를 많이 하고 있었다. 생각해 보면 당연한건데 왜 여태는 그런 생각을 못했었는지.. ㅡ..ㅡ 오히려 더 현실적이고 실무에 도움이 될만한....

암튼 이번 세미나는 OKJSP에서 진행한 세미나로 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기를 지으신 이상민님이 "Performance and Java Tuning"라는 주제로 진행이 되었다.



본 세미나 전에 kenu님의 TPTP에 대한 설명이 약간 있었다. TPTP는 Test & Performance Tools Platform의 약자로 이클립스 프로젝트의 하나이다. kenu님은 All-in-one버전을 추천하셨고 kenu님의 블로그에 가면 TPTP의 자료를 얻을 수 있다. 쉽게 말해 이클립스 상에서 테스트를 하고 성능진단을 할 수 있는 플랫폼을 얘기한다.

개발하면서 서능에 대한 부분까지 확인할 수 있는 것인데 아직 그런 수준까지는 가지도 못했지만 내가 관심이 있는 분야였기 때문에 이런 것이 있다는게 꽤 흥미로웠다. 이번 프로젝트 끝나면 설치해서 좀 만져봐야겠다. 현재버전은 4.5라고 한다. (디밸로퍼웍스에도 TPTP에 대한 강좌들이 있다.) 퍼포먼스에 대한 테스트를 할 수 도 있고 실행할 때의 클래스가 호출되는 시퀀스도 볼 수 있고 Diagram도 볼 수 있는데 적응되면 아주 편할듯 싶다.





어쨌든 본 세미나가 시작되었다. 이하에 나오는 모든 내용은 이상민님의 발표자료를 바탕으로 되어있습니다.

퍼포먼스라 하면 응답시간과 TPS로 나눌 수 있다.

응답시간은 보통 성능을 얘기할때 개발자들이 많이 얘기하는 부분이다. 리퀘스트를 보내고 레스폰스가 올때가지의 시간이고

Network Connection -> Send Request data -> Wait Time(ServerTime) -> Receive Response Data -> Network close

의 순서로 이루어지는데 실제 튜닝이 가능한 부분은 가운데 Server Time뿐이다. 나머지는 컨트롤 할 수가 없으면 여기서 패킷이 전송된 후에 브라우저가 처리하는 시간은 성능에 포함시키지 않는다.

Server Time은 WAS에서 잡아먹는 시간인 Thread time과 그 외에서 잡아먹는 Wait Time으로 나눌수 있다. 이상민 님은 XML로 전송하는 것을 별로 좋아하시지 않는데 XML로 전송하는 것이 성능에 영향을 많이 끼치기 때문에 되도록 쓰지말기를 권하지만 절대 쓰지 말라는 것은 아니무로 당연히 필요한 부분에서 써야한다. 그 외에도 GCsk String도 영향을 많이 끼친단다. 그리고 Wati Time에서는 여러가지가 있지만 역시 DB Time이 가장크게 차지한다.

TPS는 Transaction Per Second의 약자로 서버의 처리능력인데 객관적인 수치이다. 1TPS면 서버로서는 상당히 적은 수치로 듀얼코어의 놋북정도면 커버가 가능하고 20TPS정도면 300명정도가 이용하는 사이트 정도는 충분히 커버가 가능하다고....

성능 테스트 툴로는 제일 유명한 머큐리사의 Load Runner, 그리고 이상민님이 추천하시는 Performance suite enterprise, SkilPerformer, Web LOAD가 있고 무료툴로는 Swing기반의 JMeter와 2002년 이후로는 Update가 없지만 아직은 쓸만하다는 MS Web application stress tool등이 있다. 무료와 상용툴의 큰 차이점은 무표툴들은 내가 쏜 URL로만 테스트를 하지만 사용툴들은 내 PC의 모든 패킷을 캡춰해 준다고 한다.



성능문제를 해결하고자 할때는 가장 중요한것은 병목현상이 일어나는 부분을 찾는 것이다.

병목현상을 찾으로면 가장 좋은 방법은 툴을 사용하는 것이다. 툴을 사용하면 될일을 일일이 System.out.println()을 사용할 필요가 없어진다. 만약 툴이 없다면 System.currentTimeMillis()나 JDK 5이상이라면 System.nanoTime()을 사용할 수도 있다. 그게 아니면 Access Log를 분석해야 하는데 기본적으로 응답시간은 찍히지 않기 때문에 설정에서 응답시간이 찍히도록 설정해 주어야 한다. 그리고 css, js, 이미지파일같은 Static한 것들은 성능하고는 상관이 없기 때문에 분석에서는 제외한다.


분석하는 툴로는 크게 APM과 Profiling Tool로 나눌수 있는데 APM은 전반적인 큰 그림을 볼 수 있으면 Jenifer등의 툴이 있고 Profiling Tool은 세밀한 부분을 볼 수 있으면 Dev Partner, Jproove, TPTP, Jprofiler등이 있다.

자바 튜닝의 대상들로는 Pattern, XML, I/O, String JDBC, GC Setting, Log등이 있다.

보통 튜닝을 해야하는 문제점에는 너무 느리거나 서버가 매일 죽거나하는 것이 가장큰 주요인이다.

이유야 너무 많긴 하지만 체크해야할 부분을 얘기하자면 응답이 너무 느리면 일단 환경을 체크해봐야하는데 환경에는 DB, Network Storage등이 있고 그 다음으로는 WAS Setting을 체크하는데 여기에는 쓰레드수, DB커넥션풀, Web Server설정들이 있다. WAS의 Keepalive설정(각 파일마다 연결을 새로하는지에 대한 여부인데 on으로 되어있으면 static한 파일들을 하나의 연결상태로 계속 받을수 있어서 기본적으론 on이 좋다고 한다.) 서버가 자주 죽는 경우는 메모리 문제(out of memory나 memory leak)나 너무 많은 유저로 발생할 수가 있다.



JVM설정을 볼때 -xx는 비표준이기 때문에 플랫폼이 바뀌면 안될 가능성이 있고 -x는 표준이다.



발표자료는 이상민님의 글에 있으며 위에 말한대로 위의 모든 내용은 발표자료와 이상민님이 발표하신 내용을 바탕으로 작성되었습니다. (내가 잊어버리지 않고 나중에 참고할 수 있도록....)