Performance tuning WebLogic 8.1 Systems

2013.02.14 05:47

조인상 조회 수:13518

원문 : http://www.ischo.net -- 조인상 // 시스템 엔지니어

Writer : http://www.ischo.net -- ischo // System Engineer in Replubic Of Korea

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

 



원문 : http://www.ischo.net -- 조인상 //시스템 엔지니어

+++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

아젠다 ---------------------------------------------

1. 목표

2. 튜닝 측면

 - 어플리케이션

 - 디비

 - 웹로직서버

 - JVM

 - 네트웍/ 하드웨어

 - OS

3. 튜닝 도구

아젠다 --------------------------------------------- 

 

 

성능 목표

1. 어플리케이션 이해

 - 유저수

 - request 수

 - data의 양

 - data의 구성

 

2. 성능 요구사항

 - 처리율 (system 측면)

 - 응답시간 (유저 측면)

 

 

 

언제 튜닝을 하는가?

1. 프로젝트를 시작할때 튜닝단계를 계획한다.

 - release할 모든 코드들이 정상 동작하면, 튜닝한다.

2. 마찬가지로 튜닝단계의 끝을 계획한다.

 - 남은기간을 체크하지 않으면 영원히 튜닝해야 한다.

3. 성능튜닝은 진행형이며, 되풀이 되는 프로세스이다.

 - 규모에 관계없이 튜닝은 모든 release 마다 해야하는 경우도 있다.

 - 성능현황을 모니터링하는 메카니즘을 시스템에 포함시키면 언제 튜닝해야하는지를 알수 있다.

 

 

성능목표를 명시적으로 정의하라

 - 목표는 반드시 측정가능해야 한다.

 - 그러지 않으면, 언제 목적을 완수했는지 어떻게 알수 있겠는가?

 

 

 

튜닝 측면

이미지 1.jpg

 

* 모든 노드와 연결선들은 잠재적인 병목지점이다.

 

 

가장 높고, 낮은 충격을 동반하는 ... 중요도의 순서가 있다.

 - 어플리케이션

 - 데이터베이스

 - 웹로직 서버

 - Java Virtual Machine

 - 네트웍 / 하드웨어

 - 운영체제

 

 

 1. 어플리케이션

1-1. 단순함을 유지하라

1-2. 오버-엔지니어링을 피하라

  - 부적절하고 쓸데없는 published-pattern에 의한 경우가 종종있다.

1-3. 현명하게 caching 하라

  - Service locator, JMS connection objects cache, JDBC connection pooling, thread pooling

1-4. Network call을 최소화하라

  - distributed computing golden rule

1-5. 데이터베이스 call을 최소화하라

1-6. Synchronized calls vs. Asynchronizedcalls

 

2. 좋은 J2EE performance design pattern 을 적용하라

 - Service locator, Session facade, Message facade, Value object, Composite entity

 

3. EJB

 - EJB home을 caching 하기

 - Caching stateless session EJB remote

 - Use concurrency strategy

 - 사용가능할때는 언제나 local interface를 사용하기

 

4. JSP/서블릿

 - redirect 대신에 forward를 사용하기

 - http 세션에 과다한 데이터를 넣는것을 피하기

 - 상태를 유지하기 위하여 stateful session bean보다는 http 세션을 이용하기

 - 불필요한 세션생성을 피하기

 - deploy 하기 전에 JSP의 pre-compile 하기

 

5. JDBC

 - prepared 되고 callable한 statements를 cache 한다

 - 트랜잭션들을 batch기반으로(batch-oriented) 만든다.

 

6. 몇몇 JAVA 팁들

 - Use primitive types rather than encapsulated classes

 - Use StringBuffer rather than String

 - Use static final when declaring constants

 - Declare methods as final whenever possible

 - Use the non-synchronized collection classes rather then Vector

 - Avoid unnecessary casting

 - Minimize use of instanceof

 - Avoid synchronized methods

 - Synchronized blocks are worse then synchronized methods

 

