Microsoft Word - 5Jeus_Performance_Tuning-cover.doc

Transcription

1 Whitepaper JEUS Performance Tuning Copyrightc 2001 TmaxSoft Co.,Ltd. All Right Reserved.

2 Contents I. JEUS Performance Tuning... 3 II. OS Tuning... 4 File Descriptor... 4 TCP parameters ) 리슨큐의길이 ) 재전송지연 ) CLOSE_WAIT 시간 ) 연결지속시간 ) 슬로우스타트... 7 III. Network Tuning... 8 IV. JVM Tuning... 9 Java Heap Size & Garbage Collection... 9 HotSpot 옵션 V. JEUS Tuning Engine Container와 Engine 매핑 JDBC Connection Pool Security Off VI. EJB Tuning Local Method Invocation EJB Bean Clustering EJB Bean Pooling InitCaching (Entity Bean Only) Fetch Size (Entity Bean Only) Home Method (Entity Bean Only) Method Classification (Entity Bean Only) ENGINE 타입선택하기 (Entity Bean Only) SUBENGINE 타입선택하기 (CMP Bean Only) Fast Deploy & EJBCompiler VII. Servlet/JSP Tuning Session Routing JDBC Connection Pooling WebT Connection Pooling Servlet/JSP Auto Reloading JEUS Performance Tuning 1

3 JSP Batch Compiler WebServer와의연결 VIII. JEUS Application Tuning JEUS Performance Tuning 2

4 I. JEUS Performance Tuning 시스템의성능을향상시키기위해서는여러가지사항을고려해야된다. 하드웨어의사양을높이는방법, 네트웍튜닝, OS의환경변수튜닝, JVM 환경변수를튜닝하는방법, 그리고어플리케이션프로그램을튜닝하는방법등등어느하나소홀히할수있는것이없다. 성능향상은어느특정부분만을튜닝하여얻는것이라기보다는, 시스템이운영되는여러환경을전체적으로이해하고고려해야만원하는성능을얻을수있는것이다. 본문서에서는다음과같은튜닝관점에대하여다루려한다. Operation System Network JVM JEUS - 공통적인부분 JEUS EJB Engine JEUS Servlet Engine Application 위에열거한요소들은각분야의전문지식이필요하니튜닝을위해수정을할시에는반드시각분야의전문가와상의하여결정하도록한다. JEUS Performance Tuning 3

5 II. OS Tuning File Descriptor Unix 에서는각사용자의 Account 가정해진수의 file descriptor를가진다. ulimit 라는 command를사용하여리소스 limit 을살피고고쳐보자. Reource limit 는한쌍의값을가지고있고그값은 current limit (soft) 과 maximum limit (hard) 를표시한다. Hard limit 는 /etc/system 에서고칠수있고그후엔반드시새로부팅시켜야한다. Note : Soft limit 는고치지않도록한다. 이값은제우스에는반영되지않는다. Hard limit 을높이려면루트권한을가진계정을가지고있어야한다 Solaris 의경우 $ ulimit $ set rlim_fd_max 4096 /* hard limit */ File Descriptor 와관련된문제점들 1. Too many open files 2. Broken pipe error 3. ClassNotFound JEUS Performance Tuning 4

6 TCP parameters 1) 리슨큐의길이 TCP 에서는정해진크기의큐를두어서즉시처리할수없는접속을그큐에넣어서관리한다. 이런큐를보통리슨큐또는 backlog 라고한다. 트래픽이한꺼번에몰리게되었을때이큐의크기가작을경우접속자를차단하는경우가생기게된다. 리슨큐를증가시키면처리할수있는접속보류자수를늘리게되지만큐가클수록더많은메모리가필요하다는것을알아두어야한다. -Solaris 의경우 $ ndd set /dev/tcp tcp_conn_req_max_q linux 2.0 의경우 include/linux/socket/h 파일에서 SOMAXCONN의기본값을 1024 으로바꾸고커널을다시컴파일하면된다. 2) 재전송지연 TCP 에서는정해진시간내에세그먼트확인응답을받지못할경우손실된것으로가정하고다시다른복사본을전송한다. 이때기본으로정해진시간은 200ms 인데지연시간이보통큰인터넷의경우에는기본값이작아같은패킷을여러번전송하는경우가생길수있다. 재전송횟수를확인하는방법을확인하여재전송지연값을조절하도록한다. -Solaris 재전송횟수확인절차 $ netstat s 위의명령으로나온결과중 tcpoutdatasegs 와 tcpretranssegs, 그리고 tcpoutdatabytes 와 tcpretransbytes 를비교하여세그먼트또는바이트의 20% 이상이재전송되는경우라면재전송지연값을높이도록한다. JEUS Performance Tuning 5

7 재전송지연값설정 $ ndd set /dev/tcp tcp_rexmit_interval_initial ) CLOSE_WAIT 시간 이값은소켓이닫힌이후에다른클라이언트가이소켓을사용할수있을때까지기다리는시간을말한다. 너무작게설정되어있을경우에세그먼트가늦게도착하면정상적인데이터를받지못할수도있고오히려너무크게설정되어있을경우에는접속량이줄어드는결과를낳을수도있다. 남아있는세그먼트가없을정도로만값을설정하는것이좋다. Solaris 의경우기본값이 4분으로설정되어있는데접속자가많을경우에는성능에큰저하를가져올수있기때문에 60초정도로설정하는것이바람직하다. -Solaris $ ndd set /dev/tcp tcp_time_wait_interval Solaris or 2.6 ~ $ ndd set /dev/tcp tcp_close_wait_interval ) 연결지속시간 TCP 의접속에서는한쪽이다운이되는경우다른한쪽이접속을시도하기전까지는다운된쪽의상태를확인할방법이없다. 실제로클라이언트가정상적으로접속을종료하지않는경우가많기때문에서버측에서는리소스가낭비될수있다. 클라이언트측의접속상태확인을일정시간동안마다하게되는데그간격을조절함으로써성능을향상시킬수있다. 기본시간간격은보통 2시간에서 8시간정도로되어있는데클라이언트가많을경우에는줄여서설정해야한다. -Solaris $ ndd set /dev/tcp tcp_keepalive_interval JEUS Performance Tuning 6

8 5) 슬로우스타트 슬로우스타트는수신측이최대처리할수있는데이터양까지한개의세그먼트부터다시두개그리고네개, 이런식으로보내는방식이다. 장점은최적의송신량을알수있다는점이지만접속횟수가많고지속시간이짧은웹환경에서는오히려느릴수도있다. 윈도우를사용하는클라이언트에게슬로우스타트를사용하게되면문제가생길수있는데윈도우클라이언트는한개의패킷이아닌두개의패킷을처음부터기다리기때문이다. 한개의패킷이보내진후클라이언트는아무런응답없이두번째의패킷을기다리게되며서버측에서는첫번째보낸패킷의응답을기다리고있기때문에종료시간이되고나서야두번째의패킷전송이시작되게되고따라서많은시간이필요하게된다. 이런이유로슬로우스타트의처음패킷을 2개부터시작하게해야할필요성이있다. -Solaris $ ndd set /dev/tcp tcp_slow_start_initial 2 슬로우스타트의최대치역시조절해줄필요가있는데이는기본값이요즘의데이터전송량에비해너무작기때문이다. -Solaris $ ndd set /dev/tcp tcp_cwnd_max JEUS Performance Tuning 7

