JBoss Performance Tunning byj
목 차 I. Basics 1. 성능튜닝의목적 II. JBoss AS 의성능 Factors 1. 성능튜닝개요 2. Application 3. 웹레이어 4. EJB 레이어 5. Database 6. 보안 7. Logging 8. 클러스터링 9. JVM III. 로드테스팅 Hints IV. 튜닝방법 V. references 자료 - 2 -
1. Basics 1. 성능튜닝의목적 1. Throughput 향상 2. 빠른응답시간 3. 응답시간의보장 4. 시스템성능의측정 - 3 -
1. 성능튜닝개요 Application 웹레이어 EJB 레이어 Database 보안 Logging 클러스터링 JVM Profiling - 4 -
2. Application Application 은다른성능 factor 이상으로성능을결정한다. App Server 나하드웨어를튜닝한다고해도 Application 디자인에서문제가있다면성능이나올수없다. Tips: 당신의 application 을최대한효과적으로튜닝하는것이제일좋은방법이다. 테스트와최적화작업을초기부터고려하여같이진행하는것이좋다. - 5 -
3. Web 레이어 Apache 와 Tomcat 로드밸러싱을위해 Apache를이용하여라.(mod_jk) mod_jk2를사용하지않도록한다. 나중에는 mod_proxy 를사용하는것이좋다. - 6 -
3. Web 레이어 Apache mod_jk 의 configuration을확인하라 mod_jk 문서를활용하여라 jboss.com의 Webinar를활용하여라. Apache Httpd server를이용하여 static content 서비스를하여라 load를줄여준다. cache 시간을조절하는 mod_expire를이용하여라. 브라우져와 proxy 서버에있는 caching 정책을조절하는유일한방법이다. 로드를줄임으로써엔드유저에게는성능향상을느끼게해준다. 파일의타입에따라 caching 정책을따로하여관리한다. - 7 -
3. Web 레이어 Tomcat 일반적으로 logging 을최소화하거나끈다. Connectors(http+ajp) 에사용되는쓰레드의최소 / 최대개수를튜닝한다. AJP Connector를이용하는경우 http Connector는사용하지않는다. JSP 의최적화 Development 모드를끈다.( 각 JSP 의새버젼을체크하기때문에 ) JSPs 를선컴파일해둔다. JSPs 의 debug 정보를사용하지않도록한다.(default:yes, classdebuginfo) Tomcat 4.x 보단 5.x 버전을디볼트로사용하도록한다. - 8 -
4. EJB 레이어 Pooling Object가사용되기전에먼저생성된 Object 그룹을제공한다. Object의생성과초기화에들어가는시간을절약할수있다. 예를들자면 http 리스너 datasources EJBs - 9 -
Pooling and Queuing - 10 -
Typical Load Profile - 11 -
4. EJB 레이어 Bean invocation 통계정보 http://localhost:8080/web-console - 12 -
4. EJB 레이어 Caching 가능한부분에모두캐싱하도록한다. (Cache 하는것이가장좋다.) Database의접근하거나 serialization 하는것을줄일수있다. CMP Caching 은 Commit Options (A/B/C/D) 에따라정책을적용할수있다. db와의데이터싱크타이밍을맞추어주는역할을한다. Caching 은성능과캐싱된데이터검증사이에있다. 따라서데이터오프젝트의검증은필요하다. 클러스터 / 멀티노드모드의 Caching은반드시 cache 된데이터체크가있어야한다. 그렇다고 caching 모드를끄는것은좋지않다. CMP 모드를가진프레임워크에서는 caching 은유효하지않다. HIbernate / JBossCache를이용하라. - 13 -
Cache는 30 초마다 refresh 된다. - 14 -
4. EJB 레이어 CMP 튜닝 Caching 로드분산전략 그룹을나누어로드를준다. DB의데이터읽는타이밍의전략 ( 싱크 ) 1. Find 시점 2. Load 시점 CMT 튜닝을위해서는 JBoss 문서와튜닝가이드를참조해서튜닝하면된다. - 15 -
4. EJB 레이어 CMP 튜닝 CMP Cache 사용 CachaMonitor 를반드시활성화하여야한다. Cache 사용률 ( 사이즈 ) 를체크하여라 - 16 -
4. EJB 레이어 트랜젝션과동시사용 트렌젝션은데이터무결성을보장되어야한다. 같은 EJB 인스턴스에멀티트렌젝션이발생하는경우트랜젝션의락킹이발생한다. 결론적으로클라이언트 1 이해당트렌젝션이끝날때까지클라이언트 2 가기다리게된다. Thread-Locking 발생 - 17 -
4. EJB 레이어 Locking Detection EntityLockMonitor 는활성화되어있어야한다. Contention -> 다른트렌젝션이 Locking 이풀리기를기다리고있을경우발생한다. Lock Time - 18 -
4. EJB 레이어 Locking 최적화 항상트렌젝션 Locking 이필요한가? read only 만하는메소드나 Bean을구분한다. 되도록이면트렌젝션의짧게하도록한다. Locking 정책을변경하는것이도움이될수도있다. - 19 -
4. EJB 레이어 Locking Locking은데이터의무결성을유지하기위해있다. standardjboss.xml / jboss.xml 에있는각각의다른빈별로다른 locking 정책을적용이가능하다. Pessimistic Locking 정책 (default) 트랜젝션이일어나는동안관련리소스는 locking 된다. 동시에트랜젝션이접근시한개는기다리게되고한개는진행하게된다.(exclusive Lock) Optimistic Locking 정책 동시접근을허용한다. 최소의 locking 시간을갖는정책이다.(database의 synchronization 함으로써 lock 를관리한다.) Locking 없는정책 exclusive Lock 을사용하지않는다. 멀티쓰레드 / 트렌젝션에의해동시접근이가능하다. Read-Write Locking 정책 ( 가장적절한정책으로보인다.) 동시에여러개의 Read Locks을허용한다. 단 Write Lock 시 Read-Locks 이걸리지않는다. Read-only 전략 데이터의생성 / 삭제 / 수정을허용하지않는다.(no ejbstore()) 트랜젝션 lock 은발생하지않는다. 가능하면 Read-only 전략을사용한다.( 공유되는마스터데이터의경우 ) Read-Write Locking 정책을적용하는것이좋다. - 20 -
4. EJB 레이어 Database Connection Pools 어플리케이션을위한 poolsize를튜닝하여라 (database 에서지원하는개수를초과하지않도록한다. statements 를트래킹하여라. 테스트시로그에남기도록하고운영시에는남기지않도록한다. prepared-statement 캐시를이용한다. 성능의향상을가져온다. insert 시 60% 이상의성능향상을가져온다. - 21 -
4. EJB 레이어 JMS 성능향상 확장성을위해서는 JMS 클러스터링을이용하라. 클러스터노드를여러개둠으로써로드를분산시킬수있다. 버전 3.2.7 이후에사용하라. 서버의 overload를피하기위해서 MDB 인스턴스의개수를제안하라 동시에 100개의메세지를 100개의 MDB에서처리하는경우여러가지문제가발생한다. CPU, Database, Memory, Excution time 합리적인개수를정하여제한을한다. 디볼트로세팅되어있는 Hypersonic database 를이용하지않도록한다. - 22 -
5. DataBase DataBase Database 스키마를체크하라. 테이블별 Indexs 를잘정비하도록한다. 성능분석을위한 Database tools 을이용하라. - 23 -
6. Security Security JBoss 에서제공하는 Security Cache를이용한다. Authentication 과 Authorization 소스에있어로드를줄이는역할을한다. (LDAP, Database ) AuthenticationCache를이용하는지확인하라. web-console 또는로그파일의 MBean을체크하여라 - 24 -
7. Logging Logging 개발자를위한 Application logging 가이드라인을제시하며세팅한다. log level 별로어떤메시지를남길지결정한다. system.out.println() 은쓰지않도록한다. 불필요한 logging은끄도록한다. 예를들자면, Tomcat의불필요한로그를남기지않도록한다. load 테스팅과튜닝하기전에 error 로그가있는지확인한다. load 테스팅시남겨지는로그를확인하라. 성능적으로중요한힌트를얻을수있다. - 25 -
8. Clustering Clustering - 26 -
9. JVM - 27 -
9. JVM - 28 -
9. JVM - 29 -
9. JVM JVM 튜닝권장사항 서버사이드 Application을위한디볼트최대 heap 사이즈가 (64MB) 작다 멀티 CPU인경우 Parallel GC 를이용하여라. 로드테스팅, 메모리튜닝시메모리 Profile을확인하라. JDK 1.4 보다는 Java 5를권장한다. 가비지컬레션 (GC) 최적화는성능을향상시킨다. 상당히높은트렌젝션시스템에대한잠재력에대해낮게평가되고있다. JVM의 option 활용도를높여라. - 30 -
9. JVM JVM Tunning 메모리누수현상감지하기 메모리관리는 JVM에의해관리되지만개발자에의해메모리누수가발생할수있다. - profiling 이필요하다. - 31 -
9. JVM Profiling 분석을통해좀더나은성능을찾을수있다. JVM 스냅샷을비교한다. 메모리누수현상을찾을수있다. 상용 SW : OptimizeIT, JProble, JProfiler JBoss Production : JBoss Profiler - 32 -
3. 로드테스팅 Hints 로드테스팅 Hints 실제적인로드테스팅을위해서는 Load VS. Concurrent Load 실질적인비즈니스시나리오 시간을생각하라. 테스트중시스템모니터링 블랙박스에서테스트하지마라 병목현상이발생하는지점을찾아라. 시스템구성의최적화를하여라. 선행테스트를위하여 Pools 의개수를체크하여라 web server pool, DB connection pool, http/ajp Thread pool pool을사용함으로써병목현상해결에도움이된다. 시스템의최적수치를찾아라. Caching 효과를이용하라. - 33 -
4. 튜닝방법 튜닝방법 1. 성능관련한요구사항을분석하고목표를정한다. 2. 케이스분석을한다. 3. Application 분석 : Application 단의성능저하요인을제거한다. 4. 기본적인환경설정을체크하고 Pools 을설정한다. 5. 모니터링을위한세팅을한다. 6. 로드테스트를실행한다. 7. 분석 : 병목현상지점을찾는다. 로그파일분석. 8. 최적화작업실행다시 6번 (re-run 테스트실행 ) 9. 확장성테스트실행 - 34 -
5. references 자료 - 35 -
Extra Material - 36 -
Extra Material - 37 -