7. DATABASE

 - Second only to application code in potential for optimization

 - Database tuning is a joint exercise between developers, DBA’s, QA and Testing

 

 8. DATABASE 최적화 팁

 - DB 스키마

 : 올바른 indexing이 매우 중요하다 (인덱스 추가/삭제를 의미할수 있음)

 - shared memory를 사용하는 것을 고려하라

 - disk access를 줄이기 위하여 block size를 늘려라

 - open cursor 의 개수를 제한하라

 - 체크포인트 빈도를 줄여라

 - DBMS는 그 자체로 다양한 튜닝옵션들을 제공한다

 

 

 

 

* 웹로직 서버튜닝

1. 웹로직 서버의 튜닝 파라미터들

 -  Core server

 -  web application

 -  JMS

 -  EJB

 -  JDBC

 -  Transaction

 -  Web Service

 

2. Core Server의 키 튜닝 파라미터들

2-1. Thread Count 

 -  가장 경험적으로 튜닝됨

 -  최적의 구성은 CPU 사용율을 최대로 사용할 수 있는 최소의 쓰레드개수이다.

    :  너무 적은 쓰레드개수는 CPU 사용률이 적은 것이며; 작업은 쓰레드가 사용가능하게 될때까지 대기해야만 한다.

    :  너무 많은 쓰레드는 자원을 낭비한다.

 -  노는 CPU사용율은 정의되어야 한다.

    : CPU idle 은 10% 이하로...

 

2-2. Web Applications / 모듈에 특정된 실행큐(Excute Queues)

 -  데드락을 방지하는데 유용하다.

 -  요청의 급증을 관리하는데 유용하다.

 -  EJB는 weblogic-ejb-jar.xml 의 dispatch-policy 구성요소를 사용할 수 있다.

      <displatch-policy>MyQueue</dispatch-policy>

 -  웹 어플리케이션은 weblogic.xml의 wl-dispatch-policy나 web.xml의 param-name 서블릿으로써 사용 할 수 있다.

 

2-3. Performance Packs

 -  팩은 서버 성능을 높이기 위한 플랫폼에 최적화된(native) 소켓 muxer를 사용한다.

 -  Windows 2000 이상, Solaris 2.6, AIX 4.3, HPUX, Linux 이상에서 사용 가능

 -  server attribute tab에서 Enable Native I/O를 체크해준다.

   : config.xml 의 <NativeIOEnabled>를 추가한다.

 - 퍼포먼스 팩을 사용하기를 강력히 권고한다.

   : 퍼포먼스팩으로 약 150%의 성능향상이 기대됨.

 

2-4. Socket Readers

 - 소켓 리더로써 전용으로 배정되는 실행쓰레드의 비율을 지정함.

   : Server Attribute 의 “ThreadPoolPercentSocketReaders”를 사용함

   : 남아있는 쓰레드는 worker 쓰레드

 -  퍼포먼스 팩을 사용하지 않을 때만 적용할 수 있음

    : 가능하면 퍼포먼스팩을 사용할 것을 권장함

 -  Default VS 권장

    : Default값은 33

    : 권장값은 33~99

 - 최적값은 어플리케이션에 따라 매우 다르다

 

2-5. Connection Backlog Buffering

 - 대기 큐에 얼마나 많은 TCP 연결이 버퍼될 수 있는지를 지정한다.

   : 많은 connection 이 drop 되거나 거절 되면 서버에는 에러가 남지 않으며, 이것은 문제가 될 수 있다.

   : 메시지가 더 이상 나오지 않을때까지 25% 단위로 증가시킨다.

 - Server Attribute 에서 Accept Backlog 를 설정한다

   : config.xml 에서 Accept Backlog 값을 지정한다

   : connection 거절을 피하기 위하여 Accept Backlog값을 늘린다

 - Default VS 권장

   : Default 는 50

   : 권장은 50~(운영체제에 따라)

 

2-6. Chunk-Tuning

 - 많은 요청/응답이 있는 경우에만 필요함

 - 소켓 read/write 의 개수를 적절하게 줄이는 것으로 튜닝

 -  -Dweblogic.ChunkSize and -Dweblogic.utils.io.chunkpoolsize

 - 주요 요인은 MTU와 request size

 - 클라이언트와 서버 양쪽 모두를 세팅한다

 - 메모리 사용량이 더 많이 요구된다

 