9 III. Network Tuning 네트워크자원이모자라성능이저하되는경우가있을수있다. 특히많은클라이언트의접속을허용하는웹서버의경우에는네트워크의성능은아주중요하다. 네트워크의상태를잘파악하고혹시네트워크가서버의처리량을못따라가는것이아닌지확인할필요가있다. 충분한 Bandwidth 를확보하는것은아주중요하다. 클라이언트가많을경우많은접속을허용할수있어야하고서버역시다른 Tier 에있는 Database등을접속해야하므로이모두를소화할수있는 Bandwidth를가지고있어야한다. 충분한 Bandwidth 를가지고있는경우에여전히네트워크가제우스서버의성능을저하시킨다고판단되는경우네트워크하드웨어나소프트웨어에문제가있는지확인해본다. 네트워크전문가와상의하여이부분의문제점을찾아해결하도록한다. 위의자원들을다확인하고나서여전히문제점이있다면네트워크인프라의구조를다시살펴보아야한다. 디자인이안정적이지않다면접속량과처리량이많을경우에문제가야기될수있다. 시스템을더늘리는방법으로일반적으로해결될수있으나심한경우에는인프라구조를다시디자인해야할수도있다. JEUS Performance Tuning 8

10 IV. JVM Tuning Java Heap Size & Garbage Collection Java Heap 에는자바프로그램의 object 들이있는곳이다. 이안에는활동중인 Object 가있을수도있고또는아무도 point 를안해 Garbage 가된 Object 들도있다. Heap Size 의중요성은 Garbage Collection 과밀접한관계가있다. 크기가큰경우에는 Garbage Collection 이오래걸리는반면그빈도는적게된다. 반대로크기가작은경우에는 Garbage Collection 은짧은반면그빈도는늘어나게된다. 가장이상적인 Heap Size 는 Garbage Collection 에쓰이는시간을최소화하는크기라할수있다. 서버어플리케이션의경우에는기본값이충분치않을수있으므로재설정이필요하다. Garbage Collection 을수행시걸리는시간이너무크지않다면시스템의 RAM 크기를고려해될수있는한큰값을설정하도록한다. Heap 의크기는 1024의배수로 1MB 이상설정해야한다. 일반적으로최소치와최대치를같은값으로설정하는것이권장된다. 프로세서를늘린경우에는이값을다시높게설정해야한다. 전체 Garbage Collection 을할때시간이 3-4초이상걸리는경우에는 Size 를줄일필요성이있다. 또한 Garbage Collection 이끝난후에 Heap 에할당된메모리가항상 85 % 이상이되는경우에도 size 를줄이는것이바람직하다. -Xverbosegc 옵션은매 Garbage Collection 의정보를모니터하게해준다. 이때의정보를이용하여적절한 Heap Size 를계산해볼수있다. -Xverbosegc:file=/tmp/gc$$.out 옵션을주면 Garbage Collection 의정보를파일로저장한다. $ java.. Xms512m Xmx512m -Xms 옵션은 Heap 의최소치를설정한다. -Xmx 옵션은 Heap 의최대치를설정한다. Heap Size 가너무작을경우 OutOfMemoryError 가발생할수도있 JEUS Performance Tuning 9

11 다. 이런경우에도 Heap Size 를늘려주어야한다. 1.3 Java HotSpot JVM 은성능향상을위해 Generational Collection 방식을사용하고있다. Object들을 Generation 별로나누어각 Generation 공간이찬경우 Live Object 들만을다음 Generation 으로옮기고나머지들은 Garbage Collection 을하는방식이다. 대부분의 Object 들이생성된직후에 Garbage 가되기때문에향상된성능을가져온다. Generation 별로공간이있기때문에그크기역시지정해줄수있다. 전체 Heap Size 와비례하게설정을하고프로세서를늘린경우에는이값들의재설정이필요하다. $ java.. XX:NewSize=128m XX:MaxNewSize=128m XX:SurvivorRatio=8 -XX:NewSize 옵션은 New generation 의 heap size 를설정한다. 전체 Heap 사이즈의 25% 정도로설정하는것이보통이다. -XX:MaxNewSize 옵션은 New generation 의 heap size 최대값을설정한다. -XX:SurvivorRatio 옵션은 New generation 안에서 Eden 과 Survivor 사이의비율을설정한다. HotSpot 옵션 HotSpot 에는많은종류의옵션들을설정해줄수있는데이중에서성능을향상시키는데도움이되는몇가지를살펴보도록하겠다. -oss 이옵션은 Java Thread Stack Size 를설정할때쓰인다. 이값을 2MB 이상으로설정하는경우성능의저하를초래할수있다. -ss 이옵션은 Native Thread Stack Size 를설정할때쓰인다. 이값역시 2MB 이상으로설정하는경우성능의저하를초래할수있다. -Xnoclassgc 이옵션은클래스에대한 Garbage Collection 을끄는데쓰인다. 이옵션을설정한경우에는더큰 Heap Size 가필요하다. JEUS Performance Tuning 10

12 V. JEUS Tuning 본장에서는 JEUS시스템전체적인 Performance향상방법을다루고자한다.. 다룰내용은아래와같다. Engine Container와 Engine 매핑 JDBC Connection Pool Local Transaction Optimization Security Off Engine Container와 Engine 매핑 JEUS 시스템은 EJB 엔진, Servlet 엔진, JMS 엔진의세가지엔진을 Engine Container라는단위로자유로이설정할수있다. 바꿔말하면하나의 Engine Container는하나의 JVM에매핑되므로엔진을 JVM 단위로설정이가능하다는얘기이다. 이것은전체시스템의성능및리소스관리차원에서매우중요하다. 여러엔진을같은 JVM에할당할시얻는성능및리소스이용측면에서의장점을들자면 Local Method Invocation 기능을이용하여프로세스간통신을로컬메쏘드콜형태로바꾸어성능을향상시킬수있다. 복수개의엔진이하나의 JVM에할당되므로, 각엔진을각 JVM 에할당하여운영하는것보다시스템리소스를적게잡고서도운영이가능하다. JEUS Performance Tuning 11

