슬라이드 1 - PDF 무료 다운로드

목 차 [ 기술노트 1 부 ] 서언 : 웹시스템안정화를위한기반 1. 데이터베이스의튜닝 1-1. Otimizer_mode와통계정보 1-2. SQL 문장의튜닝 1-3. Oracle Instance 튜닝 [ 기술노트 2부 ] 2. 웹서버의튜닝 2-1. TCP/IP kernel parameter 2-2. Source Code의분석 2-4. SQL*Net 환경의튜닝 3. 결언

2. 웹서버의튜닝 2-1. TCP/IP Kernel Parameter 일반적으로최초설치 (Install) 된운영체제 (Operating System) 는범용의목적하에 Kernel Parameter 설정이이루어진다. 따라서 Web Service 만을위한 Kernel Parameter 값은반드시최적화시켜야한다. 특히웹서버의성능에영향을많이주는 TCP/IP parameter setting 은 20~30% 정도의성능향상을가져올수있을정도로중요하다. 본장은웹서버의형태로운용되는유닉스서버의 TCP/IP 일반과 Tuning 에관한내용을기술한다 2-1-1. TCP connection initiation background TCP 는 reliable connection oriented protocol 이다. 즉 2 개의 machine 사이에데이타를주고받기전에 connection 이이뤄지는것이다. Adrian Cockcroft(Sun Performance and Tuning, Java and the Internet, 2 nd Edition 의저자 ) 는 TCP connection 의설명을 Phone Call 에비유를하였다. (dialing, talking, hanging up). Incoming Call 은수동적으로 (passive) open 되고 ( Server Part 에서아무런동작없이일어난다.) 그러나 Server 는 Call 을 Accept 하기위해서특별한프로그램이동작하고있어야한다. Outgoing Call 은 Server 에서시작되는데, 이것은능동적인 (active) open 으로분류된다. 이러한경우의예로서다른 host 에 rlogin 하는경우에해당이된다. Connection 의시작은 3-way handshake sequence 로구성이된다. 이러한 handshake process 는 round-trip 시간과모든 delay 에영향을받는다. 최초의 handshake 는 SYN(synchronize sequence numbers) 로구성된 incoming packet 이다. Server 는자신의 listen queue(tcp_conn_req_max_q0 on solaris, tcp_syn_rcvd_max on HP- UX) 에 entry 를만들고 connection 은 SYN_RCVD 상태로남게된다. Server 는고유한 SYN 을포함하는 acknowledges(ack) 를가지고 SYN packet 에응답을한다. Client 에서오는다음 packet 은 second SYN 에대한 acknowledge 이다. 두번째 SYN/ACK 를 client 로부터받고난다음에 connection 은 accepted listen queue (tcp_conn_req_max_q on Solaris, tcp_conn_request_max on HP-UX) 로이동한다. Read request ack Read request ack Timeo=11 ack Connection ack Timeo=22 늦게도착 Server Client Server Connection? Client 늦게도착

만약 client 가 SYN 을보내기만하고어떤 ACK 도받지않으면 time out 때까지 SYN_RCVD 상태로남게된다. 이러한 TCP 의작동원리는웹서버에서권장하는 tcp 파라메타를이해하는데충분한설명일것이다. 만약더자세한설명을원한다면아래참고자료를읽어보기바란다. 1. Solaris - Tuning Your TCP/IP Stack http://www.rvs.uni-hannover.de/people/voeckler/tune/en/tune.html 2. Sun Performance and Tuning, Java and the Internet, 2 nd Edition, Adrian Cockcroft, Richard Pettit ISBN 0-13-095249-4, 1998,pp.55-59 3. Tips For TCP/IP Monitoring And Tuning To Make Your Network Sing http://www.sunworld.com/swol-12-1996/swol-12-perf.html 2-1-2. TCP Kernel Parameter 의튜닝 UNIX 는사용자가 tune 을할수있도록하고있으며, 시스템운영중에도 TCP/IP stack 관련한다양한파라메타는 set 과 reset 이가능하다. 이러한작업은 ndd 명령어 (network device driver) 로가능하다. Ndd 명령은시스템재부팅없이변경이가능하지만, 변경한내용은시스템재부팅시 default 값이되기때문에시스템 start script 에넣어주어야한다. For Solaris Startup see : /etc/rc2.d/s69inet For HP/UX 11.x Startup see : /etc/rc.config.d/nddconf 본문서에서언급하는파라메타는 time interval 이다. 모든 interval 은 milisecond 단위이다 (e.g. 1000=1 second). 가. 현재설정된 TCP 커널파라미터의값확인 # ndd /dev/tcp \? 모든파라미터의현재설정값을 Display 한다. # ndd /dev/tcp tcp_close_interval 특정파라미터의현재설정값을 Display 한다. # ndd -set /dev/tcp tcp_conn_req_max_req 10240 특정파라미터의현재설정값을변경한다 2-1-3. Parameter Description tcp_conn_request_max Maximum number of outstanding inbound connection requests tcp_conn_req_max_q0 (Solaris) / tcp_syn_rcvd_max (HP) Handshake incomplete 상태의최대 connection 갯수. 많은수의 SYN 이몰려들때이파라메타에영향을줄수있고, 특별한알고리듬에의해서유효한 connection 이지속될수있도록한다. 즉, 현재큐에있는 connection 은방금초기화된것들다. SYN 는 client 에서도착되었고, TCP connection 은 SYN_RCVD 상태로된다. Connection 은 handshake 가완료되어야만 accept 된다. tcp_conn_req_max_q CPU time 을얻고 accept 를 return 받은 completed connection 의최대갯수