2-7. Clustering

 - 클러스터링은 응답시간과 HA의 기본 요소이다.

   : 로드밸런싱, Fail-over, Scalability

 

 

3. web application

3-1. HTTP Session State를 조심히 다뤄라

 - session state와 size를 최소화 하라

 - 여러개의 single object 보다는 aggregate object를 이용하라

 - 적합한 세션 유지 메카니즘을 선택하라

 

3-2. JSP 페이지 체크와 servlet reloading 을 비활성화 하라

 - jsp-param pageCheckSeconds = -1 로 세팅하라

 - container descriptor 에서 servlet-reload-check-secs = -1 로 세팅하거나

 - config.xml 의 WebAppComponent 에서 ServletReloadCheckSecs = -1 로 세팅하라

 - 5~8%의 성능향상 효과가 있다.

 

3-3. Precompile JSP

 - 모든 JSP들은 precompile되어야 한다

 - 서버가 restart될때마다 JSP들을 recompile 하는것을 피한다

 - 서버 startup 시간에 영향을 끼친다

 - jsp-param precompile=true 로 설정한다

 

3-4. 서블릿과 EJB에  별도의 실행큐를 배정한다.

 

 

4.  JMS

4-1. 메시지 디자인 팁

 - 메시지 타입에 따라 Serialization cost는 다양함

    : 일반적으로 Byte, Stream < Object, Map < Text, XML

 - message properties의 Stings의 사용을 피한다.

 - 큰 메시지를 압축하는것을 고려하여 메시지 사이즈를 최소화 한다

 - Message selectors는 비싸다.(특히 Xpath)

   : 가능하면 indexed topic subscribers를 사용하라

   : selector 대신에 여러개의 destination 을 사용하라

 - message paging은 성능을 떨어뜨린다( 기본값으로 disable)

 

5.  EJB

( 생략 )

 

6. JDBC

6-1. min-capacity 와 max-capacity 값을 같게 설정하라.

 

6-2. 큰 오버헤드 환경 : ConnectionLeakProfiling, CheckConnectionOnReserve/Release

 

6-3. 풀 사이즈 >=  DB작업을 실행할 것으로 예상되는 모든 실행큐들의 쓰레드카운트의 총 합계

 

6-4. Prepared statement cache

 - 준비되고 호출 가능한 statement를 캐쉬한다

 - 네트웍 roundtip과 데이터베이스에서 준비작업을 줄인다.

 - connection pool의 각 connection 은 자신의 개별 캐시를 가진다.

 - 올바른 드라이버를 선택하는것이 중요하다. (type 2 드라이버는 빠르지 않다)

 - 오라클 10g thin 드라이버가 9i 것보다 빠르다.

 - 컴파일된 SQL문의 connection-specific 캐시

 - java.sql.PreparedStatement 의 사용이 필요

 - 기본값은 10이며, 어플리케이션의 prepared statement들의 총 개수로 설정해야한다.

 

 

7. Transaction Performance

7-1. Keep transactions short


7-2. Choose appropriate isolation level


7-3. Minimize distributed transaction Two-phase commit costs - Use local transactions and non-XA drivers where possible
 -  Experiment with various JDBC drivers for your database (JDBC driver performance is highly variable, especially XA JDBC drivers)
 -  Make sure database server CPU is not the bottleneck
 -  Use separate physical drives for transaction logs and JMS file stores
 -  Use of Direct-Write for transaction log files may improve performance with hardware write cache enabled 

 

7-4.XA overhead
 - Due to transaction logging and inefficient XA implementation of JDBC drivers


7-5. JMS and JDBC in a transaction
 - Requires two-phase commit (even if it is the same database)
 - JMS has to use an XA-enabled Connection Factory
 - Therefore, JDBC has to use an XA driver (slow!)


7-6. JMS and JMS in a transaction
 - Using 2 destinations from different JMS servers in a transactionwill use two-phase commit

 

 

8. Web Service

8-1. Operations with small simple method invocations perform much better than large complex invocations or arrays.


8-2. Prefer the use of the US-ASCII character set, it is the most efficient and the fastest. 

 