13 JDBC Connection Pool 데이터베이스에 JDBC Connection을생성하는작업은상당히느린작업이다. Connection Pool을이용하지않는에플리케이션의경우 JDBC Connection을맺고끊고하는작업을반복한다면이는성능을떨어뜨린다. JEUS는 Connection Pool을제공함으로써물리적 JDBC Connection을끊지않고, 논리적 JDBC Connection만끊게함으로서실제데이터베이스와의물리적 JDBC Connection을재사용하게해준다. JDBC Connection Pool 기술은앞서말한 JDBC Connection 생성작업을거의없앰으로서시스템의성능을향상시킨다. JeusMain.xml의 <DataSource> 항목에 DataSource에대한환경을설정할수있는데, 파라미터를설정할때, 몆가지사항을고려해야한다. ( 파라미터의자세한설명은 JEUS JDBC Guide를참조하기바란다.) 먼저, <MinPoolSize> 와 <MaxPoolSize> 를동시접근유저수를고려하여적절히잡아야된다. Pool Size가너무작다면동시접근유저가 Connection을얻기위해블록킹되는시간이길어져성능을떨어뜨리고, 너무크게잡는다면 Connection등리소스의낭비뿐아니라불필요한서버프로세스가데이터베이스에살아있어성능을저하시킨다. Pool Size는원칙적으로동시에 Connection Pool에 Access하여 Connection을얻어서데이터베이스에작업하려고하는쓰레드의개수만큼을잡는것이좋다. 두번째로, DataSource타입중상대적으로부하가큰 XA DataSource의사용필요성을고려해보아야한다. 복수개의데이터베이스를이용하는데분산트랜잭션이필요없거나, 단일데이터베이스만사용하는경우라면 DataSource 타입을 XADataSource가아닌 ConnectionPool DataSource를이용하여성능향상을꾀할수있겠다. JEUS Performance Tuning 12

14 Local Transaction Optimization 기본적으로 JEUS 트랜잭션시스템은 XADataSource 를기반으로동작한다. XADataSource 로부터얻어진 XAConnection 을사용하는복수개의작업을트랜잭션으로묶어진행하게되면이트랜잭션이이기종데이터베이스에대해작업을하고, 복수개의 JEUS Transaction Manager 관리영역을통과한다하더라도모두하나의 global 트랜잭션을묶여져처리된다. 이러한동작방식은다양하고복잡한어플리케이션프로그램에대해트랜잭션환경을제공하지만, 실제어플리케이션프로그램들은대개하나의데이터베이스인스턴스에대해작업을수행하고그트랜잭션의실행영역또한 JEUS Transaction Manager 하나의관리영역을벗어나지않는것이보통이다. ( 하나의 JEUS Transaction Manager 는하나의 JVM을관리영역으로한다 ) 이경우 JEUS 트랜잭션시스템에서는 XAConnection 이아닌 Pooled- Connection 을이용하여보다효율적으로트랜잭션을수행한다. 트랜잭션수행을 XADataSource로하여야하는이유는트랜잭션이복수개의데이터베이스에접근하였을때이트랜잭션의 commit 시점에서이들데이터베이스인스턴스들과 2 phase commit 을진행하여야하기때문이다. 만약트랜잭션이하나의데이터베이스인스턴스와만작업을진행한다면하나의데이터베이스에대한복수개의 branch들을하나의 branch로묶는 branch joining과 1 phase commit 프로토콜에의해서 commit 메시지한번으로 commit 이처리될수있다. Local Transaction Optimization 에서는이보다한걸음더나가트랜잭션을 Global 트랜잭션이아닌 Local 트랜잭션으로처리하는것이다. 어플리케이션은트랜잭션의시작과종료를선언하고트랜잭션진행중복수개의 Connection을얻어작업을진행하는등 Global 트랜잭션과똑같이작업을수행하지만 JEUS Connection Pool 이 JEUS Transaction Manager의도움을받아트랜잭션의진행을추적해가며하나의 PooledConnection 이계속사용되도록 Connection을별도로관리한다. 이렇게하면 commit 과정에서 local 트랜잭션 commit을사용할수있을뿐만아니라 XAConnection 관리와관련된추가적메시지교환을하지않아도되어성능을보다향상시킬수있다. Local Transaction Optimization의개념은 J2EE 와 Connector Architecture 에서제시된바있다. JEUS 트랜잭션시스템의 Local Transaction Optimization 은이루고자하는바는같지만그구현방 JEUS Performance Tuning 13

15 식이다르다. Connector Architecture 에서는하나의트랜잭션이 local 트랜잭션으로처리가가능한가를 Connector 시스템이자동으로감지하지만 JEUS 트랜잭션시스템에서는어플리케이션시스템관리자가 Local Transaction Optimization 용 Connection Pool을따로설정하고이 pool을기반으로트랜잭션작업이이루어져야만한다. 이렇게구현한이유는관리자가이러한설정을해줌으로써 Local Transaction Optimization 처리가훨씬간단하고효율적으로구현될수있으며이러한설정이매우간단하게이루어질수있기때문이다. Security Off 시스템운영중 JEUS에서제공하는보안기능을사용하지않는경우 JeusMain.xml 파일의 <Engine Container> 별로설정하는 <SecuritySwitch> 항목을 false로설정하는것이좋다. 이것이 true로설정되어있으면엔진내부의작업이나클라이언트가요청한작업을엔진에서처리할때인증 (Authentication) 과권한체크 (Authorization) 작업이빈번히일어난다. 이러한보안관련작업은 JEUS 시스템에오버헤드를주므로 JEUS제공보안기능을이용하지않는경우에는이를사용하지않도록설정하는것이좋다. JEUS Performance Tuning 14

16 VI. EJB Tuning 본장에서는 JEUS EJB 엔진에서의성능향상을위한방법을다루어보도록하겠다. 앞으로다룰 JEUS EJB 튜닝방법의종류를아래에열거하였다. 모듈간통신방법관련 Local Method Invocation 클러스터링관련 EJB Bean Clustering Pooling 관련 EJB Bean Pooling Entity Bean 관련 InitCaching (Entity Bean Only) Fetch Size (Entity Bean Only) Home Method (Entity Bean Only) Method Classification (Entity Bean Only) Engine 타입선택하기 (Entity Bean Only) Subengine 타입선택하기 (CMP Bean Only) Deploy 관련 Fast Deploy & EJBCompiler 각각의의미를명확히이해하여구축하려하는시스템이최적화된성능을내도록하자. JEUS Performance Tuning 15