2-1-3. Parameter Description ( 계속 ) tcp_close_wait_interval(pre Solaris 2.7)/tcp_time_wait_interval(Solaris7 이후, HP-UX) default 240000 (according to RFC 1122, 2MSL), recommended 60000 possibly lower. 이파라메타는 TIME_WAIT interval 을나타낸다. 대다수의사용자가 local 에서사용한다면, 60000 ms 정도면충분하다. 그러나만일사용자분포가많다면, RFC 1122 에서조언하는대로 240000 정도가되야할것이다. tcp_slow_start_initial solaris 와는다르게 NT 4.0 에서는초기접속시작에대한응답을곧바로하지않기때문에시작에대한지연이발생한다. 그러나 NT 4.0 에서는 2 개의패킷이보내졌을때곧바로응답을하게된다. NT 와 Solaris 의구현상의차이점때문에생기는성능차이와높은응답시간때문에 NT client 가 Solaris Server 에접속할경우에는고속이나 LAN-bases 네트웍을이용하여접속하여야한다. Solaris 에서 Congestion Window 를 tcp_slow_start_initial = 2 로셋업하도록한다. tcp_recv_hiwat default 8192, recommended 32768 이파라메타는초기의 TCP reception buffer의최대크기이다. 명시된값은 MSS 의 2배까지될수있다. Buffer의 free space에서지정된 window size를검사할수있다. Reception window의크기는 remote peer에영향을준다. tcp_xmit_hiwat default 8192, recommended 32768, maximum 65535 LFN bulk data transfer 131071 or above ( 아래설명참조 ) 이파라메타는 initial send window 크기를휴리스틱하게결정하는데영향을준다. 실제값은 MSS의두배까지될수가있다. ( 예, 8760 = 6*1460). Solaris 에서는 65535 이상의값이가능하다. 만약 peer host가 RFC 1323 (http://www.merit.edu/internet/documents/rfc/frc1323.txt) 에의해구현이되었다면 buffer size를 65535 이상으로설정하여이득을얻을수있다. 그러나만약 host가 window scale option으로구현되지않았다면, window의한계는아직 64K 이다. tcp_conn_hash_size (Solaris Only) Solaris에서 tcp_conn_hash_size 파라메타는 connection backlog를지정하는데도움을준다. High connection rate에서 TCP data structure kernel의 lookup은매우비싼비용을치루고있고, server를느리게할수있는요소이다. 따라서이파라메타를늘려줌으써 hash table의크기를늘려서 lookup 효율을높여줄수있다. 이값은 active TCP connection을관리하는데사용되는 kernel hash table의크기이다. 큰값을가질수록많은접속을하고있는서버에서높은효율을갖는다. Solaris의경우 2의배수의값을갖을수있고, 256(default) 이가장작은값이고, 밴치마킹에서일반적으로사용되는값으로가장큰값은 262144이다. 더큰 tcp_conn_hash_size는많은메모리를필요로하지만, 많은접속을해야하는경우에는메모리에대한투자를고려해볼가치가있다. 이값은반드시 2의배수이어야하고 /etc/system 커널 configuration 화일에서조정할수있다. 따라서현재 size는 ndd로조회했을때 tcp_conn_hash 값을읽기만할수있도록되어있다.

2-1-4. Recommended Parameter 의설정본문서에서추천하는파라메타값은각운영체제 (Solaris, Aix, Hp-ux) 의 Administration / Performance and Tuning Section 을참조하고있다. 그러나시스템을위한최적의파라메타값은정해져있지않으므로반드시백업을수행하고나서테스트와 tuning 을하여야한다. 아래에서기술하는사항은최적의 tcp 성능을위하여어떻게파라메타값을설정하고이해하는데도움이될것이다. [ 약어설명 ]: MSL - Maximum segment lifetime,tcp segment 가 net 상에서존재할수있는최대기간 MSS - Maximum segment size LFN - Long Fat Network ( [RFC 1323] 에따르면 elephan(t) 로발음된다.) RFC - Request for comments, 문서시리즈로관련된실험을통하여최적의값들을추천한것이다. 가. Solaris Recommended Parameter 다음명령을통하여설정하며, 시스템리부팅시에도적용될수있도록관리한다. #set rlim_fd_max=8192 : /etc/system #ndd -set /dev/tcp tcp_close_wait_interval 60000 : /etc/rc2.d/s69inet

2-1-4. Recommended Parameter 의설정 ( 계속 ) 나. HP-UX Recommended Parameter /etc/rc.config.d/nddconf 파일에기록하여영구적으로적용된다. 나. AIX Recommended Parameter 다음명령으로현재파라미터값확인및설정 ( 수정 ) 이가능하다. #/usr/sbin/no a : 디스플레이 #/usr/sbin/no -o rfc1323=0 : 수정

이러한 TCP 권장파라미터는 Oracle 의 Apache(Httpd) 데몬운영시에도적용되고있다. 오라클이설치된서버의 $ORACLE_HOME/Apache/Apache/bin/tcpset.sh 파일을열어보면아래와같은내용이설정값으로되어있는것을볼수있다. [ora920:$oracle_home/apache/apache/bin]% cat tcpset.sh #!/bin/sh # Set tcp parameters to values for a web server on Solaris # get entries out of hash table ASAP case `uname -r` in "5.8") /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000 echo "tcp_time_wait_interval =" `/usr/sbin/ndd -get /dev/tcp tcp_time_wait_interval` ;; "5.7") /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000 echo "tcp_time_wait_interval =" `/usr/sbin/ndd -get /dev/tcp tcp_time_wait_interval` ;; "5.6") /usr/sbin/ndd -set /dev/tcp tcp_close_wait_interval 60000 echo "tcp_close_wait_interval =" `/usr/sbin/ndd -get /dev/tcp tcp_close_wait_interval` ;; esac # set queue lengths to maximum to prevent tcplistendrops /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024 echo "tcp_conn_req_max_q =" `/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q` /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 1024 echo "tcp_conn_req_max_q0 =" `/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q0` # change slow start algorithm to bypass congestion problem /usr/sbin/ndd -set /dev/tcp tcp_slow_start_initial 2 echo "tcp_slow_start_initial=" `/usr/sbin/ndd -get /dev/tcp tcp_slow_start_initial` # set high transmission window for efficient TCP transfers /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768 echo "tcp_xmit_hiwat =" `/usr/sbin/ndd -get /dev/tcp tcp_xmit_hiwat` # set high receiving window for efficient TCP transfers /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768 echo "tcp_recv_hiwat =" `/usr/sbin/ndd -get /dev/tcp tcp_recv_hiwat` # remind the user to set the tcp_conn_hash_size parameter, etc. echo "" echo "Set tcp_conn_hash_size in /etc/system to 32768" echo "" echo "Reboot and rerun this program if it had to be changed

2-2. Source Code 의튜닝본노트에서는 Web Server 의 Application 중, 가장성능문제를많이야기시키는게시판리스팅 (Listing) 부분에관해서예시를들고자한다. JSP Source Code 가 Database 단으로던지는 SQL 문장의로직이전체적인성능과어떤연관관계를가지고있는지설명하고자한다. 2-2-1. 게시판리스팅 SQL 문장의성능분석게시판리스팅을위한 SQL 문장의원문과 Plan 분석은아래와같다. SELECT RROWNUM, BDID, BDCD, BDNM, EGID... FROM ( SELECT ROWNUM AS RROWNUM, BDID, BDCD, BDNM, EGID... FROM ( SELECT BDID, BDCD, BDNM, EGID... FROM TBD9002M WHERE BDCD= 1607 게시판분류코드 ORDER BY GROU DESC, STEP ASC ) ) WHERE RROWNUM >0 AND RROWNUM <= 10; DBCD 컬럼에인덱스를생성하여 Full Table Scan 을회피한경우의 Plan 분석 Execution Plan -------------------------------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=70 Card=233 Bytes=1M) 1 0 VIEW (Cost=70 Card=233 Bytes=1M) 2 1 COUNT 3 2 VIEW (Cost=70 Card=233 Bytes=1M) 4 3 SORT (ORDER BY) (Cost=70 Card=233 Bytes=261K) 5 4 TABLE ACCESS (BY INDEX ROWID) OF 'JAY.TBD9002M' (Cost=27 Card=233 Bytes=261K) 6 5 INDEX (RANGE SCAN) OF 'JAY.IDX_TBD9002M_BDCD' (NON-UNIQUE) (Cost=1 Card=233) 플랜에서보여지는것처럼제일안쪽의인덱스에서부터많은량의데이터를가져와서끝까지이것을가공 / 처리하고있다. 실제로 tkprof 결과를분석해보면제일안쪽부터 Index Table Sort View 를거치는내내 1601 건의데이터를퍼올려서마지막에 rownum 에의하여 10 건을가져와게시판리스트로뿌려주고있다. 이러한 SQL 문장의튜닝시에는항상최초시작하는집합의범위를최소화시킬것을권장하고있기때문에이문장은다음과같이수정될수있다.