8-3. Security Overhead: data encryption and digital signatures adversely affect performance
 - be very judicious when adding security to a Web Service.


8-4. Be sure to turn off all debugging flags you might have turned onduring development

 

 

9. JVM

9-1. Heap size

 - 32bit JVM은 4GB까지의 최대 메모리를 갖는다.

 - 디스크로 swap될 어떠한 heap 도 허용하지 말라

 - 1개의 거대한 heap을 가진 단일 서버보다는 작은 heap을 가진 여러개의 서버가 더 낫다

   : GC가 더 짧아지고 분산되어 충격이 적어진다

 - 메모리 expansion과 shrinking 을 방지하기 위해서 -ms 와 -mx을 같은 값으로 잡아준다.

 

9-2. Heap size와 Gabage Collection

 - RAM보다 더 큰 heap사이즈는 page swapping을 일으킨다.

 - 큰 heap은 느리지만, GC를 덜한다

 - 작은 heap은 빠르지만, GC를 자주한다

 - 목표는 어플리케이션에 적합한 중간포인트를 잡는 것이다.

 - GC 현황을 분석하기 위해서 -verbosegc 옵션을 사용한다.

 - 경험적으로 Full GC는 3~5초사이에 일어난다.

 

9-3.  Garbage collection

 -  -XX:NewSize와 -XX:MaxNewSize 를 같은 값으로 설정하라

 - 위의 값들을 최대 heap 사이즈의 약 1/4 정도로 구성하라

  : 다른 값들을 시험하라. 최적값은 어플리케이션의 오브젝트 instantiation 비율에 따라 다르다.

 - 위의 값들이 heap 사이즈의 1/2을 넘지 않도록 한다.

  : Full GC를 모니터링 한다

 -  -XX:SurvivorRatio 값을 4-8로 지정하고, minor GC를 모니터링 한다

 - Full GC의 interval을 3-5분이 넘지 않도록 한다

 

10. JVM to CPU Ratio

 - 웹로직 JVM당 2-4개의 CPU

 

 

 

 

 

 

 

 

 

 

 

 

 

번호 제목 글쓴이 날짜 조회 수
31 웹로직 패스워드 분실시 초기화 방법 조인상 2013.12.17 17605
30 RHEL 5.x에 웹로직 설치 file 조인상 2013.07.10 13789
» Performance tuning WebLogic 8.1 Systems file 조인상 2013.02.14 13518
28 웹로직 , 아파치 연동하기 조인상 2013.02.06 19135
27 weblogic 을 위한 OS별 커널파라미터 권장값 조인상 2011.10.19 16057
26 WebLogic Server 와 Server Instances 에 대한 정보확인 명령어 조인상 2011.02.23 13847
25 [WAS] Tmax WebtoB, JEUS 운영 관리 지침 secret 조인상 2010.12.30 0
24 XE 게시글 보호 (복사방지/블럭방지/마우스액션 금지) 조인상 2010.12.07 11024
23 weblogic 기본 교육 교재 file 조인상 2010.11.17 12588
22 JEUS 버전 확인 방법 조인상 2010.10.20 25479
21 SNMP 보안 file 조인상 2010.07.23 11094
20 톰캣 에러 - Exception loading sessions from persistent storage 조인상 2010.06.21 19995
19 제로보드 - fread() [function.fread]: Length parameter must be greater than 0 in ~~/bbs/lib.php on line 1010 [1] 조인상 2010.06.01 15365
18 TCP/UDP Port Map 조인상 2010.05.31 25542
17 민주주의 벌받기시계 달기 조인상 2010.05.14 11147
16 xe 에서 일반유저를 관리그룹으로 포함시키려면 관리자 2010.05.13 10778
15 아파치 환경에서 404 페이지 만들기 조인상 2010.05.13 10696
14 tmax 제우스,웹투비 프로세스를 윈도우 서비스에 등록시키기 조인상 2010.05.12 14429
13 XE에서 파일첨부용량 변경하기 조인상 2010.05.12 10561
12 Zend optimizer 설치 조인상 2010.05.12 10368
서버에 요청 중입니다. 잠시만 기다려 주십시오...