[WebSphere Bebchmark Test 승리를 위한 최적 파라메터 셋팅 방법론]
먼저, 개념과 기본적인 셋팅은 아래 문서를 참조하시고 숙지 하십시요
Performance Tuning QuickGuide for BenchmarkTest
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=985764595
여러번의 시행착오끝에 수치를 찾아내셔야 합니다.
BMT수행전 적정수치를 찾기 위한 방법은 가급적 실제 테스트 하는 방법을 그대로
사용하십시요. 예를 들어, "LoadRunner 를 통해 6개의 호출을 순차적으로 호출하여
저장한 후 전체를 하나의 Transaction 으로 호출한다" 거나, "select성/update성 을
구분하여 각각 1000번씩 수행하고 전체의 elapsed 시간을 측정한다"와 같이 고객이
원하는 방법을 그대로 테스트시에도 해야만 합니다.
최적의 파라메터는 해당 어플리케이션에 따라 달라지므로 실제 테스트하는 방법을
통해 그대로 하시는 것이 매우 중요합니다.
굳이 이론적인 근거를 들어 "벤치마크테스팅방법론"을 설파할 필요는 없습니다.
사실, 해당 어플리케이션의 특성에 따라 무엇을 어떻게 측정할 것인가를 제대로
알고 있는 엔지니어는 드뭅니다.
다음과 같은 순서로 찾아 가시면 됩니다.
1) HTTP MaxClients 300, WebSphere OSE 300, 그리고, Legacy 서비스인 TUXEDO의
BMT 대상 "service"가 포함된 "server"의 복제수는 충분한 수치로 마추십시요.
수치를 찾기 위해 허용가능한 최대 수치로 마추세요.
50 - 100 개..
(J*Link 가 Pool 을 사용할 경우, 아래 PS (1) 을 참조 하십시요)
2) RoadRunner 혹은 AKtools 를 통해 정해진 테스트 시행 방법대로 Active사용자(thinktime=0)를
10부터 200 까지, 아니, 그 이상 500 까지 시행 하십시요...
이 때, 중요한 것이, HTTP Server머신, WebSphere 어플리케이션서버 머신,
TUXEDO서버, DB서버의 CPU와 MEM 사용량의 변화를 기록하십시요.
첫번째 시행에서 가장 먼저 주시해야 할 대상은 TUXEDO서버와 DB서버의 CPU
사용량입니다. Active사용자(ActiveClients,thinktime=0)가 몇개 부터 CPU 100 % 가까이 사용하는
지를 찾아내셔야 합니다.
(TUXEDO서버와 DB서버는 같은 머신에 있을 것으로 예상합니다만, 만약 다른
머신에 위치한다면, 둘 중 먼저 CPU 100 % 에 도달하는 시점으로 산정하십시요)
예를 들어 Active사용자 20-30 부터 CPU 는 100% 가까이 되었다면, 그 수치가 TUXEDO의
Seturation Point 가 될 가능성이 있습니다.
그러나, CPU 100% 만 보시지 마시고, LoadRunner 의 Active사용자 증가에 따른
TPS(Transaction Per Second) 가 최고에 도달하는 최초 시점과 함께 고려하십시요.
3) 2번에 찾으신 수치를 BMT 대상 TUXEDO "service"가 포함된 "server"의 복제수로
하양 조정하십시요. 만약, 하나 이상의 "server" 에 "service"가 분산되어
있다면, 직관적으로 찾으셔야 합니다. 가장 부하가 심한 "service"가 무엇인지
확인하고, 그 "service" 가 포함된 "server" 의 복제수에 주안하십시요.
그런 후, 2)번의 과정을 다시 반복하십시요.
그러나 이젠 관심의 대상이 "WebSphere 어플리케이션서버머신"의 CPU 사용량입니다.
어쩌면, TUXEDO서버의 성능상의 한계점과 N/W 에 의한 bottleneck 으로 인해
WebSphere 어플리케이션서버의 CPU는 100 % 에 도달하지 못할 수도 있습니다.
응답시간이 느린 서비스일 수록 CPU 는 100%에 도달하기 힘들겁니다. 반면,
TUXEDO서비스가 "Echo서비스"과 매우 빠른 응답속도를 나타낸다면 WebSphere
어플리케이션서버의 CPU 는 낮은 ActiveClients에서도 CPU 100%에 도달할
가능성이 높아집니다.
ActiveClients의 증가에 따른 TPS (Transaction Per Second) 가 최고점에 처음
도달하는 부근에서 WebSphere OSE Seturation Point 를 잡으십시요.
만약, 아무리 ActiveClients를 증가시켜도 CPU 100 % 에 도달치 못한다면, 굳지
OSE 수치를 높이 조정할 필요는 없습니다. TPS가 최고점에 도달하는 Active Clients
수치에 마추시는 것으로 충분합니다. WebSphere어플리케이션서버의 CPU가 100%에
도달치 못한다는 것은 bottlenect 의 원인이 backend 서비스인 TUXEDO에 있다는
것을 의미있을 뿐입니다. (특히 이같은 경우가 WebSphere어플리케이션서버 머신의
대수를 높여 클러스터링으로 묶는 것은 전혀 성능향상에 도움이 되지 않는 경우이지요)
그러나, 다행스럽게도 CPU가 100% 가까이 올라가서 최고의 TPS를 낸다면, 이것이
최적의 경우가 되는 상황입니다. WebSphere 어플리케이션서버의 OSE에 대한 Seturation
Point 가 적절히 발견된 경우지요. CPU 100% 가 되는 시점의 Active Clients 수치가
이제 마추어야 할 WebSphere 어플리케이션서버 OSE의 적정 Seturation Point 가 됩니다.
고객이 요구하는 BMT시나리오 항목에는 보통 "CPU 사용량" 있습니다. 그러나,
이것에 너무 주안을 두는 것은 바람직하지 않습니다. CPU사용량이 낮고 성능이
낮는 것보단, CPU사용량이 높되 성능이 우수한 것이 바람직하기 때문에, 해당
항목은 사실 그리 중요한 포인트가 아닌 거죠.
주의할 것은 이렇게 찾은 WebSphere의 OSE 적정 수치가 Backend TUXEDO 서비스의
"서버복제수" 보다는 크게 나와야 합니다. 만약, 낮게 나왔다면, TUXEDO서버의
복제수에 대한 Saturation Point를 잘못찾았거나, 지금의 OSE 수치를 잘못 찾았다는
것을 의미합니다.
따라서, 동시사용자(Active Clients)가 TUXEDO 서버의 복제 수 보다 높은 수치에서
WebSphere 의 OSE에 대한 Seturation Point 가 나타난다면, 즉, 최고의 TPS 가 나오는
시작시점이면서 CPU도 100 % 를 넘어간다면, 그 시점이 적정 OSE 수치가 됩니다.
4) 이제 3번에서 찾은 OSE 수치를 Websphere 에 적용하십시요.
그리고, 굳이 IBM HTTP Server 의 MaxClents 를 찾기 위해 또 다시 테스트를
시행하실 필요는 없습니다.
일부 Performance Tuning 가이드에 보면, MaxClients 수치는 OSE 수치보다 약간 높게
설정하라고 되어 있습니다.
예를 들면, OSE가 10 이라면, MaxClients 는 15 정도,
OSE 가 25 라면, MaxClients 는 30 정도, OSE: 50 --> MaxClients : 60
OSE: 100 --> MaxClients : 120 정도로 잡으라는 것이죠.
그러나, Benchmark 테스트에서는 약간 얘기가 다릅니다. HTTP 서버의 MaxClients
수치가 만약 낮을 경우, 대량의 동시사용자에 대해, HTTP 서버는 request fail을
발생시키게 됩니다. MaxClients이상으로 호출할 경우에 나타나는 당연한 증상인거죠.
이것이 실운영환경이었다면 MaxClients는 이렇게 설정되어 과도한 호출이 들어오지
못하도록 설정하겠지만, Benchmark 테스트에서는 어떻습니까? 단 하나의 에러도
허용해서는 안되잖습니까? 성능과 튜닝을 이해하지 못하는 엔지니어는 대량의
동시사용자에 따른 MaxClients 도달시에 발생하는 에러에 대해 왜 그렇게 호들갑을
떠는지 모르겠어요. 당연한 것을... 따라서, MaxClients 수치는 최대치로 마추어
주십시요. MaxClients 512. (더 높일 수 있던가?)
그리고, KeepAlive 기능은 필요에 따라 설정하십시요. 예를 들어, KeepAliveTimeout이
15초로 설정되어 있고, MaxClients 수치만큼 현재 ActiveClients 가 들어 오고 있다면,
새로운 Clients은 대기상태에 빠집니다. 왜냐면, 기존의 모든 http child process가
모두 각자의 clients들에게 15초간 우선적으로 할당되며, 15초가 지나기 전까진
놀고 있더라도 새로운 clients에게 처리를 할당시키지 않게 됩니다.
결국, 300이하의 Active Clients 일 경우는 KeepAlive 기능이 도움이 되지만,
MaxClients를 넘어서는 Active Clients 시행시는 KeepAlive 기능은 오히려 성능저하를
야기합니다.
어쨌거나, HTTP Server의 MaxClients 와 KeepAlive 기능은 몇번의 시행을 통해
적정 수치를 찾되, 최대의 TPS를 찾으려는 노력보다는 대량의 Active Clients에
대해서도 request fail 이 발생치 않는 수치를 찾는 부분에 노력을 기울이십시요.
reqeust fail이 발생하는 것이 실운영시에는 오히려 바람직함에도 불구하고,BMT의
결과에 연연해 하는 고객은 "active clients 500일때 request fail이 발생했다"는
것에 이슈를 제기할 겁니다. 일일이 응대하기도 이젠 지치네요.
방향은, MaxClients를 높이고, KeepAlive기능을 사용치 않는 방향이 될 겁니다.
그런후, 2)번의 테스트 시행을 최종적으로 다시 하십시요..
그리고, 총 세번 시행한 그 결과를 놓고 얼마만큼 성능이 향상되었는지 비교하십시요.
기대 효과는 동시사용자가 100 혹은 200 이상 에서 튜닝전에 비해 TPS 가 꾸준히
일정하여 "bucklezone" 이 사라졌음을 확인하십시요. 또한 bucklezone 에서
평균응답시간이 감소하였음을 확인하십시요.
NOTE: BMT 테스팅 방법에 대해 가타부타 할 필요는 없습니다. 평균응답시간의 그래프는
TPS 가 항상 최적치로 나올 때, 가장 안정적인 응답시간분포가 나옵니다.
그러나, CPU 사용율의 경우는 앞서도 언급했지만, WebSphere 가 CPU 사용율이 높은
반면, TPS나 평균응답시간이 훨씬 좋게 나왔을 경우, 다음과 같이 대응하십시요.
"CPU 사용율이 높은 것은 내부적에서 많은 일을 빨리 수행하기 때문이다. 그리니
성능이 더 좋게 나온 것 아니냐. 성능이 낮고, CPU 사용량도 낮다는 것은 뭔가
내부에서 bottleneck 이 발생하여 제대로 일처리를 하고 있지 않다는 증거다.
따라서, CPU사용량은 참고자료일 뿐이지 성능비교자료는 아니다"
PS: 다음 사항을 고려 하십시요.
(1) J*Link 의 경우, Connection Pool 을 사용하는 지, 아니면, 매번 맺고 끊는지
확인하십시요. 만약, Pool 을 사용한다면, 2번 수행시에 매우 높은 수치로
같이 마추신 후, 수행후 찾은 최적치는 TUXEDO "server"의 적정 복제수와 동일하거나
약간 높게 설정하십시요
(2) 만약 J*Link 가 매번 Connection 을 맺고 끊는 구조라면, API를 변경하여
Pool 을 사용할 수 있도록 조치를 취하십시요. 분명히 성능향상이 있을 것이라
생각합니다.
(3) BMTServlet 을 호출하실 때, "/servlet/BMTServlet" 으로 호출치 마시고,
"BMTServlet" 을 WebSphere 관리콘솔의 WebApplication 에서
"bmtservlet" 이라고 서블렛을 등록한 후, "시작시 기동" 옵션을 선택하십시요.
그리고, "/servlet/bmtservlet" 으로 호출 토록, 소스에서 고쳐 주십시요.
PS: TUXEDO나, Tmax, CICS등과 같이 legacy backend서버스와 연동되어 돌아가는 BMT는
사실 기술적으로 보면, WebSphere 어플리케이션서버의 성능테스트가 아닙니다.
TUXEDO 서비스의 성능은 WebSphere 나 혹은 타 어플리케이션서버 상에서 돌아가는
Servlet/JSP에 비하면, 턱없이 낮은 성능을 나타낼 것입니다. 결과적으로 bottleneck 은
TUXEDO backend 서비스에서 발생할 것이며, 제한된 TUXEDO성능을 어느쪽이 꾸준히
제성능을 유지할 수 있도록 셋팅하느냐의 차이입니다. 또한, TUXEDO의 제성능을
최적화하고 그것에 WebSphere 의 각 파라메터를 잘 셋팅하는 것이 WebSphere BMT 승리의
관건입니다. 여기엔 J*Link나 E*Link, Jolt 의 성능차이가 일부 요인이 될 수
있습니다.
---------------------------------------------
WonYoung Lee. Advisory IT Specialist,
IBM WebSphere, TSC-STSS, IBM Korea.
E-mail: lwy@kr.ibm.com, javaservice@hanmail.net
Phone : 02-3781-7904
Mobile : 011-898-7904
---------------------------------------------
|