[ 수정된문장과플랜 ] 이 SQL 문장은아래와같이수정될수있다. 게시판테이블의분류코드와시퀀스번호로작성된인덱스를 INDEX_DESC 하게타게되면가장최신의게시물순서로자동소트되어있으므로 ORDER BY 절이필요없게되며, 가장안쪽의퀄리블록에서 ROWNUM < 10 을사용함으로써 STOPKEY 역할을하게된다. SELECT RROWNUM, BDID, BDCD, BDNM, EGID... FROM ( SELECT ROWNUM AS RROWNUM, BDID, BDCD, BDNM, EGID... FROM ( SELECT /*+ INDEX_DESC(TBD9002M TBD9002M_IDX2) */ BDID, BDCD, BDNM, EGID... FROM TBD9002M WHERE BDCD= 1607 게시판분류코드 AND ROWNUM <= 10) ); - - WHERE RROWNUM >0 주석처리 - - AND RROWNUM <= 10; 주석처리 이결과아래와같은플랜이생성된다. Execution Plan -------------------------------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=27 Card=233 Bytes=1M) 1 0 VIEW (Cost=27 Card=233 Bytes=1M) 2 1 COUNT 3 2 VIEW (Cost=27 Card=233 Bytes=1M) 4 3 COUNT (STOPKEY) 5 4 TABLE ACCESS (BY INDEX ROWID) OF 'TBD9002M' (Cost=27 Card=233 Bytes=261K) 6 5 INDEX_DESC (RANGE SCAN) OF 'TBD9002M_IDX2' (NON-UNIQUE) (Cost=1 Card=233) 이플랜에의하여동작되는 SQL 문장은최초인덱스에서테이블 Access 까지는 1601 건의데이터를핸들링하지만, 이후부터는 Stopkey 에의하여오로지 10 건의데이터를가지고최종수행단계까지처리 / 도달한다. 수행결과평균 18 초걸리던이문장은 1.2 초이내에결과를리턴하게된다. 웹사용자들이게시판리스트가 18 초걸려서나타나게된다면조금심각한지경이라고생각할것이다. 그런데, 문제는이 SQL 문장을튜닝하려면 Source Code 를수정해야한다는것이다. 이 JSP Source Code 가어떻게되어있는지살펴보자