17 Local Method Invocation 이전에는한 Bean에서같은엔진내의다른 Bean의메쏘드를호출할경우, 이는엔진밖의클라이언트가호출하는경우와마찬가지로 RMP 또는 RMI./IIOP 형태의프로토콜을이용하여메쏘드콜을해야만했었다. 이런형태의메쏘드콜은리소스를많이사용할뿐만아니라속도도느리다. Jeus-ejb-dd_< 모듈명 >.xml 파일의 <islocalinvocationoptimized> 항목을 true로설정하여같은엔진내의 Bean간의호출을로컬메쏘드콜로바꾸어성능을향상시킬수있다. 메쏘드호출이되어질 Bean에이항목을설정하도록한다. EJB 메쏘드콜은기본적으로 Call-By-Value이지만 jeus-ejb-dd_< 모듈명 >.xml 파일의 <islocalinvocationoptimized> 항목이 true로설정된 Bean을호출할경우는 Local Method Call이되어 Call-By- Reference로동작함을주의하여야한다. 파라미터가레퍼런스형태로동작함을인지하고주의깊게사용하여야한다. 구체적으로 JEUS내에서 Local Method Invocation이가능한통신경우를살펴보자. Servlet < > EJB Servlet 엔진과 EJB 엔진이동일한 JVM에위치하고 Servlet에서 EJB Bean을메쏘드콜할경우. EJB < > EJB 서로다른엔진이동일한 JVM에있고, 각엔진내의 EJB Bean간의통신의경우. 또는같은엔진내의두개의 EJB Bean간이통신 JMS < > Message-Driven Bean JMS Server로부터메시지을받아동작하는 Message-Driven Bean의경우메시지교환이 Local Method Call로이루어질수있다. JEUS Performance Tuning 16

18 Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info /> <beanlist> <stateless> <ejb-name>test</ejb-name> <export-port>0</export-port> <export-name>testapp</export-name>... <islocalinvocationoptimized> true </islocalinvocationoptimized>... </stateless> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 17

19 EJB Bean Clustering 하나의 Bean을여러개의 Engine에동시에 Deploy하여클러스터링할수있다. Jeus-ejb-dd_< 모듈명 >.xml 파일의 <clustering> 항목에클러스터링정보를설정할수있다. Bean을클러스터링함으로써, 클라이언트요청을클러스터링된 Bean에부하를분산시켜동시접근유저수를증가시키고, 리소스를효율적으로사용할수있게한다.. 또한 failover 옵션을설정함으로써 Fail-Over 기능이되게할수도있다. EJB Bean Clustering 기능을이용하여성능 (Performance), 확장성 (Scalibility), 안정성 (Stability) 그리고가용성 (Availability) 모두를향상시킬수있다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info> <module-name>module1</module-name> </module-info> <beanlist> <stateless> <ejb-name>bean1</ejb-name> <export-port>0</export-port> <export-name>name1</export-name> <export-iiop>false</export-iiop>... <clustering> <cluster-name>activestublink</cluster-name> <cluster-export-name>name1</cluster-export-name> <cluster-export-name>name2</cluster-export-name> <home-clustered>true</home-clustered> </clustering>... </stateless> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 18

20 EJB Bean Pooling 풀링은클라이언트의요청을처리할때인스턴스및쓰레드의생성오버헤드를피하고이를재사용하여리소스사용효율을높힘으로써시스템성능을향상시키는기술이다. EJB 모듈을 Deploy할때, jeusejb-dd_< 모듈명 >.xml 파일에아래세가지값을설정하여 EJB Bean별로풀링의크기, 증가단위및 Resizing 주기를설정할수있다. <bean-pool> EJB Bean의풀링최소값, 최대값, 증가단위, Resizing 주기를설정한다. <connect-pool> EJB Object 의풀링최소값, 최대값, 증가단위, Resizing 주기를설정한다. <thread-pool> 특정 Bean을동시에수행할수있는쓰레드의최소값, 최대값, 증가단위, Resizing 주기를설정한다. <bean-pool> <connect-pool> 은인스턴스재사용을위한풀링설정이다. 클라이언트에서 EJB Bean을생성하고삭제하는작업을하는경우 <pool-max> 를크게잡는것이성능향상을위해좋다. 하지만 <thread-pool> 은엄밀히말해쓰레드의재사용설정이아니다. 쓰레드의생성및소멸은 RMI 런타임내에서제어를하기때문에 JEUS EJB 엔진에서는이를제어할수없다. 다만 RMI 런타임에서시작된쓰레드가 EJB 엔진내의 EJB Bean을수행할때동시에수행될수있는쓰레드의개수및 Resizing 주기를 EJB Container에서제어할수있는데이에대한설정을 <thread-pool> 항목에해주면된다. <thread-pool> 과는달리 <bean-pool>, <connect-pool> 에서의풀링할최대값 <pool-max> 은다른의미를가진다. <bean-pool>, <connectpool> 에서설정한 <pool-max> 값의 EJB Bean 인스턴스, EJB Object 인스턴스가풀에서모두사용되어풀이비어있는경우, 이후에추가적인클라이언트요청이오면사용된인스턴스가풀에반환되는것을기다리지않고추가적인인스턴스를만들어제공한다. 하지만사용되어진추가적인인스턴스는풀에반환되지않고버려진다. Stateless Session Bean의경우 <bean-pool> 설정만을하는데, 이는 JEUS Performance Tuning 19

21 <connect-pool>, <thread-pool> 도동일한값으로설정됨을의미한다. Stateless Session Bean은그특성상 EJB Bean 인스턴스의풀링개수가 EJB Object 인스턴스개수및동시수행가능한쓰레드의개수와같다. 때문에 Stateless Session Bean의경우세가지중하나인 <beanpool> 항목의설정만으로세가지의풀링설정을하는것이다. 위의항목을설정할때, 전체 Bean의개수를고려하여그숫자를상대적으로결정하여야한다. <thread-pool> 를너무작게잡으면 CPU 사용이효율적이지않게된다. <thread-pool> 를너무크게잡으면유저요청이많을때, 시스템에동시에수행되는 thread가많아져스케쥴링및리소스할당으로인한부하가커져전체적인성능이떨어질수있으므로설정값에주의를요한다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info> <module-name/> </module-info> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>... <bean-pool> <pool-min>2</pool-min> <pool-max>4</pool-max> <resizing-period>600000</resizing-period> </bean-pool> <capacity>100000</capacity> <connect-pool> <pool-min>2</pool-min> <pool-max>4</pool-max> <resizing-period>600000</resizing-period> </connect-pool> <thread-pool> <pool-min>2</pool-min> <pool-max>4</pool-max> <pool-step>1</pool-step> <resizing-period>600000</resizing-period> </thread-pool>... </container-managed> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 20

