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

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

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

1. 목표

2. 튜닝 측면

 - 어플리케이션

 - 디비

 - 웹로직서버

 - JVM

 - 네트웍/ 하드웨어

 - OS

3. 튜닝 도구

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

성능 목표

1. 어플리케이션 이해

 - 유저수

 - request 수

 - data의 양

 - data의 구성

2. 성능 요구사항

 - 처리율 (system 측면)

 - 응답시간 (유저 측면)

언제 튜닝을 하는가?

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

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

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

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

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

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

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

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

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

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

튜닝 측면

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

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

 - 어플리케이션

 - 데이터베이스

 - 웹로직 서버

 - 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