[JSP 소스코드에서 SQL 문장생성부분 ] if(field01.equals("")) { tail02 = "' ) WHERE BDCD = '" + bdcd01 + "' AND RROWNUM >= " + page_start + " AND RROWNUM <= " + page_end + " ORDER BY GROU DESC, STEP ASC"; } if(field01.equals("suje")) { tail02 = "' AND ( SUJE LIKE '%" + search01 + "%')) WHERE BDCD = '" + bdcd01 + "' AND RROWNUM >= " + page_start + " AND RROWNUM <= " + page_end + " ORDER BY GROU DESC, STEP ASC"; } if(field01.equals("writ")) { tail02 = "' AND ( WRIT LIKE '%" + search01 + "%')) WHERE BDCD = '" + bdcd01 + "' AND RROWNUM >= " + page_start + " AND RROWNUM <= " + page_end + " ORDER BY GROU DESC, STEP ASC"; } if(field01.equals("yymm")) { tail02 = "' AND ( WRDA LIKE '%" + search01 + "%')) WHERE BDCD = '" + bdcd01 + "' AND RROWNUM >= " + page_start + " AND RROWNUM <= " + page_end + " ORDER BY GROU DESC, STEP ASC"; } sql01 = " SELECT "; sql01 = sql01 + " RROWNUM,BDID,BDCD,BDNM,EGID,WRIT,BUCD, "; sql01 = sql01 + " BUNM,EMAI,REGI,TELON,TELTW,PAWO,PDSON, "; sql01 = sql01 + " PDSTW,PDSTH,TYCD,TYNM,DECD,DENM,VICD,VINM, "; sql01 = sql01 + " STCD,STNM,SGCD,SGNM,SGID,IGCD,IGNM,"; sql01 = sql01 + " HIT,SUJE,CONTON,CONTTW,CONTTH,WRDA,MODA, GROU,STEP,LEVE "; sql01 = sql01 + " FROM (SELECT ROWNUM AS RROWNUM,BDID,BDCD,BDNM, "; sql01 = sql01 + " EGID,WRIT,BUCD,BUNM,EMAI,REGI,TELON,TELTW, "; sql01 = sql01 + " PAWO,PDSON,PDSTW,PDSTH,TYCD,TYNM,DECD,DENM, "; sql01 = sql01 + " VICD,VINM,STCD,STNM,SGCD,SGNM,SGID,IGCD,IGNM,"; sql01 = sql01 + " HIT,SUJE,CONTON,CONTTW,CONTTH,WRDA,MODA, GROU,STEP,LEVE "; sql01 = sql01 + " FROM " + TBD9002M + " WHERE BDCD = '" + bdcd01 + tail02; 이소스코드부분이게시판리스팅알고리즘의열쇠를갖고있다. 이소스코드의의도는게시판의최신데이터순으로첫번째부터열번째까지의결과를리스팅하고, 만약사용자가게시판리스트화면의하단번호를눌러서그다음열개의문서제목을보고싶어한다면열한번째부터스무번째까지의결과를리스팅하고자하는것이다. 앞페이지의 SQL 문장만을분석했을경우와는조금다른 Source Code 의논리적인흐름을읽을수있을것이다. 위소스코드에서는다행히 DB Table 의이름이명시 (Fix) 되어있고, where 절의조건이명시되어있으므로가장안쪽의 SQL Block 에힌트처리 (/*+ INDEX_DESC.*/ ) 와튜닝된 where 절조건 (rownum <= 10 ) 이처리되도록넣으면성능튜닝 SQL 절이 DBMS 로날아올것이다. 항상느끼는것이지만개발자의성능 (Performance) 에대한관심이문제가된다. 조금만성능을고려하고 JSP Programming 을했더라면이러한코드는나오지않았을것이다. 개발자들은모든것을 Procedural 한관점에서이해하고자하지만 SQL 은 SET( 집합 ) 의관점에서받아들여수행되어진다는것을명심해야한다.