22 InitCaching (Entity Bean Only) 데이터베이스의특정테이블의모든레코드가빈번히쓰이고, 그크기가크지않다면 jeus-ejb-dd_< 모듈명 >.xml 에 <init-caching> 옵션을 true로설정함으로써성능을향상시킬수있다. Deploy가끝난후요청이들어올때해당하는 Entity Bean이메모리에존재하지않는경우 Container는요청을처리하기전에테이블의레코드를 Entity Bean에로딩하는작업을한다. 이옵션을설정하면모듈의 Deploy 시점에테이블의모든레코드를 Entity Bean에캐쉬함으로써, 실제서비스를수행할때데이터베이스의데이터를 Entity Bean에로딩하는작업을없애성능을향상시킨다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info /> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>.... <init-caching>true</init-caching>... </container-managed> </beanlist> </jeus-ejb-dd> Fetch Size (Entity Bean Only) 데이터베이스테이블의레코드를 Entity Bean에로딩할필요가있을경우 JDBC Connection을이용하여데이터를가져온다. 이때 jeus-ejb-dd_< 모듈명 >.xml 파일에 <fetch-size> 항목에적절한값을설정하여 JDBC를통해한번에가져오는레코드의크기를결정할수있다. 이수치를적절히설정하여 Throughput을높힘으로써성능을향상시킬수있다. 보통의경우그크기를 10으로하는것을권장한다. JEUS Performance Tuning 21

23 Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info /> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>.... <fetch-size>10</fetch-size>... </container-managed> </beanlist> </jeus-ejb-dd> Home Method (Entity Bean Only) Entity Bean의어떤메쏘드가특정 Bean 인스턴스에해당하는메쏘드가아니고, Bean의공통적으로쓰이는성격이라면이를 Home Method 로만드는것을고려해본다. 비즈니스메쏘드를 Home Method로만들면메쏘드수행시 Container에서 EJBObject 할당없이 Anonymous Entity Bean을할당하여메쏘드를수행함으로써약간의성능향상을꾀할수있다. JEUS Performance Tuning 22

24 Method Classification (Entity Bean Only) Entity Bean의비즈니스메쏘드는 Persistence 측면에서두가지종류로나눌수있다. Entity Bean의값을변경시키는메쏘드와 Entity Bean의값을변경하지않는메쏘드가그두가지종류이다. Entity Bean의값을변경하지않는대표적인경우가 Entity Bean의값을읽는 (Read Only) 메쏘드이다. jeus-ejb-dd_< 모듈명 >.xml 파일의 <nonmodifying-methods> 항목에메쏘드를추가함으로써 Read Only 메쏘드라고명시할수있다. 한트랜잭션이끝나기직전에, Container는이트랜잭션과관련된모든 Entity Bean을조사하여 Read Only로설정되지않는메쏘드가한번이상수행된 Entity Bean에대해서만 ejbstore() 메쏘드를호출해준다. Entity Bean에 Read Only 메쏘드를명확히명시하여데이터베이스에불필요한작업을줄임으로써성능을높힐수있다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info /> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>.... <non-modifying-methods> getdescription() </non-modifying-methods> <non-modifying-methods> getprice() </non-modifying-methods>... </container-managed> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 23

25 ENGINE 타입선택하기 (Entity Bean Only) Entity Bean 이표현하는데이터베이스의테이블이이용되는형태를파악하여세가지중하나의엔진타입설정함으로써시스템성능을높힐수있다. 데이터이용형태를파악할때아래의사항을고려하자. 동시접근유저는많은가? 데이터읽기위주의작업이많은가? 아니면데이터수정작업이많은가? 데이터접근경합 (Contention) 이많은가? 트랜잭션처리의시간은얼마나되는가? 엔진타입선택시위에서열거한사항들을고려한다. 아래는각엔진타입이어느경우에적당한지를설명하였다. EJB Bean 클러스터링을하지않는경우는 EXCLUSIVE_ACCESS가적당하다. SINGLE_OBJECT와 MULTIPLE_OBJECT는 EJB Bean을클러스터링할경우에만의미가있다. EXCLUSIVE_ACCESS 데이터베이스특정테이블의레코드를시스템내의유일한한개의 EJB Bean이캐쉬하여트랜잭션시작시 EJB Bean의 ejbload() 작업을줄임으로서성능을향상시키는옵션이다. 동시접근유저가적은경우면서, 데이터캐쉬기능을최대한활용하여빠르고효율적인시스템구성을원할경우이옵션이적당하다. SINGLE_OBJECT EXCLUSIVE_ACCESS는 EJB Bean 인스턴스를이용할수있는트랜잭션이특정순간 (Snapshot) 단하나밖에없어서확장성 (Scalibility) 에문제가있다. SINGLE_OBJECT는동시접근유저가많아 EJB Bean 클러스터링을구성하여확장성 (Scalibility) 을높이려할경우에적당하다. 데이터베이스특정테이블의레코드를시스템내의클러스터링된여러개의 EJB Bean이표현하고있다. 그래서트랜잭션시작시매번 ejbload() 작업을해야하므로각각의트랜잭션작업만을보았을때는 Access Path가길어져 EXCLUSIVE_ACCESS에비해서는비효율적이다. 하지만동시에진행될수있는트랜잭션수을높힐수있다. JEUS Performance Tuning 24

26 MULTIPLE_OBJECT 이옵션은 SINGLE_OBJECT와같이클러스터링을이용하여 EJB Bean을구성하는경우에사용된다. 다른점은특정레코드를표현하는 EJB Bean 인스턴스가다른트랜잭션에할당된상태에서다른트랜잭션이같은 EJB Bean 인스턴스를요구할경우동일레코드를표현하는새로운 EJB Bean 인스턴스를만들어트랜잭션에할당하는방법이다. 데이터경합 (Contention) 이많아트랜잭션이동일한데이터에대한 Access가많을경우 SINGLE_OBJECT에비해 Concurrency를더높힐수있다. 트랜잭션길이가길어서하나의트랜잭션이진행되는동안다른트랜잭션이블록킹되는일이많아지는경우이옵션을설정하여 Concurrency를높이는것이좋다. 하지만데이터에대한작업성격이읽기보다는주로수정작업이라면데이터베이스의데이터접근경합 (Contention) 으로인하여 Deadlock 상황이발생할수있으므로주의를요한다. SINGLE_OBJECT보다더복잡한객체관리가요구되기때문에엔진오버헤드가크다는것도염두에두어야한다. 정리하자면클러스터링기능으로 Scalibility을높혀야하는데 SINGLE_OBJECT에비해동시에처리되는트랜잭션수를늘리려할경우, 동일한데이터에대한읽기작업많으면서데이터경합이심한상황이라면이옵션이적당하다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info> <module-name/> </module-info> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>... <engine-type>exclusive_access</engine-type>... </container-managed> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 25

