ORACLE 9iAS Performance Tuning Getting the most out of MetaLink 박준현 한국오라클 ( 주 ) 제품지원실 오늘세미나에서는 ORACLE 9iAS 를사용하시면서접하시게되는 performance 문제와관련하여어떻게접근을해야하는지와또한어떠한사항을고려해야하는지에대해초점을맞추어진행하도록하겠습니다. 그럼 ORACLE 9iAS Performance Tuning 세미나를시작하겠습니다. Page 1 1
Agenda Tuning Approach OC4J & JDK Issues Tuning with Oracle HTTP Server (OHS) Tuning with Web Cache Load Balancing Conclusion 본세미나에서는웹기반시스템의성능향상을위한구체적인내용들을다루고자합니다. 비록그것이 Oracle9iAS 에초점이맞추어져있지만일반적인웹기반시스템과크게차이가나지는않습니다. 이론적인부분은가급적피했으며여기에서사용되는방법들은바로적용해볼수있을것입니다. 현업에서바로적용, 성능의이득을볼수있다면이것이본세미나를듣고서가질수있는가장큰수확이아닐까합니다. Page 2 2
How to Tune? 1 Measure 2 Benchmark 3 Identify Bottlenecks 4 Reconfigure 5 Log everything 웹기반시스템의튜닝은종합예술이라고도한다. 그만큼그어느하나, 한분야만을알아서도안되고특정부분만을튜닝한다고해서전체적으로성능이향상되는것도아니다. 시스템에문제가있다면, 즉 Oracle9iAS 가비즈니스적기대치에미치지못하고있다고판단한다면다음과같은과정을통해서성능향상을이끌어낼수있을것이다 1) Measure 문제가무엇인지수치적으로모니터링하고표본을추출한다. 이단계에서본세미나에서알아볼 ART, TPS 를계산해내야하고추가로 CPU, Memory 사용량도조사한다. 2) Benchmark 측정된수치를가지고실제로타시스템과비교를해본다. 또한 Stress Tool 을사용하여현재시스템의성능을알아본다. 대표적인 Stress Tool 로는손쉽게사용할수있는 MS Stress Tool 이나 Grinder 가있고, 보다 Detail 하게성능에대해분석을하고싶다면 etest 나 Load Runner 등이있을수있다. 이단계에서 Application code 도재검검을해야하는데일반적으로가장많이시간소요가발생하고있고또한가장많은성능향상을기대할수있다. 3) Identify Bottlenecks 전반적인시스템의어느부분에서 Bottleneck 이걸리고있는지를세분화하여찾아낸다. 4) Reconfigure 선행과정에서의심이가는부분이찾아졌다면해당부분에대한튜닝요소를추출하고이에대해재설정작업을한다. 5) Log everything 문제가있다면반드시로그에남게된다. 모든로그들을찾아내서에러나문제점이없는지를확인한다. 이상의과정은상당한노력과인내력이필요한부분임에는틀림없다. 그렇지만위의과정은시스템의적절한성능향상을이룰때까지계속반복해서이루어져야한다. Page 3 3
How a request works Client Browser Web Cache Apache App Server Database 1 2 3 4 5 9 8 7 6 1. Client가 HTTP 요청 2. 캐시에해당하는객체가존재하면 Web Cache는바로응답 3. 캐시에없으면 request를 Apache에넘긴다 4. Apache는 App Server에해당객체를요청 5. App Server DB query를포함하여객체에대해결과를재생성 (generating) 6. App Server는 Apache에게해당결과를보낸다. 7. Apache는해당결과를Web Cache에게보낸다. 8. Web Cache는결과가오면다음에재호출을위해해당결과의복사본을유지 9. Web Cache는해당결과페이지를압축하고나서 Client에게보낸다. How a request works? 이것은일반적인웹기반시스템에서의 request flow 이다. 그렇다면 Apache 의역할은무엇일까? 1. Client 가 HTTP 요청한다. 2. 캐시에해당하는객체가존재하면 Web Cache 는바로응답한다. 3. 캐시에없으면 request 를 Apache 에넘긴다. 4. Apache 는 App Server 에해당객체를요청한다. 5. App Server DB query 를포함하여객체에대해결과를재생성 (generating) 한다. 6. App Server 는 Apache 에게해당결과를보낸다. 7. Apache 는해당결과를 Web Cache 에게보낸다. 8. Web Cache 는결과가오면다음에재호출을위해해당결과의복사본을유지한다. 9. Web Cache 는해당결과페이지를압축하고나서 Client 에게보낸다. Page 4 4
Performance Terms Concurrency 동시에여러요청을처리할수있는능력 Latency 한시스템에 A component 가있고 B component 가존재할때, B 가완전하게자신의 task 를처리할때까지 A 가기다리는데걸리는시간 Response time 하나의요청이이루어져결과값이돌아올때까지걸리는시간 Throughput 단위시간당처리되는요청수 (req/sec) Think time 실질적으로시스템프로세스에서처리하지않고제외되는시간 Concurrent User 동시단말사용자수 or 동시접속자수 Active User + Inactive User TPS Transactions Per Second ART Average Response Times Concurrent User / TPS Think Time Saturation Point TPS 가최고가되기시작하는시점 Active User Active Threads라고도하며현재해당시스템을사용하기위한일련의목적으로한번이상호출했거나하고있는서비스의개수. 즉, 호출하여아직 response를받지못한사용자들. Inactive User 현재 request를수행하지않고있으며, 화면의결과를보고있거나다음요청을위해 form에필요한내용을입력하고있거나대기중인사용자. Think Time에해당하는사용자로분류될수있다. 시스템의관점에있어서는 Inactive User 는중요하지않다. 왜냐하면실제적으로시스템에부하를주지않기때문이다. 따라서보통부하테스트를할경우에는 Inactive User. 즉, Think Time 은 0 로놓고테스트하게된다. 그러나비즈니스적관점에서는상당히중요한데비록한번클릭하고나서커피를마시고있는사용자혹은다른일을하고있는 Inactive User 들의범위를어디까지설정하느냐에따라서 Concurrent User 가바뀌기때문이다. 1/(ART + Think Time) = 사용자당 TPS TPS * ART = 한시스템에요청된수 TPS * (ART + Think Time) = Concurrent User 수 Concurrent User 수 /TPS - Think Time= Average Response Time Page 5 5
Mission for Tuning Increase TPS Short ART 70 TPS 60 50! after Concurrent User TPS* Think Time 40 30 20 10 saturation point? Questions? 0 1 20 40 60 80 100 Threads 1) TPS 가 SP 를지나면서저하 -MaxClients 2) TPS 가좋아지면 ART 도함께짧아지나 웹기반시스템의튜닝목적은안정적으로보다빠르게서비스를하는데에있다. 이를수치화한다면 TPS를증가시키는것이고 ART를보다짧게가져가는것이다. 그러나 Saturation Point를높아진다고해서시스템이안정적이라고는할수없다. 1) Saturation Point 를지나서 TPS 가떨어지는이유는? 일정정도의 Concurrent User 이상에서는시스템이급격히성능이떨어지고있다. 이는시스템의 Latency 가좋지않으며이를개선하기위해서는 request 가들어올때이것들을큐에쌓거나해서 Throughput 을유지한다. Apache 에서 MaxClients 옵션을사용한다. 2) TPS 가좋아지면 ART 도개선되나? 그렇지는않다. 공식에서보면 TPS 가높아지면 ART 는짧아지지만이는 Saturation Point 이전까지만이다. TPS 만을올린다고해서성능이향상되는것은아니다. 안정성이뒷받침되어야하며이를위해서는어떤작업들이선행되어야하는지를본세미나에서구체적으로알아본다. Page 6 6
Oracle9iAS Architecture Web Tier Application Tier Database Tier Web Cache Apache JSP Browser Apache JVM Servlet EJB Database Wireless & Mobile Oracle9iAS Containers for J2EE (OC4J) Oracle9iAS 의기본적인핵심구조는 Web Cache Apache OC4J 이다. OC4J 는 J2EE 기반 Application 의핵심이며모든비즈니스로직이포함되어진다. Apache 는 J2EE Application 의앞단에존재하며모든 request 를조절하는역할을한다. 그리고 Web Cache 는반복되거나자주 request 되는내용들에대해서 OC4J 의부하를줄이고보다빠른서비스를보장하기위해 OC4J 혹은 Apache 의앞단에위치한다. 시스템구조는다양하게구성할수있는데, 대부분의고객들께서시스템을구현하는경우많이사용되고있는대표적인 4 가지예를참고해보도록하겠다. -OC4J standalone 시스템부하가적거나 J2EE only Application 서비스에적절하다. -Apache OC4J 보편적인구조로 Apache 는 Load Balancer 역할수행한다. 또한 J2EE 이외 CGI, PERL, PL/SQL 이존재할경우적절하다. -Web Cache Apache OC4J 일반적으로정적인데이터 ( 이미지등 ) 가많은경우효과가크며 Web Cache 와 OC4J 를분리할수있다. -Web Cache OC4J 대량의 request 가있는경우에효과적이며이경우 Web Cache 가 Load Balancing 을수행한다. Page 7 7
How to Find Tuning Point? Browser L4/GW Web Cache Apache JVM Database tcpset.sh httpd.conf mod_oc4j.conf webcache.xml server.xml.java_wrapper opmn.xml data-sources.xml 각각의 Tier 를단순화 (OC4J -> Apache -> Web Cache) 반복적인부하테스트및에러로그확인 모니터링툴활용 튜닝포인트를어떻게찾을것인가? 우선튜닝을하기전에튜닝포인트를어디에관점을두고할것인지, 또한과연튜닝포인트의초점이제대로맞추어진행되는인지를파악하는데는여러번의시행착오끝에나올수있다. 여기서는이러한시행착오를줄이기위해체크해야할사항에대해알아보도록한다. 1) Overload 가어디서걸리는지찾기위해서 Web Cache, Apache 를연결하지않고 OC4J 만을가지고부하량을체크한다. 즉 OC4J standalone 관점에서접근하는데.java_wrapper, opmn.xml, 그리고 DB 연결에관여하는 data-sources.xml 의 parameter 를변경한다. 이작업은반복적으로이루어져야하기에많은시간이필요로할것이다. 2) OC4J 에서일정정도최대의대역폭, 최대의성능을도출해내었다면 Apache 를붙인다. 이단계에서는 tcpset.sh, httpd.conf, mod_oc4j.conf 등이튜닝대상이다. 3) Apache-OC4J 관계에서튜닝이끝나면 Web Cache 를붙인다. Web Cache 를튜닝을위해서는 http://host:4444/ 로접속하여 Web Cache Manager 에서 parameter 를수정, 튜닝을한다. 4) 이상과같은과정을거치면서 Bottleneck 을찾아서제거한다. 5) OS, Network 대역폭, DB query 튜닝도반드시이루어져야한다. 6) CPU, Memory 의증설은보다효율적으로성능향상을할수있음을잊지말아야한다. 위의경우는각단계별로체크할사항에대해알아보았지만, 이와더불어각단계에서사용될각각의 configuration file 에서사용될파라미터는미리매뉴얼을참고하여각파라미터의의미와적절한값의범위등에대해서도알고있어야하겠다. Page 8 8
Monitoring Tools aggrespy 특정시점에서빠르게성능요소를추적 결과값을성능지표로삼기에는부적합 http://hostname:port/dms0/spy (standalone) http://hostname:port/dmsoc4j/aggrespy dmstool 일정주기의시간단위로성능요소를추적 성능개선을위한도구로적합, 적극활용 스크립트를만들어사용하면효율적 Check: DB connections, Response Times, Completed operations 앞에서의기본적인개념을가지고구체적으로각부분에대해서모니터링할필요가있다. 이때 Oracle9iAS 에서는다음과같이 2 가지의모니터링도구를제공하는데 dmstool 이가장적절하다. 이는일정시간동안의부하량을측정할수있다는장점이있다. Page 9 9
dmstool Collect 100 sets at 60 second intervals dmstool -i 60 -c 100 \ /appsvr/apache:2534:6004/apache/handle.completed \ /appsvr/apache:2534:6004/apache/request.completed >> t1.out Output Listing /appsvr/apache:2534:6004/apache/handle.completed 240320 ops /appsvr/apache:2534:6004/apache/request.completed 146504 ops /appsvr/apache:2534:6004/apache/connection.completed 56908 ops 매분마다 Apache components (handle, request, connection) 의 completed 통계치 dmstool 에서옵션 -i 는 time interval 을 c 는횟수를나타낸다. Oracle9iAS 관련모든 components를추출하는경우 $ dmstool dump 현재각 modules, component별로 completed인 metrics를추출하는경우 $ dmstool l grep completed Page 10 10
# of JVM in an Instance OC4J Instances Results 1 and 2 JVM instances Apache mod_oc4j AJP AJP --- JVM JVM TPS 400 350 300 250 200 150 기본설정은 1 JVM 필요이상추가는 CPU 병합 CPU 갯수의 2 배수가적절 시스템성능의안정성확보 100 50 With 1 OC4J With 2 OC4Js 0 100 300 500 Number of Users $ORACLE_HOME/opmn/conf/opmn.xml <island id="island" numprocs="2 /> mod_oc4j Apache와 OC4J 사이에는 mod_oc4j가놓여있다. 이는 URL Binding을담게되는데여기에서특정페이지 ( 확장자기준 ) 을제어할수있다. 예를들면 jsp 파일에대한 request만을 OC4J로 redirect하고자한다면다음과같이 mod_oc4j.conf에서설정한다 Oc4jMount / *.jsp 이는 static 한 html 페이지나이미지파일들을굳이 OC4J 로넘겨서 OC4J 에게부하를줄필요는없다. 현재 OC4J Instance가하나라면이것을증가시킨다. 즉 JVM이 1개와 2개의차이는매우크다. 이경우각각의 JVM에서발생하는 log 파일들은각각존재하게된다. Page 11 11
JVM HotSpot HotSpot Architecture Results w/ and w/o server option Client Compiler Server Compiler 350 300 250 TPS 200 150 VM Runtime Garbage Collector Bytecode Interpreter Memory Management Thread and lock subsystems 100 50 With -server Without -server 0 100 300 500 Number of Users $ORACLE_HOME/opmn/conf/opmn.xml <java-option value= -server /> JAVA VM HotSpot 은크게 Compiler 와 Runtime 으로구분할수있다. Runtime 영역이존재하는 Virtual Machine 영역에는 Garbage Collector, Bytecode Interpreter 등과같은기능등이수행된다. 그리고 Application 은컴파일과정을통해수행되게되는데이때사용자는 compiler 를선택할수있다. Client VM compiler Java applications이나 applets이많다면이옵션을사용한다. 즉 Java GUI 환경에적절하다. Java HotSpot Client VM은 Java application의기동시간을대폭줄여주며보다적은메모리를사용한다. Server VM compiler JSP, Servlet, EJB와같은 Server side Java application을운영하고자한다면 server 옵션을사용한다. Page 12 12
JVM Parameters 각벤더에따라조금씩다름 -Xms -Xmx -Xss -verbosegc -JIT Same/Different of Xms and Xmx TPS 350 300 250 200 150 100 50 With -ms=256m, -mx=256m With -ms=128m, -mx=256m 0 100 300 500 Number of Users Setting Xms = Xmx, why? $ORACLE_HOME/opmn/conf/opmn.xml <java-option value= -Xms256m Xmx256m /> Heap 은모든 Thread 들이공유하는영역으로 Heap 에는모든클래스인스턴스와배열들이저장되게되는메모리의 Runtime Data Area 이다. 그리고각각의 Thread 들이개별적으로가지고있는메모리영역이있는데이를 Stack 이라고한다. -Xmxn -Xssn Pool 에할당되는최대의메모리값으로단위는바이트이다. 기본값은 64MB 이며 2MB 보다크게 1024 의배수배이다. 단위인 m 이나 M 은 megabytes 를뜻하며대소문자구분은없다. JDK 1.3 에서 Limit 는 4GB (Solaris 7, 8), 2G (Solaris 6, x86) 이다. 쓰레드스텍사이즈이다. 각각의 Java thread 는두개의 stack 을가지게되는데, 하나는 Java code 이고다른하나는 C code 를위한것이다. Xss512k 라고한다면 stack size 의 max 값은 512k 이고이값은 C 코드에의해사용되어진다. n 의기본단위는 bytes 이고 n 은 1000 bytes 보다커야한다. 기본스텍사이즈는 512 kilobytes 이다 (-Xss512k). Page 13 13
Heap & GC GC 가빈번하게발생 Heap size가작아새로운 Thread 생성시필요한가용메모리할당에부하발생 이때시스템은서비스 panic 상태 Heap size의증가 Applications code 튜닝 Garbage Collector OutOfMemoryError GC 에의해이용가능한영역보다더많은 heap 이요구되어지는경우 Heap size 의증가 Heap은 JVM이기동시에생성되어진다. 객체들을위한 Heap 저장공간은 Garbage Collector에의해서선언되어진다. 객체들은결코명시적으로해제되어지지않는다. Garbage Collector는특별한형태로지정되어있지않고 JVM 구현자의시스템요구사항에따라서 GC 알고리즘이선택되어질수있다. Heap은고정된크기로되어지거나계산에의해서요구되어지는만큼확장되어질수있고큰 Heap이불필요해지면줄어들수도있다. Page 14 14
Use JDK 1.4 than 1.3 JDK 1.3 을사용해야한다면 Updated 버전사용 1).java_wrapper 수정 $ORACLE_HOME/jdk/bin/.java_wrapper #PRG=$0 PRG=/usr/local/java131/bin/java $ORACLE_HOME/jdk/jre/bin/.java_wrapper #PRG=$0 PRG=/usr/local/java131/jre/bin/java 2) opmn.xml 에 java-bin 추가 $ORACLE_HOME/opmn/conf/opmn.xml <java-bin path= /usr/local/java131/bin/java /> 가능하다면 JDK 1.4 를사용 위의 2) opmn.xml 수정방법이용 <java-bin path= /usr/local/java142/bin/java /> $ORACLE_HOME/jdk/lib/tools.jar 를 JDK1.4 의그것으로대체 다음은 Metalink 를통해서확인할수있는문서로써기존 JDK 를 1.4 로올리기위한또다른방법이다. 다음은 http://metalink.oracle.com 에서찾은 Note 번호 232496.1 를참조한내용입니다. 1. Stop all Oracle9iAS processes. 2. Rename ORACLE_HOME/jdk to something else( ex. jdk13). 3. Download J2SE version 1.4 from http://java.sun.com./j2se/1.4/ - See that you download the SDK version, not the JRE version - See that the self-extracting binary file version so that you can install the J2SE anywhere on your machine. 4. Following the instructions provided by Sun Microsystems install the J2SE 1.4 into the directory "9iAS_ORACLE_HOME/jdk". 5. Add the following lines to 9iAS_ORACLE_HOME/jdk/jre/lib/security/java.security: --------------------------------------------------------------------- # Oracle-specific definitionsauth.policy.provider=oracle.security.jazn.spi.policyprovider login.configuration.provider=oracle.security.jazn.spi.loginconfigprovider ---------------------------------------------------------------------- Note : The login.configuration.provider line already exists in the java.security file. Comment out the existing line by prefixing a # character at the beginning of the line and add the line with the Oracle-specific value. 6. Copy the jar files FROM : the old jdk(i.e. 9iAS_ORACLE_HOME/jdk13/jre/lib/ext ) TO : the new jdk(i.e. 9iAS_ORACLE_HOME/jdk/jre/lib/ext ) 7. Start all Oracle9iAS processes. Page 15 15
Oracle HTTP Server OHS OHS response time Browser Apache Apache Millisecond 80,000 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 OHS parameter tuning: httpd.conf OHS & OC4J relations: mod_oc4j.conf Network tuning: tcpset.sh 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 1 5 Only 1 OHS, 1CPU Active Connections 50 Tuning Oracle HTTP Server OHS의성능을평가하려면 static한페이지에대해 Concurrent User를증가시키면서스트레스를걸어보면쉽게알수있다. 이때주시해야할부분은 OHS response time이고, 이를짧게가지고가는것이튜닝의또다른목표이다. 만일현재 Concurrent User가 50이넘어서면서 response time이급격히증가한다면무엇이문제인가? 이것은이시스템의 Max throughput일수도있지만판단하기에는아직이르다. 대부분의고객이튜닝시간과하는부분이 OS 부분의튜닝관점이다. Oracle 9iAS 에서는이러한부분에대한최소한의 OS network 부분의 Tuning 관점에서설치시다음의 Shell 을제공하여준다. $ORACLE_HOME/Apache/Apache/bin/tcpset.sh TCP Setting 에서반드시해야할 TCP parameter 값을가지고있다. Page 16 16
OHS (httpd.conf) KeepAlive On Persistent connection 하나의 Client 가연결을맺으면 KeepAliveTimeout 동안세션을유지 HTTP/1.1 MaxKeepAliveRequests 100 Persistent connection 을허용할최대의 Clients 갯수 더이상의접속요청은 KeepAlive Off 모든접속요청에대해적용 : 0 StartServers 5 초기기동되는서버수 MaxClients 150 Concurrent Client 수 (httpd 프로세스수 ) 여유 httpd 프로세스가없을때추가의연결요청은 TCP/IP 시스템큐에싸임 소수사용자 & 지속적인사용 KeepAlive On MaxKeepAliveRequest KeepAliveTimeout 다수사용자 & 짧은사용 MaxKeepAliveRequests KeepAliveTimeout StartServers 또는 KeepAlive Off 그렇다면사내인트라넷, 쇼핑몰, 검색사이트는??? Persistent connection Clients가 request를보내기위해 socket을열게되는데이때해당연결을바로끊지않고일정시간유지하는것을말한다. 이는많은 request가있을경우총 response time을줄여주는효과가있는데이유는초기연결을할때드는초기화가한번밖에없기때문이다. KeepAliveTimeout HTTP 1.0의기본동작방법은세션연결후자료전송이끝나는대로세션을끊도록구성되어있다. 이는사용자가여러개의정보를전송시에재접속을위한오버헤드가과도하게발생하는문제점이있어이를개선하고자 KeepAlive라는 접속유지 방법을사용하는데이방법은세션연결후파일전송이끝나면 KeepAliveTimeout 시간동안세션을유지함으로써재전송시접속을위한오버헤드를감소시킬수있다. (HTTP1.0은옵션 /HTTP1.1에서기본 ). MaxClients Dynamic request에있어서시스템이부하가많이걸리고있다면들어오는 request들을네트웍상의 Queue에쌓이게하는것이성능에도움이된다. 이를위해서 MaxClients 값을감소시켜서 concurrent requests를조절한다. 결국 Apache 레벨에서는들어오는 requests 에대해적절하게조절하여 Bottlenecks 이되지않게하는것이관건이다. 소수사용자들이지속적으로사용하는대표적인시스템은사내인트라넷이될것이고이들은회사직원들로국한되어일상업무를처리한다. 즉 KeepAliveTimeout 을길게가지고가서재접속에대한오버헤드를줄인다. 그러나쇼핑몰인경우다수의사용자들이다수의요청을할수있다. 이경우에는 KeepAliveTimeout 을짧게가지고가면서새롭게접속하는유저들이 Waiting 하지않도록유도를한다. 그리고검색사이트같은경우불특정다수가특정시간대에국한하지않고일정하게 requests 가많이이루어지는특징이있다. 이경우 KeepAliveTimeout 을짧게가지고가는것도하나의방법이나 KeepAlive Off 가오히려답이될수가있다. Page 17 17
Monitoring mod_oc4j & http_core dmstool -table ohs_module -c 1 Name: mod_oc4j.c... decline.count: 13487 ops handle.active: 0 threads handle.avg: 3 usecs handle.completed: 13487 ops handle.maxtime: 8 usecs handle.mintime: 2 usecs handle.time: 43710 usecs Name: http_core.c... decline.count: 0 ops handle.active: 0 threads handle.avg: 0 usecs handle.completed: 0 ops handle.maxtime: 0 usecs J2EE 요청처리 Static 문서처리 http_core.c OHS로들어오는모든 static한요청을처리한다. http_core.c를모니터링하는것은조금은불명확할수있는데이유는 Web Cache에서 static한페이지들을캐시하고있다가요청에대해처리되는것들은여기에포함되지않기때문이다. 따라서보통은 static한페이지에대한프로세싱처리는 Web Cache에서담당하는것이일반적이다. 물론 Web Cache를사용하지않을경우에는당연히 http_core.c에대한모니터링은유효하다. mod_oc4j.c OC4J에대한모든 J2EE의요청을처리한다. 즉 *.jsp를했다면이는 OHS단에서 mod_oc4j.c 모듈을통해서 OC4J로전달되고그리고그결과를되돌려받게된다. 따라서 mod_oc4j.c에대해모니터링할경우얼마나많은 requests들이 OC4J로넘겨지고있는지를확인할수있기에매우유익하다. Page 18 18
Web Cache Tuning http://hostname:4000/ Requests 현재, 평균, 최고의 TPS 를보여준다. Backlog 는웹캐시가죽게되면이를바라보고있다가다른웹캐시를띄워준다. Errors 네트웍, 사이트의부하정도, 특정페이지의에러에대한정보를갖고있다. Misses 캐쉬되거나그렇지않는통계정보를담고있다. Compression 압축되어져저장되어있는 RAM 의총사용정보를보여주며, 웹캐시의효율성의척도를나타낸다. Add RAM 웹캐시가 HTML 과 XML 을 OHS 를통하여 Delivery 의비율향상 Improve latency 네트웍위에전달되는컨텐츠통합 Higher reliability 지리적으로캐시를분산 Oracle9iAS Web Cache Admin 페이지는 http://hostname:4000/ 이다. 특이하게도 webcache.xml이존재하지만 Web Cache만은 Admin Web Site를통해서환경변수나일련의수정작업을진행해야한다. 즉, webcache.xml을직접 notepad나 vi등의텍스트편집기를이용하여수정하면안된다. Page 19 19
Load Balancing Hardware 가장기본적인 Load Balance. OHS 와 OC4J 를서로다른장비에두거나추가. Web Cache Web Cache 와다수의 OHS, Web Cache 와다수의 OC4J Instances 의형태로구성. mod_oc4j OHS 와다수의 OC4J Instances 를구성 OHS to Database Listener 다수의 OHS 를두고, 다수의 DB 리스너로 Load Balance. Load Balancing 을구성할수있는경우는크게다음과같이있다. 1) Hardware 2) Web Cache 3) Mod_oc4j 4) Database Listener 5) DNS Round Robin Page 20 20
Summary Goals How Method Identifying Bottlenecks Check your code Configuring 9iAS Page 21 21
Q U E S T I O N S A N S W E R S 본기술세미나의내용과관련된기술적인문의는 Metalink 에서 itar 를등록을통하여지원을받으시기바라며, itar 등록시제목은 iseminar :????? 로하여등록하시면되겠습니다. METALINK를통한새로운iTAR 등록 http://metalink.oracle.com Title : iseminar METALINK에대한문의 1588-8501 전화후메뉴 6번 Page 22 22