2-3. SQL*Net 환경의튜닝 Web Server 와 DB Server 간의인터페이스에서튜닝되어야할대상중의하나가바로 SQL*Net Configuration 이다. 너무정형화된 listener.ora 파일과 tnsnames.ora 파일의셋팅에의하여흔히간과되는것이바로 SQL*Net 구성인데, 이네트워크환경을잘튜닝함으로써 40% 이상의성능개선을이룬사례도있다. 어떤 SQL*Net 환경의튜닝요소가있는지살펴보자. 2-3-1. SQL*NET 의 PACKET SIZE 조정 (SDU 와 TDU) SQL*NET 에서는 tnsnames.ora 와 listener.ora 에 SDU 와 TDU 의 parameter 를추가함으로써 Session Data Unit 과 Transport Data Unit 의 size 를변경할수있다. 이는 SQL*NET 을경유하여 Network 상에서보내지는 packet 의 sizes 를변경할수있다는것을의미한다. 최대값은 32K 이며 SQL*NET V2.3 이전버젼에서기본값은 2K 이며그이상은허용하지않는다. 즉, 이러한 parameter 들을이용하여 services 와 transport layer 를경유하여전달되는 Oracle 의데이터에대한각각의 buffer sizes 를조정할수있다. Oracle V7.3 이전에서는 SDU 와 TDU 를 2K 로제한하였으나 Oracle V7.3 이상에서는이 parameter 를 2K 이상으로조정할수있게되었다. SDU size 의경우는 Oracle 8 Release2 이상부터는 32K 이상까지도가능하다. 또한사용자는 SDU 와 TDU 의값을다르게지정할수도있으나이렇게한다하더라도장점은별로없다. 예로 TDU 는 1024 로 SDU 는 1536 으로설정을하였다고하더라도사용자는처음에는 512 bytes 를, 그런다음 1024 bytes 를보내는것을볼수있을것이다. 예 ) tnsnames.ora: 이 parameters 는반드시 DESCRIPTION 절안에있어야합니다. KRRCSUN = (DESCRIPTION = (SDU=8192) ) <**** Calls to this alias will <**** try to use 8K packets. (TDU=8192) (ADDRESS = (COMMUNITY = TCP.kr.oracle.com) (PROTOCOL = TCP) (HOST = krrcsun.kr.oracle.com) (PORT = 1521) ) (CONNECT_DATA = (SID = ORA733) ) Web Server 단의 tnsnames.ora 파일의설정에추가하여준다.