27 SUBENGINE 타입선택하기 (CMP Bean Only) 이옵션은 CMP에서만사용될수있다. Jeus-ejb-dd_< 모듈명 >.xml 파일의 <subengine-type> 에아래두가지옵션중하나를선택하여넣을수있다. 업무성격을파악하여주된데이터접근방법을알아내어옵션을선택하도록한다. ReadLocking Bean의성격이 Read 작업이많은경우 Shared Read를허용하여동시에데이터에 Access할수있도록한다. Read 작업이많은경우 Concurrency를높혀성능을향상시킬수있다. WriteLocking Bean의성격이 Write 작업이많은경우 Lock Promotion 등으로인한 Deadlock 상황을방지해줄필요가있다. Write작업이많을경우데이터를읽을때, Write Lock을잡고작업을진행하게하여, Concurrency는낮추지만 Deadlock 발생빈도를낮춤으로써전체적인성능향상을꾀할수있다. Jeus-ejb-dd_< 모듈명 >.xml 파일의설정예는아래와같다. <jeus-ejb-dd> <module-info> <module-name/> </module-info> <beanlist> <container-managed> <ejb-name>pkproduct</ejb-name> <export-port>0</export-port> <export-name>pkproductapp</export-name>... <engine-type>single_object</engine-type> <subengine-type>writelocking</subengine-type>... </container-managed> </beanlist> </jeus-ejb-dd> JEUS Performance Tuning 26

28 Note : 엔진타입및서브엔진타입선택에대한기준을시스템성격에따라아래그림으로표현하였다. 동시접근유저수 작다 많다 데이터접근경합많다. 트랜잭션시간길다. 아니다 그렇다 Exclusive Access Single Object Multiple Object Read 가많다 Write가많다. Read 가많다 Write가많다. Read Write Read Write locking locking locking locking JEUS Performance Tuning 27

29 Fast Deploy & EJBCompiler 이방법은이전의튜닝옵션과다르게런타임성능향상이목적이아니고, Deploy과정을단축시켜부팅을빠르게하는방법이다. EJB 모듈로구성된시스템을생각해보자. 엔진이부팅될때마다 EJB 모듈을 Deploy해야되는데, 보통의경우 EJBMain.xml의 <ModuleList> 항목에 EJB 모듈을추가하여엔진이부팅될때, 모듈이 Deploy되도록설정을한다. 모듈이 Deploy되는과정을살펴보면, 먼저 EJB Object와 Home Object 그리고 Skeleton, Stub등의코드를생성한후이를컴파일하고, 이모듈의 Container 인스턴스를하나만들어서이를 EJBServer 에등록하는과정을거치게된다. 위의모듈 Deploy과정은최초한번은반드시수행되어야된다. 이를이후에다시 Deploy하는데, 모듈수정이없는경우 ( 좀더정확히말하자면, Home과 Remote의인터페이스가변하지않는경우 ) Deploy 과정중에서 EJB Object와 Home Object의코드생성및컴파일과정은다시할필요가없다. 이러한경우 ( 모듈의 Deploy과정이전체적으로한번수행되고, 그이후 Home과 Remote 인터페이스가변하지않는경우 ) EJBMain.xml의 <FastDeploy> 항목을 true로설정하면엔진은 EJB Object와 Home Object의코드생성및컴파일과정을생략하고 Deploy작업을진행한다. <FastDeploy> 옵션은실제로시스템의운영중 Performance에는영향을미치지는않는다. 하지만운영중엔진을새로이부팅시킬필요가있을때, 빠른시간내에모듈을 Deploy하여엔진의부팅시간을단축시킬수있다. 특히많은 EJB 모듈을가지는시스템의경우이옵션의사용을권장한다. 실제로수백개의 EJB 모듈로구성된시스템의경우부팅작업은상당히오랜시간동안진행된다. 시스템을운영하다보면특정 EJB 모듈을수정할상황이발생한다. 이경우모듈을수정하고클래스를컴파일한다. 그다음으로모듈의 Redeploy 작업이필요하다. EJB 모듈의수정작업에서 EJB모듈의 Home과 Remote의인터페이스가변했다면, Deploy 작업중 EJB Object와 Home Object의코드생성및컴파일과정이반드시이루어 JEUS Performance Tuning 28

30 져야된다. 이런경우 EJB 모듈의 Deploy 에는세가지방법이있다. 첫째, ejbadmin 을사용하여엔진을내리지않고모듈을 undeploy한후다시 deploy하면된다. Deploy시 f (FastDeploy) 옵션을사용하지않아야한다. 둘째, 엔진을내리고 EJBMain.xml의 <FastDeploy> 옵션을 false로하여부팅시코드생성및컴파일과정이일어나도록한다. 셋째, ejbcompiler를이용해 EJB Object와 Home Object의코드생성및컴파일과정을거치게하고 EJBMain.xml의 <FastDeploy> 옵션을 true로설정하여부팅을한다. 첫번째방법은 Runtime에 EJB 모듈을 Redeploy하는방법이다. 두번째와세번째방법은다음엔진부팅시에수정한모듈의 Redeploy작업을하는방법이다. 다음엔진부팅시에수정한모듈의 Redeploy를원할경우두번째방법은비효율적이다. EJBCompiler를이용하는세번째방법으로부팅시간을단축하는것이더효율적이다. 정리하자면 EJBCompiler는 EJB Object와 Home Object의코드생성및컴파일과정을수행하는툴이다. 이를이해하고적절히사용하면부팅시간을단축시킬수있다. EJBCompiler 사용법은아래와같다. %JEUS_HOME%\bin\ejbcompiler ejbcompiler command usage : ejbcompiler [engine name] [modulename modulename::beanname] [options] options -xml : use ejb-jar-modulename.xml and jeus-ejbdd_modulename.xml as deployment descriptor -v : verbose JEUS Performance Tuning 29

31 VII. Servlet/JSP Tuning 본장에서는 JEUS Servlet 엔진에서의성능향상을위한방법을다루어보도록하겠다. 앞으로다룰 JEUS Servlet 엔진의튜닝방법종류를아래에열거하였다. Session Routing Handler Thread Pool JSP Batch Compiler Servlet/JSP Auto Reloading Connection Pooling 관련 JDBC Connection Pool WebT Connection Pool WebServer와의연결관련 WebToB Apache Session Routing Servlet 표준의 Session은세션정보를웹컨테이너가관리해주고 Cookie에는단지 Session Key만이실리게되어기존의 Cookie 방식에비해네트웍사용량을크게줄여성능을향상시킨다. Session Routing 기법은 JEUS 웹컨테이너의웹서버로서 WebToB나 Apache를사용하고웹서버에다수의 JEUS 웹컨테이너가클러스터링되었을경우사용할수있는기법이다. 기본알고리즘은 Apache Web Server와 Jserv servlet engine 사이에서제공하는 load balancing 기법과동일하다. 세션객체를최초로생성한 JEUS 웹컨테이너는 session 구분자인 Cookie에자신의구분자 (servlet engine JEUS Performance Tuning 30

32 identifier) 를삽입한다. 웹서버는이 Cookie 값을조사하여세션객체가생성된 JEUS 웹컨테이너로클라이언트요청을 routing해준다. Session Routing 기법은동일한클라이언트가같은웹컨테이너에서서비스되도록하여클러스터링된웹컨테이너간통신량을줄여준다. 아래는 container.xml 파일에 SessionRouting 을설정하는예이다. <DistributedSession SessionRouting="true"> <SessionServer ServerName="session1" BackupServerName="session2" InitCapacity="1" MaxCapacity="3" IncrementRate="1" TimeoutMilliSec="10000"> </SessionServer> </DistributedSession> Note : <Failover에관하여 > JEUS 시스템에서는 Web Container Cluster 내의 session 정보를효율적으로관리하고 Web Container간 load balancing 및 failover 를보장하기위해 Session Manager 를도입하였다. 하나의 Web Container 에서 session 이생성되면해당 Web Container 는이 session을자신의 Session Cache 에저장하고설정된 Session Manager에게 session 정보를전달한다. JEUS는이러한방법으로특정엔진이나노드가장애발생했을경우에도세션을유지시켜준다. JEUS Performance Tuning 31

