Performance Tuning QuickGuide for BenchmarkTest
Document Version : 0.98-1 , 2001.09.11
Version History
First Version : 0.95, 2001.01.16
Version : 0.96, 2001.02.15
Version : 0.97, 2001.03.28
Version : 0.98, 2001.03.29
Version : 0.98-1, 2001.09.11
특정 Servlet/JSP/EJB 어플리케이션이 최상의 Performance 를 내야하는 Benchmark Test
시행시에 IBM WebSphere 3.5.x 에서 적용해야 하는 최적의 파라메터 값들을 찾아내는
방법 입니다.
비록, 앞부분의 특정 파라메터는 IBM WebSphere 어플리케이션서버 기반의 수치이지만,
인터넷의 특성과 성능, 그리고, 최적의 파라메터를 찾아가는 과정은 웹기반 시스템이라면
동일하게 적용되는 방법론적인 문제입니다.
먼저 용어에 대한 정의부터 정하고자 합니다.
동시사용자/Concurrent Users/Concurrent Clients :
현재 해당 시스템을 사용하기 위한 목적으로 한번 이상 호출을 했거나, 하고 있는,
모니터 앞에 있는 사용자들이며 "Active Clients" 와 "Inactive Clients" 를 합한
사용자이다.
Active Clients/Active Reuqests/Active Threads :
현재 Request 를 수행하여 아직 응답을 받지 못한 사용자 혹은 수행중인
서비스의 갯수
Inactive Clients :
현재 Requset 를 수행하지 않고 있으며, 화면의 결과를 보고 있거나 다음 버튼을
누르기 전까지의 사용자.
일부 문서에서는 "동시사용자(Concurrent Users)"의 정의를, 위에서 정의한 "Active
Clients" 를 지칭하는 것으로 많이들 사용합니다. L4 스위칭 장비의 Active session개수
라든가, 80 port ESTABLISH로 물려 있는 "netstat -n"수치라든가, 혹은 Application
Server의 수행중인 Thread의 갯수라든가... 그러나, 이렇게 정의할 경우,
비즈니적인 중요한 부분을 상실하게 됩니다. 예를 들어, 현재 실행되고 있는 서비스의
갯수는 해당응용어플리케이션의 응답시간이 느릴 수록 높게 나타나며, 응답시간이
매우 빠른 서비스의 경우, 극히 낮게 나타납니다. 순식간에 끝나버리니 실제 서비스하는
갯수는 낮게 보이는 것이지요. 예를 들어, 어제는 Active Clients 수치가 무척
높았었는데, 어젯밤 열심히 어플리케이션을 수정하여 응답속도를 개선하고 오늘 측정하니
Active Clients 는 매우 낮게 나타났습니다. 만약, 이같은 상황을 두고, 매니져에게
"어제는 '동시사용자'가 100 이었는데, 오늘은 10 입니다." 라고 하면, 매니져는
"왜 어제보다 오늘 사용자가 적게 들어왔지?" 라고 오해를 한다는 것이죠. 실제 어제나
오늘이나 이 시스템에 들어와서 사용한 빈도는 동일했음에도 불구하고 말입니다.
따라서, 이 문서에서는 "동시사용자(Concurrent Users)"와 "Active Clients", 그리고
"Inactive Clients"를 구분하여 사용하겠습니다.
물론 정의에 허점은 있습니다. Active Clients 는 명확한데, Inactive Clients 의 경우
어디까지를 포함해야 하느냐의 문제가 있습니다. 호출에 따른 응답을 막 보고 있는
사용자의 경우는 분명하겠지만, 화면을 보면서 커피를 마시는 사람, 화장실에 잠깐
간 사람, 컴퓨터를 켜두고 집에 가 버린 사람 등, 그 범위가 애매 합니다.
Inactive Clients 의 정의에 따른 "동시사용자"의 정의 역시 마찬가지로 애매해 집니다.
그러나, 시스템의 관점에서는 "Active Clients"가 의미 있지만, 비즈니스적인 측면에서는
위 정의에 따른 "동시사용자"의 개념은 대단히 중요합니다.
1. Basic Setting
1장의 Basic Setting 은 IBM WebSphere 기반의 각종 튜닝 파라메터 설정에 관련한
부분입니다.
IBM WebSphere 어플리케이션서버와 관심/관련이 없는 분은 곧바로 "2. Tuning Approach
Methodology" 부분으로 가십시요.
1.1 IBM HTTP Server(httpd.conf)
- MaxClients (ThreadsPerChild) : (discussed later)
- Timeout 600 (default 300)
( 충분한 수치로 잡는 이유는 300(5분)도 충분히 크지만, 동시사용자가 증가함에
따른 최대 Response Time 보다 큰 수치로 적절히 맞춤, BMT(BenchMarkTest)환경에서는
시간이 오래걸려도 응답은 와야합니다.)
- CustomLog 는 최소화 : 불필요한 Trace 로깅(logging)은 가급적 자제합니다.
1.2 IBM Websphere Application Server
1.2.1 Web Server Configuration Reload Interval
[<websphere_root>/properties/bootstrap.properties]
ose.refresh.interval=20000
1.2.2 Initial Parameters
-Xms512m -Xmx512m -noclassgc ( -noasyncgc on solaris ) \
-Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util \
-Dcom.ibm.CORBA.iiop.noLocalCopies=true \
-Dcom.ibm.ejs.dbm.PrepStmtCacheSize=200 \
-Dfile.encoding=KSC5601 \
-Ddefault.client.encoding=KSC5601
NOTE: ms, mx 값은 CPU의 갯수와 MEM크기에 따라 적절히 조정합니다.
NOTE : com.ibm.ejs.dbm.PrepStmtCacheSize =
{서로다른 PreparedStatement 의 갯수} X
{BMT시 DB Connection 연결수 or # of MaxConnection}
default : 10
JIT compiler 가 "enabled" 되도록 Default로 사용
Q: SUN JVM Heap Setting
-Xgenconfig:64m,64m,semispaces:128,512m,markcompact
1.2.3 Servlet Engine
node --> AppServer --> ServletEngine --> 오른쪽 "일반" : 최대연결수
최대연결수(OSE Max Connection) : (discussed later)
1.2.4 WebApplication
- WebApplication AutoReload = false (default is "true")
- JSP Reload Interval
JSP 1.x Preprocessor --> Advansed --> Init Parameters 에 추가
minTimeBetweenStat : 7200000(2시간) (default 1000 ms)
(NOTE: 이렇게 할 경우, JSP를 변경하더라고 곧바로 변경되지 않습니다)
- 만약, EJB Container 를 사용치 않는다면 관리콘솔에서 반드시 지우십시요.
- 설치시 생성된 Default Server 를 그대로 사용치 말고, 지운후 새로 app server 를
재구성하십시요(!). Default Server에는 불필요한 samples,admin 등의 WebAppliation
이 설정되어 있습니다.
- File Servlet 이 있다면 반드시 지우십시요(IHS 가 html/image 를 처리토록)
- 만약, Servlet 이 BMT에서 사용된다면, 반드시 Alias 를 등록하여 사용토록 하고,
invoker Servlet 을 이용하여 ClassName 로 접근치 않도록 하십시요. 약간의
성능저하를 야기합니다.
1.2.5 SessionManager
Servlet Engine:Session Manager:Intervals:Invalidate Time: 600 seconds (default 1800)
SessionMgr:Session Manager:Tuning:Using Cache=Yes (default is No)
JSP 에서 HttpSession 을 사용치 않는다면, 소스에서 반드시 아래 라인을 추가하십시요
<%@ page session="false" %>
NOTE: DO NOT use Sesssion persistence feature !!
"Websphere 3.5.2 HTTP Session Persistence 17% performance degradation
for Trade2JDBC on Solaris when persistent session is used."
1.2.6 JSP Buffering
대량의 요청에 대해 메모리를 작게 사용하기 위해, 로직상의 문제만 없다면,
아래 라인을 통해 JSP buffering 을 하지 않도록 설정 하십시요
<%@ page buffer="none" %>
1.2.7 JDBC DataSource
Data Source:YourDataSource:Minimum connection pool size: 1 (default)
Data Source:YourDataSource:Maximum connection pool size: 20-40 (discussed later)
Data Source:YourDataSource:Connection timeout: 300 (default)
Data Source:YourDataSource:Idle timeout: 1800 (default)
Data Source:YourDataSource:Orphan timeout: 1800 (default)
NOTE: 실운영환경에서는 가용한 Connection 이 없을 경우, 마냥 기다리게 하면
전체적인 시스템의 hang 현상을 초래할 수도 있으나, BMT환경에서는 응답이 늦게
걸리더라도 DB 작업은 이루어져야 합니다. 따라서, connection timeout 값은
defualt 값인 300(5분)을 그대로 유지합니다. (실운영환경에서는 이 수치를 2-3(초)로
권장합니다.)
1.3. UDB DB2 DataBase
Use JDBC Driver Type 2 App Driver
Application Heap Size = 256M (default 128M)
MaxAppls = (# of connections set for Data Source + # of connections in session mgr)
x ( # of clones)
(default is 40)
Buffpage = 2 x MaxAppls (minimum setting)
MaxAgents = sumation of MaxAppls for all databases
NOTE: DB2 on Local AIX, TCP/IP cataloging
1.4 etc.
4 CPU 까지는 어차피 CPU를 100% 까지 사용하기 때문에 cloning 의 효과가 없으며
하나의 JVM으로 최적의 성능을 낼 수 있습니다.
2. Tuning Approach Methodology
2.1 Tuning Basic Issue
아래 [그림1]과 같이 "브라우져", "어플리케이션서버", 그리고 "DB or Legacy tier",
이렇게 3개의 tier 가 있다고 가정해 보겠습니다.
[그림1]
아래는 브라우져 단에서 측정한, 특정 H/W환경에서 특정 어플리케이션의 Active
Clients 증가에 따른 "평균응답시간"의 그래프입니다.[그림2]
[그림2]
동시사용자(Concurrent Users)가 증가하면 Active Clients 도 그에 따라 증가하고,
일반적으로 특정 시점까지는 평균응답시간은 일정한 값을 유지하다가 그 이후부터는
linear 한 증가를 보입니다.[그림3]
[그림3]
여기서 TPS(Transaction Per Second)라는 용어를 하나 정의하고 넘어가겠습니다.
[그림1]에서 "브라우져", "어플리케이션서버", 그리고 "DB or Legacy tier" 가 있을때
브라우져 단에서 측정한 1초당 응답횟수를 TPS(Trnasaction Per Second) 라 부르겠습니다.
사실 "Transaction" 이란 용어는 서로다른 뜻으로 IT에서 광범위하게 사용합니다. 이
문서에서는 Transaction Per Second 보다는 RPS(Response Per Second), 혹은
PPS(Page Per Second) 의 의미가 강합니다.
이렇게 정의된 TPS는 Active Clients 가 증가함에 따라 함께 증가하다가, 일정시점부터는
더이상 증가하지 않습니다. 오히려, 과도한 Active Clients 에 대해서는 오히려 TPS는
감소하는 결과를 야기합니다.[그림4]
[그림4]
어쨌거나, 해당 어플리케이션 혹은, 어플리케이션서버의 "성능(Performance)"를 이야기
할 때, "평균응답시간이 0.5 초였다, 혹은 1.7 초였다" 라는 것은 "특정 H/W, 특정
Active Clients 가 얼마일 때 그러했다"라는 조건이 붙어야 합니다.
반면, TPS 에는 Active Clients 가 얼마이든, 1초당 처리할 수 있는 횟수는 Active
Clients 의 일정구간에서 일정하게 되고, 그 수치를 넘어서지 않습니다.
따라서, "성능"을 이야기할 때, "평균응답시간" 보다는 "TPS" 를 놓고 얘기하는 것이
보다 바람직할 것입니다.
그리고, "평균응답시간"은 특정 하나의 수치를 갖고 얘기해서는 안되며, Active Clients
의 증가에 따른 전체적인 그래프를 놓고 이야기해야만 의미를 가집니다.
성능측정을 위한 Benchmark Test를 시행할 때, 대부분의 경우, 아래의 두가지 항목이
고려되어야 합니다.
즉,첫째 TPS(단위시간당 최대처리건수)를 구하는 것이지요. 이는 1초당, 혹은 1분당
최대 처리할 수 있는 건수를 구하는 과정으로 Active Client 를 지속적으로
증가시키며 그에 따른 단위시간당 처리건수의 그래프를 구하여 그래프의 최대치를
확인하는 것입니다.
둘째, 비즈니스적 요건상 허용가능한 최대응답시간을 설정하고, Active Client 를
증가시키며 부하량을 지속적으로 높였을 때, Active Client 에 따른 평균응답시간의
그래프를 구하고, 그 평균응답시간의 변화량이 허용가능한 범위에 속하는 지를
확인하는 것입니다.
성능측정이라는 것은 어떤 Tool 을 사용하든, 결국 위의 2가지 사항을 확인하는 과정이
될 것입니다.
그 이외의 것은 부수적인 모니터링 관점일 뿐이며, 대표적인 예가, CPU사용량,
메모리 사용량, I/O량, N/W 사용량 등이 될 것입니다.
궁극적으로 "Performance Testing" 의 근본적인 목적이 "Performance Tuning"을
위한 것이므로, 각 관점에서의 모니터링 결과를 토대로 bottleneck 의 Point를
찾아내고, 개선함으로써, Performance Tuning 을 하게 되는 것이지요.
간혹, 일각에서는 BMT를 시행할 때, CPU사용량과 MEM사용량을 성능측정의 한 항목으로
선택하기도 합니다. 그러나, 이것은 어디까지나 참조자료이지, 성능비교를 위한 자료가
되어서는 않됩니다. 이는 마치 여러명의 축구선수들이 경기를 할 때, 어떤 선수가 가장
많이 골을 획득하느냐 보다는 어떤 선수가 땀을 많이 흘리지 않느냐를 가지고 그 선수를
평가하려는 것과 동일합니다. 혹자는 동일한 성능을 나타낼 때, 이왕이면 CPU나
메모리를 적게 사용하는 시스템을 선택하려 했을 지도 모르겠습니다. 그러나, 대부분의
축구경기결과가 그러하듯 비기는 경우는 상대적으로 매우 드문현상이며, 설령 동일한
TPS결과를 보였더라도, CPU나 MEM사용량이 낮다는 것은 뭔가 좀더 튜닝을 통해 성능을
높일 수 있었거나 다른 외적 부분에 의한 bottleneck 이었겠구나 정도로 받아들여야지
이를 마치 2차 성능측정 항목으로 선택하는 것은 축구경기가 비겼을 때, 어느 팀이
땀을 적게 흘렸느냐로 우승을 가리는 꼴이 되고 맙니다.
2.2 Actual Tuning Methodology
2.2.1 관련된 모든 수치(MaxClients:300,OSE:300)를 최대한 높인 후, AKstress Tool을
이용하여 점차적으로 Active Clients 수(Threads #)를 증가시키며 부하를 주고,
그 결과를 아래와 같은 그래프(Throughput Curve)로 그리십시요
[그림5] AKtools 의 결과로 나온 PPS(Page Per Second): 1초에 수행한 횟수
2.2.2 Saturation Point 와 buckle zone 을 찾으십시요
Saturation point
- CPU가 100% 가 되는 시점.
- TPS 가 최대가 되는 시작 시점.
Buckle zone
- TPS 가 CPU의 경합으로 인해 오히려 떨어지는 구간
[그림6]
두 값을 찾을 수 있을 때까지 충분한 수치(MaxClients,OSE)에서 동시 Thread 구간을
여러 번 테스트할 필요가 있을 것입니다.
2.2.3 관련된 수치를 Saturation Point 에 맞추십시요
위에서 Seturation Point 가 발생하는 원인이 서블렛엔진의 처리능력상의 문제라면
OSE수치가 Seturation Point 의 대상이 될 것입니다.
그러나, DataBase를 사용할 경우나, Legacy 시스템과 연동하는 구조라면, 오히려
이와 관련한 수치가 Seturation Point 를 만들어낸 주된 요인이 될 것입니다.
2.2.4 다시 동시 thread 수를 증가시키며 점차적으로 부하를 주십시요
그리고, 항상 최대치의 TPS가 유지되는 것과 buckle zone 이 사라졌음을 확인하십시요
[그림7]
NOTE: 위 결과에서 보듯, 만약, 항상 Active Clients 50 에서만 테스트 했었다면,
Seturation Point 을 찾아 튜닝한 것과 하지 않은 것의 차이를 느끼지 못했을
것이고, "성능상의 변화가 없다"라고 오판할 수 있을 것입니다. 사실상 차이는
Active Clients 가 많을 때 차이가 발생했으니까요...
NOTE: Backend 시스템(CICS,Tmax,SNA HOST,Socket) 과 연동시에도 반드시 가능한 최대
높은 수치로 마추어 놓은 후, Threads 갯수를 10 부터 500 까지 10씩 증가시켜
TPS 를 구해야 합니다.
NOTE: 특정 H/W 플렛폼상에서 특정 어플리케이션은 고유의 TPS가 정해져 있습니다.
단지 찾지 못했을 뿐입니다. 그 수치를 찾아, 항상 그 수치가 나오도록 하는 것이
튜닝입니다.(물론 해당 프로그램 로직을 고쳐 성능향상을 가져오는 것이 더욱
영향력이 큽니다.)
NOTE: 잊지 말아야 할 사항은 Seturation Point 를 찾으려면 들어가는 모든 통로를
최대한 열어두고(MaxClients:300, OSE:300, DataSource:300, 혹은 그 이상) 테스트가
수행 되어야 합니다.
NOTE: 각 어플리케이션 마다 최적치의 파라메터는 그 어플리케이션의 특성에 따라
각기 서로 다릅니다. 정말 그렇습니다.
2.3. Application 성격에 따른 특성
2.3.1 dummy.jsp 와 같이 응답이 매우빠르고 내부에서 별로 하는 일이 없는 어플리케이션
- 동시에 처리하는 Max제한수치는 10-20 으로 매우 낮아 질 수 있습니다.
- 수치를 매우 낮게 제한시켜 두어도 CPU 사용은 100 % 까지 순식간에 올라갑니다.
왜냐면, 대부분의 부하는 해당 어플리케이션에 있는 것이 아니라, 엔진쪽에서의
Event처리가 거의 점유하게 됩니다. 응답이 빠른 서비스인 만큼, CPU가 할일도 많고
발빠르게 움직여야 한다고 설명하면 될까요...
응답이 매무 빠르므로 TPS 는 매우 높습니다.
2.3.2 DB 관련 어플리케이션
- DB SQL의 Query 정도에 따라, DB서버와 WebSphere 가 CPU사용량이 달라집니다.
위의 "Tuning Approach Methodolody" 에 따라 DataSource Max 수치와
WebSphere OSE Max #, IHS MaxClients # 를 찾아내야 합니다.
- DB Query 시간이 많이 걸리는 서비스일 경우, Seturation Point 의 대상은
DataSource 의 max connection 비중이 성능상의 영향을 더욱 받습니다.
DB Server 의 CPU/MEM 사용량에 따라 Seturation Point 를 잡되, OSE 수치보단
DataSource 의 max connection 에 관심을 가져야 합니다.
- DB Query 가 simple 할 수록, DataSource 의 max connection 수치는 낮아질 수
있다. 이 경우, DataSource 의 max connection 보단, WebSphere 의 OSE수치가
성능에 더욱 영향을 받습니다.
NOTE: 적정한 수치가 어떤 것인지는 해당 어플리케이션의 특성과 H/W에 따라
달라 집니다. 그렇기 때문에 특정 수치를 이 문서에서 제시할 수는 없습니다.
2.3.3 Backend Access 어플리케이션
- CICS Transaction Gatewary for Java, WebT for Tmax, Socket, JNI 등으로 Backend
서비스와 연동될 경우, 대부분 Backend 시스템에서 bottleneck 이 발생하며,
전체적인 TPS 는 backend 의 TPS 그 자체가 됩니다.
- Backend 시스템의 buckle zone 이 발생하지 않는 한 앞단에서는 최대한
Backend 로 많은 수의 Request 가 쌓이도록 해야 합니다.
따라서, MaxClients, OSE 수치는 높아 질 수 있으며, 그럼에도 불구하고
WebSphere Machine 의 CPU/MEM 사용량은 극히 낮을 것입니다.
NOTE: BMT의 환경에서는 아무리 응답시간이 느리더라도 응답이 실패하면 안됩니다.
반면, 실 운영환경에서는 응답이 느려질 경우, 마냥 기다릴 것이 아니라, 가용한
자원(DataBase Conneciton, Legacy Socket Pool, etc..)이 없을 경우 "시스템이
폭주중입니다. 다음에 다시 이용하세요"와 같이 곧바로 호출을 밖으로 밀어내야
합니다. 그렇지 않으면 시스템은 그 대량의 호출을 끝까지 수행하기 위해 계속적으로
Queue 에 쌓아 둘 것입니다. 이것을 해결하는 하나의 방법이 "Peek Point Control"
이라 명명한 프로그래밍 기법입니다.
2.4 수용가능한 최대동시사용자(Maximum Concurrent Users)
2.4.1 TPS 에 근거한 최대 동시사용자
Active Clients 증가에 따른 1초당 처리횟수 TPS를 측정한 [그림7]에서, 해당 어플리케
이션의 최대 TPS는 83.33 나왔습니다.
예를 들어, "한 사용자는 응답시간이 얼마가 걸리든 10초간격으로 한번씩 무조건 호출을
한다"라고 가정해 보면, 한사람이 10초간격으로 호출하니, 10사람이면 서버측에서는
1초에 한번꼴로 요청이 들어올 것입니다. 100사람이면 1초에 10번 꼴로 요청이 들어올
것입니다. 833 명이면, 서버측에서는 1초에 83.3 개의 호출이 들어오는 정도의 부하일
것입니다.
만약, 833 명 이상이 되면 어떻게 되겠습니까? 1초에 83.3 회 이상의 빈도로 호출이
발생하게 되는데, 해당 H/W, 해당 어플리케이션은 [그림7]에서 측정한 바와 같이 1초에
최대 83.3 회 이상은 처리하지 못합니다. 그렇게 되면 일부 초과하는 호출들은 응답지연이
발생하게 되고, 응답지연에서 그치는 것이 아니라, 호출빈도와 처리능력의 상관관계에서
밀리게 되므로, 일부 Request 는 Queue 에 쌓이게 되고, Queue 에 쌓이는 량은 계속적으로
늘어나게 됩니다.
결국, "10초에 한번씩 무조건 호출한다"란 가정하에 해당 어플리케이션은 특정 H/W환경에서
833 명 이상은 수용할 수 없다고 할 수 있습니다.
물론 이것은 빈도와 확율의 문제일 뿐입니다. 특정 시점에 몰릴 수도 있고, 1만명이
접속해 있어도 실제 호출량은 작을 수 있습니다. 또한 그 "10초"라는 가정을 어떻게
보장하겠습니까? 화면의 Content 의 위치와 Navigation 방법에 따라 달라질 것입니다.
그러나, 기존 Access 로그 자료가 있다면, 그 자료를 기반으로 특정 어플리케이션의
호출빈도와 그 변화량 추이를 예상할 수 있습니다. 또, 일반사용자를 선정하여 특정
시스템 사용에 따른 호출패턴과 호출빈도를 모니터링하면, 어느 정도 동시사용자일 때,
어느정도의 부하가 발생하므로, 향후 어느시점에 되면 최대동시사용자의 한계시점에
도달할 것인가를 나름대로 예측할 수 있다고 봅니다.
2.4.2 평균응답시간(Mean Time)에 근거한 최대동시사용자
앞선 글에서는 TPS에 의한 직관적인 최대동시사용자를 구해 보았습니다. 반면 Active
Clients 증가에 따른 "평균응답시간"의 그래프를 그려두면, 해당 어플리케이션이 최대
수용할 수 있는 사용자를 구간별로 계산해 낼 수 있습니다. 예를 들어 Active Clients
증가에 따른 "평균응답시간"의 그래프가 다음과 같다고 가정하겠습니다.
[그림8] Ktools 의 결과 중 Active Thread # 증가에 따른 Mean Time(평균응답시간)
다음과 같은 것을 생각해 보겠습니다.
[그림9]
위에서, Active Clients 120 의 경우를 보면, "항상 120 개의 Request가 서버측에서
수행하고 있는 상황" 입니다. 이 정도의 부하가 들어오기 위해서 몇명의 사용자가
있으면 되겠느냐를 역산하는 것입니다. 예를 들어 "응답시간이 얼마가 걸리든, 항상
10 초 간격으로 호출한다"라고 가정하면, 만약 이러한 사용자가 120 명이 있다면
서버측에서는 불과 1.4초 밖에 "Active Clients 120" 을 유지하지 못합니다. 항상
120 개의 호출을 서버측에서 수행중인 상황이 되려면, 1.4 : 10 의 비율만큼이 더
있어야만 할 것입니다.
따라서, 120 x { 10,000 / 1,409 } = 852 명 정도가 10초간격으로 지속적으로 호출할
때, 서버측에서는 항상 120 여개의 Active 호출이 발생하는 셈입니다.
Max Concurrent Users = (Acrive Clients) x { t / r }
(t : 몇초마다 사용자가 한번씩 버튼을 누른다는 가정치. 예) 10000(10초) )
r : 특정 Active Clients시의 평균 응답시간)
위 수치를 계산해 보면, Active Clients 가 증가함에 따라 특정 수치로 수렴하게 됩니다.
그 수치가 t 값의 가정하에 최대 수용가능 인원이 됩니다.
또한 이 수치는 앞서 TPS에 의해 구한 "최대동시사용자"수와 유사하게 일치합니다.
(사실 수학적으로는 정확히 일치하여야 하는데, AKtools 가 TPS를 계산할 때, miscro
second 를 이용치 않고, second 를 이용하여 devide 연산을 하는 듯 합니다.)
[그림10]
NOTE: 그러나, 평균응답시간의 그래프([그림8])에서 "수용/허용가능한 응답시간
시점"까지만 의미가 있는 만큼, 응답시간이 매우 빠른 속도로 느려질 경우, 수렴값
이전에 이미 한계 사용자수에 도출될 수 있습니다. 예를 들어, "응답시간이 1초 이상은
도저히 용납할 수 없다" 면 위에서 Active Clients 80 여명일때 평균응답시간이 1초
가까이 된다고 했을 때(1,008 ms), 80 * { 10,000/1,008 } = 794 명. 이를 넘을 경우,
ActiveClients 가 80 을 넘어서게 되고, 이는 용납할 수 없는(!) 평균응답시간(1초)을
야기하는 구간이 됩니다.
NOTE: 위 그래프를 해석하면,
(1) 일정한도 까지는 사용자가 증가하더라도 그에 따른 부하를 적절히 처리할 수
있지만, 위에서 언급한 "최대동시사용자" 가까운 수치에서부터는 조금만
사용자가 증가하면 그에 따른 서버측의 부하는 급격하게 증가합니다.
대표적인 현상이 "netstat -n | grep asi | wc -l" 로 본 실제 서비싱하고
있는 갯수(OSE)의 급격한 증가를 야기합니다.
(2) 이 얘기는 역으로 Clients 가 호출하는 빈도(Request Per Second)가
서버측에서 1초당 처리할 수 있는 갯수(Trahsaction Per Second)를 초과하는
그 시점부터, 일부 Request 는 Queue 에 쌓이게 됩니다.
이는 호출빈도와 처리능력의 문제이므로, 이 상황은 절대 복구되지 않으며,
점차 악화되어 복구 불능의 상태에 도달합니다.(공을 던지는 사람과, 공을받아
다시 되던지는 두사람이 있다고 할 때, 공을 던지는 사람의 빈도가 공을받아
되던져주는 사람의 처리능력 이상으로 던져 버리면, 받지 못한 공의 수는
계속 늘어만가지 결코 줄지 않지 않습니까)
이것이 기존의 Client/Server 환경과 인터넷의 차이입니다. C/S환경에서는
사용자가 버튼을 누를 경우, 응답이 오기전까지 모든 버튼이 비활성화되어
다시 누를 수 없었습니다. 이는 서버측의 성능이 낮을 경우 단지 응답속도의
저하현상만 초래할 뿐, Queue 에 쌓인 Request 는 언젠가 응답이 오게 됩니다.
그러나 브라우져 기반의 인터넷 사용자는 응답이 오지 않을 수록 더욱
요청을 날리는 경향이 있으며, 이는 또다른 호출발생을 통해 호출빈도를
증가시키게 됩니다.
앞선 최대동시사용자를 구하는 공식은 "응답이 얼마만에 오든 무조건 t 시간
간격으로 호출한다"는 가정하에 이루어졌습니다.
만약 "응답이 얼마가 걸리든 응답이 정상적으로 온 후, t 시간 이후에 다시
호출한다"는 C/S환경의 가정하에 동일한 "최대동시사용자"를 구해 보면
그 차이를 알 수 있습니다.
C/S Max Concurrent Users = Active Clients x { (r+t) / r }
(t : 응답이 온 이후 몇초가 지난 후 다시 버튼을 누른다는 가정치. 예) 10000(10초) )
r : 특정 Active Clients시의 평균 응답시간)
[그림11]
즉, Active Clients 사용자 증가에 따라 수용할 수 있는 Clients 수는 그에 따라
linear 하게 증가합니다. 즉, 사용자가 증가하더라도, 응답시간만 느려질 뿐,
여분의 응답대기상태에 빠진 request 수는 일정 시간후 더이상 증가하지 않기
때문입니다.
인터넷 기반의 웹시스템이 이렇게 말많은 이유가 여기에 있습니다.
3. 결론
튜닝은 종합예술입니다.
PS: AKtools : ftp://ftp.javaservice.net/pub/aktools/
Document :
http://www.javaservice.net/~java/bbs/read.cgi?m=etc&b=etc&c=r_p&n=972365763
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:019-310-7324
================================================
 image4_2.gif (8368 Bytes)
image5.gif (15854 Bytes)
image0_2.gif (11888 Bytes)
image2.gif (21694 Bytes)
image1.gif (15062 Bytes)
image6.gif (17121 Bytes)
image0_3.gif (9539 Bytes)
image0_4.gif (9969 Bytes)
image0_1.gif (2955 Bytes)
image3.gif (23246 Bytes)
image4_0.gif (20848 Bytes)
|