예 ) listener.ora : 이 Parameter 는반드시 SID_DESC 절안에있어야합니다. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = ) (SDU = 8192) <**** Connects to this SID (TDU = 8192) <**** will try to use 8K. (SID_NAME = ORA733) (ORACLE_HOME = /oracle2/app/oracle/product/oracle8) ) (SID_DESC = <*** This one will default generally to 2K (SID_NAME = V723) (ORACLE_HOME = /oracle/product/7.2.3) ) DB Server 단의 listener.ora 파일에설정하여준다. 이러한 SQL*Net 레벨의운반단위를튜닝하는것과 Application 레벨의 Array Fetch 크기를같이튜닝함으로써 SQL*Net 의 Packet 운반효율을극대화시킴으로써좋은튜닝효과를볼수있다.

3. 결언 웹서버가정의된성능목표를만족하는지, 성능을저하시키는주요병목현상은무엇인지, 성능저하에대한최적의개선방안은무엇인지등을판단하기위해서는웹서버를포함한전체시스템구성요소 ( 서버, 네트워크, 데이터베이스등 ) 에대한성능을측정하고적절한지표값들을수집하여이를종합적으로분석하는것이필요하다. 이때, 사용되는주요성능지표로응답시간, 시간당처리량및자원사용량 ( 어플리케이션수행중사용되는 CPU, 메모리, 디스크 I/O, 네트워크대역폭등 ) 등에대하여알아보았다. < 웹서버의주요트랜잭션구성도 > 웹시스템튜닝가이드라는제목하에 1,2 부에걸쳐데이터베이스 ( 인스탄스및 SQL), 운영체제, TCP/IP, SQL*Net 환경을파헤쳐보았다. 이모든부분을한명의웹서버관리자가전문적인지식을가지고성능조정 ( 튜닝 ) 한다는것은무리가있다. 그럼에도불구하고웹서버는모든조직의상징적인얼굴이되어조금느리거나문제가발생하면조직의장에서부터일반사용자 (End-User) 에이르기까지그원성의대상이되는것이상례가되었다. 이기술노트의몇줄지식으로모든웹서버관리자가모든트랜잭션을 3 초이내의초고성능웹서버로향상시켜관리하게끔하는것은꿈일것이다. 그러나, 웹서버의향상을위하여관리대상이되는요소들이어떤것들이며, 그개선방향이나가능한접근방법이이런것들이있다는것을안내하는선에서웹서버개선 ( 튜닝 ) 가이드의의도를변 ( 辯 ) 하고자한다.