33 JDBC Connection Pooling JEUS 에서 JDBC Connection Pool 을이용하는방법은두가지가있다. JEUS 시스템에서데이터베이스로의 connection 관리를담당하는 JDBC 표준의 DB Connection Pool은 Naming & Directory 서버에등록되어 JEUS Cluster 어디에서는접근가능하고 JEUS Transaction Manager와연동하여트랜잭션관련정보를관리하는등다양한기능을제공한다. 클라이언트가이를이용하기위해서는 JeusMain.xml에설정을하고 JNDI API를이용해접근한다. 하지만만약어플리케이션이 HTML, Servlet, JSP 등으로만구성된 presentation 중심의구조에간단한데이터베이스작업만을수행한다면 Web Container 전용의 Connection Pool을사용할수있다. 이 Connection Pool은 JDBC 표준에서제시하는 Connection Pooling 메커니즘을따르지않고보다가볍고간단한구조를사용하여 JEUS 시스템의무게를줄이고, 불필요한리소스의낭비를막는다. 클라이언트가이를이용하기위해서는 container.xml에설정을하고 JDBC DriverManager로로딩한후사용한다. 아래에 container.xml 에 DB Connection Pool 설정예를보였다. <DBConnectionPool ConnectionPoolID="sharedOraclePool" ConnectionPoolType="shared" " DriverClassName="oracle.jdbc.driver.OracleDriver" ConnectionArguments="user=username;password=password" CloseLongActiveConnection="true" MaxActiveTimeSecs="60"> <DBPoolControl InitCapacity="2" MaxCapacity="10" IncrementRate="2" MaxIdleTimeSecs="300"/> </DBConnectionPool> JEUS Performance Tuning 32

34 WebT Connection Pooling JEUS에서 WebT 라이브러리를이용해 TMAX를 Access할수있다. 이럴경우 JDBC Connection Pooling과마찬가지방법으로 TMAX와의 Connection을풀링하여이용할수있다. 이에대한장점은 JDBC Connection Pooling과같다. 아래에 container.xml에있는 WebT Connection Pooling 설정예를보였다. <WebtConnectionPool LogLevel= info LogFileName= c:\jeus30\logs\webt.log > <WebtConnectionGroup ConnectionGroupID= tmax1 TmaxAddress= TmaxPort= 8888 InitCapacity= 10 MaxCapacity= 40 IncrementRate= 2 /> <WebtConnectionGroup ConnectionGroupID= tmax2 TmaxAddress= TmaxPort= 8888 InitCapacity= 10 MaxCapacity= 40 IncrementRate= 2 /> </WebtConnectionPool> Servlet/JSP Auto Reloading 실제 WEB-BASED 시스템을운영하다보면프리젠테이션이나비즈니스로직을수정할경우가발생한다. 이럴경우특정모듈에수정을가하고엔진을리부팅하는것은시스템의 Availibility측면에서바람직하지않다. JEUS는 Servlet/JSP Auto Reloading기능을제공하여모듈수정시엔진리부팅을하지않고해당모듈이속해있는 Context만다시 Reload를하게할수있다. 모듈이있는디렉토리밑에있는하위모든디렉토리를모니터링하는쓰레드가있어모듈수정으로인한파일의변경이일어났는지를감시하고, 변경이있다면해당 Context를다시 Reload한다. 이기능은모듈수정이빈번한경우매우유용한기능이다. 하지만 Auto Reloading을위한디렉토리의파일감시작업도엔진에는 JEUS Performance Tuning 33

35 오버헤드가된다. 시스템의수정이없는경우라면, 그리고안정되고빠르게운영하려한다면 Auto Reloading을위한오버헤드를없애주는것이성능향상에도움이될것이다. 이러한경우 Container.xml을아래와같이설정하여 Auto Reloading 기능을사용하지않게할수있다. <Container MonitoringIntval="300" SessionMonitoringIntval="120" RedirectStdOut="true" RedirectStdErr="true"> <ContextGroup GroupName="MyGroup" GroupDocBase="webapps" SharedSession="true" SessionTimeoutMinute="20" PrintErrorToBrowser="true">.... <Context ContextName="Examples" ContextPath="/examples" DocBase="examples" EnableJSP="true" AutoReload="false"> </Context>.... </ContextGroup> </Container> JEUS Performance Tuning 34

36 JSP Batch Compiler 개발자가 JSP파일을작성하고이 JSP파일을실제운영시스템에 Deploy했다고하자. Servlet 엔진은최초이 JSP로의요청이있을때이 JSP파일을파싱하고이를 Servlet코드로바꾸어준다. 그다음 Servlet코드를컴파일하고이를클래스로더가로딩하게한후인스턴스를하나만들고 service() 메쏘드를실행시킨다. 이후두번째요청부터는만들어진인스턴스의 service() 메쏘드를부르기만하면된다. 위에서보듯이 JSP의최초서비스절차는상당히많은절차를거치기때문에클라이언트입장에서는비교적긴시간을기다려야결과를볼수가있다. 만일 JSP의수정이빈번하거나그양이많다면, 위에서언급한절차가엔진에오버헤드를줄뿐아니라클라이언트응답시간도길어진다. JEUS는 JSP Batch Compiler를제공하여 JSP파싱, Serlvet코드생성그리고생성된코드컴파일과정을미리작업하도록하여, JSP로의최초요청시엔진오버헤드방지및성능개선을하도록하였다. JSP Batch Compiler는 ContextGroup 또는 Context 단위로해당단위내에있는 JSP파일을 Servlet 클래스파일형태로만들어준다. 아래 JSP Batch Compiler 의사용법을간략히적어놓았다. %JEUS_HOME%\bin\jspc JEUS Web Container version: jspc -e engine_name [-g grpname [-c ctxname]] [-noxml] [-f container_xml_path] - pre-compile the jsp files of context ctxname of contextgroup grpname - if ctxname omitted, entire contexts of grpname will be pre-compiled - if ctxname and grpname omitted, entire contexts of engine_name will be pre-compiled -noxml configuration by.conf file -g context group name to compile -c context name to compile -f config_file configuration file name -h this message -v version information JEUS Performance Tuning 35

37 WebServer 와의연결 JEUS의 Web Service는 HTTP요청을 WebServer에서받고이를파싱하여 Servlet이나 JSP 요청의경우 JEUS의 Web Container에넘겨주는구조로되어있다. 많은유저를빠르고효율적이게처리하기위하여 JEUS는크게두가지의아키텍쳐를수용하고있다. 첫쨰, ThreadPool을사용하여클라이언트요청이들어왔을때, 매번새로운쓰래드생성오버헤드를줄이고쓰래드를재사용하게하였다. ThreadPool 크기의설정은 Web Container의성능에매우영향이크다. 둘째, WebServer와 Web Container사이에 Queue를두어서 ThreadPool에서당장처리할수없는클라이언트요청을잠시 Queue 에두고쓰레드가 ThreadPool에반환되는시점에처리가되도록하였다. 이렇게함으로써동시에많은클라이언트요청을수용하여 Availibility를높혔다. 앞에서설명한 OS의 TCP레벨에서도 Backlog 크기를늘려주는작업도같은목적으로하는설정이다. 이두가지의설정을동시에고려해주어야하겠다. JEUS Performance Tuning 36

38 JEUS에서사용할수있는 HttpServer는크게세가지가있다. 각각의경우에대하여간단한설정예를아래에보였다. JEUS 에내장된 HttpServer 와의연결 <Connection ListenerType="HttpListener" Port="8088" ServerAccessControl="false"> <ThreadPool MinThread="2" MaxThread="10" ChangeRate="2" MaxIdleTime="300" MaxWaitQueue="4" /> </Connection> Apache Server 와의연결 <Connection ListenerType="ApacheListener" Port="8007" ServerAccessControl="false"> <ThreadPool MinThread="2" MaxThread="10" ChangeRate="2" MaxIdleTime="300" MaxWaitQueue="4" /> </Connection> WebToB 와의연결 <Connection ListenerType="WebtobListener" Port="9900" WebServerAddress=" " ConnectionPortNum="2" ServerAccessControl="false"> <ThreadPool MinThread="10" MaxThread="10" ChangeRate="2" MaxIdleTime="300" MaxWaitQueue="4" /> </Connection> JEUS Performance Tuning 37

39 VIII. JEUS Application Tuning 이제까지시스템의성능을향상시키기위한 OS, Network, JVM 튜능방법및 JEUS 엔진튜닝방법에관하여다루었다. 여기에추가하여 Application 튜닝도빠질수없는부분이다. Application이성능을고려하여만들어지지않았다면위에서언급한모든부분을모두고려하였다할지라도시스템의성능이어떻게나올지는뻔한일이다. Application 튜닝에관련된부분은본문서에서다루기에는그범위가너무넓고다양해서구체적으로다루지는않겠다. 개략적인몇가지만을다루고자하므로이외의내용은관련문서를참조하기바란다. Application 디자인과정부터성능을생각하라. Application 튜닝은개발이모두끝나고나서하는것만이아니다. 디자인부터잘못된 Application은시스템에치명적인 bottleneck 이될수있을뿐아니라쉽게고치기도어렵다. 복잡한코딩으로성능을향상시킬수있는경우보다도간단한디자인하나가성능을놀랄만큼향상시키는예를많이볼수있다. 디자인단계부터성능을생각하라. Design Pattern을적용하라. Design Pattern이란시스템디자인시에자주발생하는문제들에대한 재사용가능한해결책 이라할수있다. 이는경험많은소프트웨어엔지니어들로부터동일한해법들을이름을부여하고디자인을추상적으로정리한것이다. 이미검증되고적용한사례가많은것이므로이를이용하는것은극히추천할만하다. 엔지니어입장에서는효율적이고유용성이좋은디자인에대한해법을짧은시간에익히고얻어이를적용하면자신이디자인하고있는시스템의안정성과성능을높일수있다. Design Pattern에는성능에크게도움을주는내용도많이있다. 특히근래에는 J2EE아키텍쳐에서적용할수있는 J2EE Pattern 들이많이나오고있다. 예를들어모듈간의통신시데이터를 Coarse-Grained 하게주고받아 Network Traffic을줄인다든지, Bean간의 Coupling이높은경우에 Dependent Object를고려하여디자인한다든지, 비동기적 (Asynchronous) 으로작업이가능한 JEUS Performance Tuning 38

40 경우 Message-Driven Bean Façade를사용한다등등 성능향상에도움이되는검증된디자인이많이있다. 단지성능뿐아니라유지보수를위해서그리고확장성및재사용을위해서 Design Pattern의적용을적극활용하라. J2EE Architecture를이해하라. 너무도당연한이야기이겠지만 Servlet 아키텍처를충분히이해하지않고 Servlet을작성하는것, EJB 아키텍처를충분히이해하지않고 EJB Bean을작성하는것은상당한위험한일이아닐수없다. 예를들어 Servlet을작성하는데 Thread Safty를제어하는일을 SingleThreadModel을이용하여처리한다면 Thread Safty는확실히지켜지겠지만성능은매우낮게나올것이다. EJB 작성시 Stateless Bean으로작성해도되는일을 Stateful Bean 으로작성하거나 Entity Bean으로작성하면불필요한리소스낭비가되고낮은성능을낼것이다. 원래의 J2EE 아키텍쳐가지향하는바를제대로이해하지못하고이를이용하면효율적인시스템이구축되지않을것이다. 데이터베이스 SQL 튜닝을고려하라. 시스템구축시데이터베이스를사용하는경우는비일비재하다. 데이터베이스를 Access하는 Application의경우 Table 디자인을어떻게하는가, Index를어떻게만드는가, SQL문장을어떻게작성하는가에따라엄청난속도차이를보이는상황을자주볼수있다. 데이터베이스그리고 SQL의데이터베이스내처리과정등의이해가깊어질수록성능이좋은시스템을구축할수있다. J2EE 아키텍쳐에는효율적인리소스관리, Concurrency관리, 트랜잭션관리등성능을위한뛰어난개념들이많이있다. 그리고 JEUS는이 J2EE 아키텍쳐를수용하고또추가적인많은성능향상관련기능들을제공하고있다. 하지만 J2EE 아키텍쳐그리고 JEUS는요술방망이가아니다. 이 Platform위에올라가는 Application을어떻게작성하는가? 그리고시스템이운용되는환경을어떻게구성해주어야하는가? 라는질문에대한답은넓은부분에있다는것을알수있었다. 다양한튜닝포인트를고려하고이를위한꾸준한노력을할수록효율적이고빠른시스템을얻을수있을것이다. JEUS Performance Tuning 39