스트레스테스트 방법론에 관한 연구

[(단일 어플리케이션에 대한) 스트레스테스트 방법론에 관한 연구]

0. 용어의 정의 및 통일의 필요성
용어상의 혼란을 막기 위해 몇가지 용어에 대한 정의를 내립니다.
사용자: 시스템을 사용하는 주체(일반적인 의미로 쓰임)
접속자: "사용자"와 동일한 의미를 가짐('사용자'보다는 좀더 구체적으로 쓰임)
엑티브유저(ActiveUser) : 요청을 한 이후 응답을 아직 받지 않은 사용자
인엑티브유저(InactiveUser) : 응답이 끊난 이후, 다음 요청을 보내기 전까지의 화면을
보고 있거나, 생각하는 사용자
동시단말사용자수(Concurrent User) = Active User수 + Inactive User수
컨커런트유저수(Concurrent User) = '동시단말사용자수'와 정의를 같이함.
동시사용자: '동시사용자'에 대한 정의가 Active User로 사용되는 경향이 있으나,
사용상의 혼란을 막기 위해 "동시사용자"는 "동시단말사용자"로
명시함. 가급적, "동시사용자"라는 다소 혼란을 초래하는 용어는 앞으로
사용치 않을 것을 권장함.
동시접속자: '동시단말사용자'와 동일함.
"요청을 날린 후 아직 응답을 받지 않은 총사용자수"에 대한 표현은 "Active User"
혹은 "Active사용자", "Active사용자수" 등과 같이 "Active(엑티브)"라는 용어를
반드시 붙여 사용할 것을 권장함.
PS: 사실, "동시단말사용자", "Active유저"만 사용하고, "일일총접속자수", "1시간당
총방문자수" 등과 같은 표현은 자유롭게 하여도 무방함.

1. 개요
본 문서는 국내에서 횡횡하고 있는 웹어플리케이션서버 기반의 벤치마크테스트과정상에서
어떻게 고객의 요구조건을 수렴하고, 어떻게 검증하는 지에 대한 방법론에 대한 연구가
적절치 않아 적잖은 어려움을 겪고 있는 담당자들을 위해 작성한 문서입니다.

2. 고객의 성능검증 요구조건
본 테스트를 위한 고객의 요구조건은 다음과 같다고 가정하겠습니다.
서비스레벨 요구조건(Service Level Specifications)
- 최대 수용가능한 동시단말사용자수
- 허용가능한 평균응답시간

설명의 편의를 위하여 다음과 같은 가정을 하겠습니다.

- 500명의 사용자를 견뎌야 함
- 평균응답시간은 3초 이내이어야 함
여기에서, 우선, "500명"이라고 했을 때의 그 500명에 대한 정의를 명확히 해야 합니다.
분분할 수 있으나, 다음과 같이 정하시면 됩니다.
요구조건에 대한 상세 변경
1) 사용자 500명이 견뎌야 한다. 여기서 '사용자'란 '동시단말사용자'로서, 예를 들어,
큰 컨퍼런스홀에서, 500명이 들어가 각자 자신의 단말기를 이용하여 자연스럽게 본
시스템을 사용할 때, 이때의 500명이 '동시단말사용자수'이다.
2) 500명의 동시단말사용자에 의해 시스템이 운영되고 있을 당시의 해당
응용어플리케이션의 평균응답시간이 3초 이내이어야 한다.
3) "ThinkTime"에 대한 추가 합의(본 예에서는 25초를 가정함)
3. 테스트 방법 및 절차
웹스트레스테스트를 위한 툴들은 다양하게 있습니다. 어느 것을 사용하든 상용툴을
사용할 것을 권합니다.

테스트를 시행하는 방법 및 절차는 크게 다음과 같이 2가지가 있을 수 있습니다.
3.1 첫번째 방법(실상황에 보다 근접한 시물레이션방법)
해당 사이트의 고유의 Think Time을 가정하여 이를 테스트시에 대입하는 방법입니다.
호출간격(RequestInterval),응답시간(ResponseTime) 및 Think Time의 정의는 다음과
같습니다.
+------------>+--->+---------------------------------------+-------->....
Click click
Response end
Response start
<--ResponseTime--><---------- Think Time --------------->
<------------------- Request Interval ------------------->
위와 같이 Think Time의 정의는 응답이 완전히 온 이후부터 다음번 Request를 날리기 전
까지의, 사용자가 "생각하는 시간"입니다. 이 수치는 해당 어플리케이션의 성능과 무관하게
비즈니스적인 사용자의 호출패턴에 따라 결정되는 수치인데, 일반적으로 다음과 같은
경험적인 수치를 사용할 수 있습니다.
[비즈니스별 Think Time 경험치]
TM(Telemarket) 시스템(Teler들에 의한 시스템) : 10-15초
MIS 인트라넷 시스템 : 15-20초
인터넷뱅킹 시스템 : 25-35초
온라인쇼핑몰 시스템 : 30-40초
온라인 커뮤너티 사이트 : 보다 길 수 있음.
(위수치는 본인의 경험자료일 뿐이며, 보다 정확한 것은 해당 사이트의 웹로그에서
직접 분석되어져 사용되어야 합니다.)
스트레스테스트 툴에서 위와 같은 ThinkTime(본 예제에서는 25초를 가정함)을 시나리오
입력하고, Virtual User는 테스트를 진행하면서 점차적으로 증가시키는데, 특정 Virtual
User에 대해서는 충분한 시간동안 측정하는 것으로 합니다. Virtual User를 끌어올린
후, 그 Virtual User에 대한 다음과 같은 두가지 그래프를 뽑아 내어야 합니다.

(1-1) Throughput(req/sec) vs Virtual User

33.3 (req/sec)
+ - - - _*---------------
/ .
17.5 / .
+. . ._/ .
/ .
/ . 임계점
/ . /
+-----+------+-------------------->
500 950
Virtual User(Think time 25sec)
(1-2) Average ResponseTime vs Virtual User
(평균응답시간)
*
*
*
임계평균응답시간 *
+3.5 (sec) _**
+2.5(sec)_* . 임계점
*-- . /
+-----+------+-------------------->
500 950
Virtual User(Think time 25sec)
Throughput(단위시간당 처리건수, req/sec)와 평균수행시간의 그래프를 그리고, 다음과
같은 테스트 수치가 나왔다고 가정해 보겠습니다.
1) 첫번째 (1-1) Throughput(req/sec) vs Virtual User 그래프에서 최대 Throughput은
33.3 tps 이었다.
2) 최초로 최대의 Throughput이 나타나는 시점, 즉 임계점은 Virtual User 950명일때였다.
3) 두번째 (1-2) 평균응답시간 vs Virtual User 그래프에서, 임계점(950명)에서의에서의
임계평균응답시간은 3.5초였다.
4) 반면, Virtual User 500명일 당시, 그래프 (1-1)에서 Throughput은 17.5 tps 이었다.
5) Virtual User 500명일 당시의 평균응답시간은 2.5(sec)였다.
결론: 이 시스템은, 25초간격의 Think Time을 가지는 최대 동시단말사용자 950명을 수용할
수 있으며, 그 시점에서의 임계평균응답시간은 3.5초이다.
고객 요구조건에 대한 검증:
- 최대 수용가능한 동시단말사용자는 요구된 500명보다 450명이 높은 950명까지 수용할 수
있으나,
- 평균응답시간은 동시단말사용자 950명일 경우 3.5초로써, 3초 이내가 아니다. 그러나,
고객의 목표치인 동시단말사용자 500명일 당시의 평균응답시간은 그래프 (2)에서 Virtual
User 500 일 때의 평균응답시간을 확인한 결과 2.5 초이므로, 사실상 고객의 요구조건을
만족하고 있다.
따라서, 테스트 결과, 고객의 요구조건을 모두 만족하고 있다.
[사족1: 엄밀히 이야기 하면, 스트레스테스트 툴은 Think time이 아니라, 호출간격(Request
Interval)을 입력할 수 있어야 하고, 시물레이션 되어야 합니다. 왜냐면, 이는 과거의
C/S시스템과 같이 응답이 오지 않으면, 응답이 올 때까지는 사용자가 버튼을 다시 누를
수 없는 상황에 대한 시물레이션이기 때문입니다. 그러나 인터넷 브라우져 환경은....
각설하고. 어쨌거나.]
3.2 두번째 방법
Think Time을 주지 않고도, 즉, Think Time을 0으로 셋팅하여 원하는 테스트를 할 수도
있습니다. 스트레스테스트 시에, Think Time을 주지 않은 채, 즉, 한 Virtual User는
응답오자 말자 곧바로 다시 반복적인 요청을 날립니다.
Think Time이 0 일 경우,앞서 첫번째 방법과는 확연히 다른 의미를 가지는 테스트가
일어납니다. 대표적인 변화 중의 하나는, 테스트시에 일어나는 Virtual User는 우리의
목표치 "동시단말사용자"를 의미하는 것이 아니라, Active유저의 수를 의미하기 때문에,
대부분 임계점이 나타나는 Virtual User의 수는 (상대적으로) 매우 낮은 범위에서
나타납니다.
상이한 두 WAS나 서로다른 어플리케이션에 대한 테스트일 경우는 해당 Virtual User의
범위는 달라도 됩니다. 간혹 "동일한 부하상황을 마련해줘야 하지 않으냐"라는 점에서
동일한 Virtual User를 부여하려는 잘못된 판단을 할 수도 있으나, ThinkTime을 0으로
부여할 경우는 그 의미가 다른 만큼, 각각의 임계점이 나타나는 근방을 중심으로 Virtual
User를 부여하여 테스트를 시행 하시면 됩니다.
Virtual User를 점차적으로 증가시키는데, 특정 Virtual User에 대해서는 충분한 시간동안
측정하는 것으로 합니다. Virtual User 증가에 따른 Throughput의 그래프와 평균응답시간의
그래프를 앞서와 같이 취득하는데, 테스트할 Virtual User의 범위는 그래프상의 임계점이
중심에 올수 있는 정도의 적당한 영역을 취하면 됩니다.
(2-1) Throughput(req/sec) vs Virtual User

33.3 (req/sec)
+ - - - _*---------------
/ .
/ .
+17.5 +/ .
/ .
/ . 임계점
/ . /
+-----+------+-------------------->
45 117
Virtual User(Think time 0 sec)
(2-2) Average ResponseTime vs Virtual User
(평균응답시간)
*
*
3.5 (sec) *
임계평균응답시간 *
+......... _**
_* -* . 임계점
*-- . /
+-----+------+-------------------->
45 117
Virtual User(Think time 0 sec)
측정후 다음과 같은 결론과 해석을 내려야 합니다.
1) Think Time이 0 으로 대입하였으므로, 테스트시에 대입한 User수는 "동시단말사용자수"를
의미하는 것이 아님을 분명히 인식시킨다.
2) 그래프(2-1)Throughput vs Virtual User 의 그래프에서, 최고 Throughput은 33.3 tps
이었다.
3) 그래프 (2-1)에서 최초로 최고의 Throughput이 나타나는 임계점은 Virtual User 117 명
이었다. (임계점이 Virtual User 117 이므로, 그래프상에서의 Virtual User는 0-150까지만
표현하여도 된다.)
3) 그래프(2-2) 평균응답시간 vs Virtual User의 그래프상에서, 임계점에서의 평균응답시간
즉, 임계평균응답시간은 3.5초로 나타났다.
해석:
만약, 본 시스템 사용자들의 평균 Think Time을 25초라고 가정한다면, 평균호출간격(Request
Interval)은 해당 임계점에서의 평균응답시간 3.5(sec)를 더하여 다음과 같다.

평균호출간격(Request Interval) = 평균응답시간 + Think Time ----------------[수식1]
= 3.5(sec) + 25(sec)
= 28.5 (sec).

따라서, "x(명)의 동시단말사용자가 28.5(sec) 간격으로 지속적인 호출을 발생하면,
서버측에는 평균적으로 33.3 (req/sec) 호출이 일어난다". 여기서 x는 다음과 같이,
동시단말사용자수X(명) / 평균호출간격(sec) = Throughput(req/sec) -----------[수식2]
라는 식으로 부터, 다음 식을 이끌어 낼 수 있다.
최대 동시단말사용자수(명) = Throughput(req/sec) x 평균호출간격(sec) --------[수식3]
= Throughput(req/sec) x {평균응답시간(sec) + ThinkTime(sec) }
= 33.3 (req/sec) x {3.5(sec) + 25 (sec)}
= 33.3 (req/sec) x 28.5(sec)
= 950(명)
따라서, 최대 동시단말사용자 950명을 수용할 수 있고, Think Time 25초를 가정하면,
서버측에는 1초당 33.3개의 서비스가 일어나며, 그 시점에서의 임계평균응답시간은 3.5초
이다.
요구조건에 대한 검증:
- 고객의 평균 ThinkTime 25초라는 가정하에, 최대수용가능한 동시단말사용자수는 위와
같이 950명으로, 요구된 500명보다 450명이 더 많다.
- 그러나, 950명의 동시단말사용자가 들어올 경우,즉 서버측에 33.3 (req/sec)로 호출이
일어나고 평균응답시간이 3.5초가 되는데, 이는 요구조건 3초이내에 있지 않다.
그러나, 고객과의 합의사항인 동시단말사용자 500명일 당시의 평균응답시간을 구해야
하는데, 동시단말사용자수는 호출빈도에 정비례하는 성질을 이용하여 다음과 같은 식을
도출할 수 있다. 동시단말사용자(명) : 호출빈도(req/sec) 의 비율식,
950(명) : 33.3(req/sec) = 500(명) : X(req/sec) ---------------------[수식4]

따라서, X ( req/sec) = 33.3(req/sec) x 500(명) / 950(명)
= 17.5 (req/sec)
즉, 500명의 동시단말사용자가 시스템을 사용하면, 서버측에는 초당 17.5 (req/sec)의
호출이 발생하게 된다. 이때의 평균응답시간이 어떻게 되는가? 그래프(2-1) 및 그래프
(2-2)에 이 정보가 모두 담겨 있을 것이다. 그래프 (2-1)에서 17.5 tps를 보이는 시점
에서의 Virtual User는 45명으로 나타났다. 이제 그래프(2-2)에서 Virtual User 45명일
당시의 평균응답속도는 얼마인가? 확인결과 2.5 sec 로 나타났다.

따라서, 500(명)의 동시단말사용자가 들어오면 서버측에는, 17.5 (req/sec)의 호출빈도가
일어나며, 이때 당시의 평균응답시간은 2.5 초로써, 고객의 요구 조건을 모두 만족한다.

따라서, 테스트 결과, 목표치를 모두 만족하고 있다.
[사족2: 위에서 Virtual User 45 및 117이 어떤 의미를 갖는 수치일까요?
동시단말사용자 500명이 접속하여 서버에 초당 17.5 (req/sec)를 보내고 있으며,
평균응답시간은 2.5(sec)를 유지할 당시, "Active유저수"는 45명이 될 것이며, 이는
또한 서버에서의 해당 시점에서 Running하고 있거나 큐잉되어있는 개수가 45개일 것
입니다.
만약, 동시단말사용자 950명이 접속할 경우, 서버에 초당 33.3(req/sec)의 호출빈도가
일어날 것이며, "Active유저수"는 117을 유지할 것입니다. 이는 서버에서 Running하고
있거나 큐잉되어있는 서비스의 개수를 의미합니다.]
4. 첨언
위와 같이 어느 방법을 사용하든 상관이 없습니다. 첫번째 방법은 웹스트레스테스트툴의
라이센스 비용이 많이 드는 반면, 실질적인 시물레이션을 할 수 있고, 두번째 방법은 적은
수의 Virtual User만으로도 계산적인 시물레이션을 할 수 있는 장점이 있습니다.
어느 것이나, 동일한 결과 및 동일한 결론을 얻을 수 있어야 하는 것은 당연한 것입니다.
어느 경우든, 핵심은 Throughput입니다. 단위시간당 최대로 처리할 수 있는 개수가 나오면,
몇명의 동시단말사용자를 수용할 수 있는지 바로 알 수 있습니다.
이에 반해 평균응답시간은 약간 다른 관점에서의 정보를 제공합니다. 10,000명을 수용할 수
있는 시스템일 지라도, 평균응답시간은 5분이 될 수도 있고, 3초가 될 수도 있습니다.
Throughput이 수용가능한 동시단말사용자수를 규정하는 변수라면, 평균응답시간은 서비스의
질을 규정하는 변수라고나 할까요.
5. 잘못된 스트레스테스트 시나리오를 정하는 경우.
대표적으로 잘못 테스트하는 경우는 다음과 같은 경우 입니다.
5.1 잘못된 벤치마크 시나리오 경우1
1) ThinkTime을 0 으로 셋팅하고,
2) Virtual User를 500명까지 끌어올린 후,
3) 그 때의 평균응답시간을 보아서, 3초 이내에 나오는 지를 확인 하는 경우입니다.

결과가 어떠할까요? 이처럼 테스트 할 경우 평균응답속도는,
3.5 (sec)
----------- x 500(명) = 14.96(sec) 가 나올 것입니다.
117(명)
이렇게 나온 14.96(sec) 결과가 무엇을 의미하는 수치인가요? 진정 아시나요?
[사족3: 예를 들어, 일일총방문자수가 700명인데, 업무적 특성으로인해 아침9시근방에
대부분이 몰릴 것이라는 가정을 해 볼 수 있습니다. 그래서 혹자는 총 방문자 7,00명중
500명이 아침9시에는 전부 접속할 것으로 보이니 "Active유저"가 500명이 가까이 될
것이다라는 잘못된 가정을 할 수 있습니다. 다시 한번, "일일총방문자수",
"동시단말사용자수", "Active유저수" 이 세가지 수치의 상관관계를 잘 생각해 보세요.
앞서 3.1의 응답시간(ResponseTime) 및 ThinkTime의 정의에서, "동시단말사용자수"와
"Active유저수"가 같다라는 것은 ThinkTime이 0 이라는 것과 같습니다. 즉, 9시근방에
모든 동시단말사용자 500명이 응답이 오자말자 ThinkTime없이 곧바로 다시 요청을 날리는
꼴이라는 것입니다. 이럴 수는 없죠. 즉, 결론적으로, "특정시각 근방에 사용자가
몰린다"는 것은, "일일총접속자수가 특정시각 근방에서 동시단말사용자수와 같을 수
있다"는 것은 있을 수 있으나, "동시단말사용자수가 Active유저수와 유사할 수 있다"는
절대적으로 틀린 이야기입니다. 다시 얘기하면, 예상되는 접속자 500명이 09시 근방에서
모두 "동시단말사용자"일수는 있어도, 결코 "Active유저"는 될 수 없습니다.
위 예에서 측정한 바와 같이, 동시단말사용자 500명일 경우에는 Active유저는 117명인
것입니다. (다음번 시나리오에서 동시단말사용자와 Actice유저의 상관관계수식이
언급됩니다.)
실제로는 발생하지도 않을 상황을 어거지로 가정하여 엉뚱한 테스트를 한 셈입니다. 더구나
이같은 테스트 결과로 나온 그 '평균응답시간'은 우리가 측정하려고 했던 그 수치가
아니라는데에 문제가 있다는 것이지요.]
5.2 잘못된 벤치마크 시나리오 경우2
1) ThinkTime을 0 으로 셋팅하고,
2) Virtual User를 동시단말사용자수의 10%인 50명까지 끌어올린 후,
3) 그 때의 평균응답시간을 보아서, 3초 이내에 나오는 지를 확인 하는 경우입니다.
이 경우는, 경험적인 수치인 "Active유저는 동시단말사용자의 10%일 것이다"라는 경험적
가정을 염두에 둔 경우입니다.
핵심은 그 10%가 진짜 10%일 것이냐가 관건입니다. 앞서의 경우, 동시단말사용자 500명일
경우에 Active유저수는 45명으로 나타났으나, 이를 50명으로 가정할 경우 다소 틀린
결과가 나타나겠지요.
수치적인 해석을 내려본다면, Throughput, Actice유저,평균응답시간에 관한 수식은
응답속도가 각각 s인 응용어플리케이션들이 동시에 n개가 수행되었다면, Throughput은
n/s 가 되는 것이 당연하므로, 다음과 같은 수식이 보입니다.
Throughput(req/sec) = Active유저수(명) / 평균응답시간(sec) ---------------[수식5]
즉,
Active유저수(명) = Throughput(req/sec) x 평균응답시간(sec) ---------------[수식5']

입니다. 예를 들어, Throughput이 17.5(req/sec)이고, 평균응답시간이 2.5(sec)라면,
Active유저수는 45명(17.5 x 2.5 = 43.75)이라는 것이지요.
여기에 앞서 [수식2]를 감안하면,
Active유저수(명) = Throughput(req/sec) x 평균응답시간(sec)
동시단말사용자수(명)
= ---------------------- x 평균응답시간(sec)
평균호출간격(sec)
동시단말사용자수(명)
= ------------------------------------ x 평균응답시간(sec)
평균응답시간(sec) + ThinkTime(sec)
평균응답시간(sec)
= 동시단말사용자수(명) x ----------------------------------- --[수식6]
평균응답시간(sec) + ThinkTime(sec)
과 같이 됩니다. 위 수식의 우측이 경험적으로 10%일 것이다라는 가정을 하고 있는
것이지요. 앞서 벤치마크시나리오의 경우에서, 동시단말사용자 500명일 경우에,
평균응답시간 2.5(sec), ThinkTime 25(sec)의 경우,
2.5(sec)/{2.5(sec)+25(sec)} = 0.0909(9.09%)가 나왔습니다.
반면, 동시단말사용자 950명일 경우에 평균응답시간 3.5(sec), ThinkTime 25(sec)의
경우는 3.5(sec)/{3.5(sec)+25(sec)} = 0.1228(12.28%)가 나왔습니다.
어쩌면, "흠, 그래. 그봐 10% 가까이 있잖아"라는 엉뚱한 결론을 속으로 내리고 있을
지 모르나, 위 수치들과 10%라는 수는 직접적인 상관관계를 갖고 있지 않습니다.
동시단말사용자수가 변함에 따라 평균응답시간이 늘어나기 때문에, 그 비율도 함께
덩달어 변하는 가변적인 수라는 것입니다.
[수식6])의 우측, 비율을 나타내는 부분은 함수 f(x) = x/(x+C),(C는 ThinkTime에 대한
상수) 로 표현할 수 있겠습니다. 근데, f(x)는 x-->+0(x가 +0을 갈때), f(x)-->0으로
수렴하며, x --> (+)infinity로 갈 때, f(x) --> 1(100%) 로 수렴하는 함수입니다.
10%가 맞아떨어지려면, x/(x+C) = 0.1(10%)를 만족하는 x 를 찾아보면 되는데,
x/(x+C) = 0.1
=> x = 0.1(x+C)
=> 0.9x = 0.1C
따라서, x = 1/9 x C, 즉, 평균응답시간이 ThinkTime의 꼭 1/9 일 때만, Active유저수가
동시단말사용자수의 10%가 된다는 얘기입니다.
"Active유저수는 동시단말사용자수의 10%이다"라는 말은, "평균응답시간이 ThinkTime의
1/9이다"와 완전히 의미를 같이합니다.

"10%"라는 지론이 누구로부터 시작되었는지는 모르지만, 웹어플리케이션서버기반으로
운영되고 있는 국내 사이트들에 대한 저의 경험으로는 동시단말사용자에 대한
Active유저의 비율은, 해당 사이트의 비즈니스적 특성, 응용어플리케이션 구현 특성에
따라 항상 달라지는 수치이며, 그 범위는 3%-30%에 이르기까지 너무나 다양한 형태로
도출되었습니다. 어떻게 믿을 수 있습니까? 주장컨데, "'10%설'은 죽었습니다."
[사족4: 왜 10%인 듯 한 경험적인 수치가 나왔을까요? ThinkTime은 대략 20-30초를 띠는
고정적인 상수값입니다. 20-30(sec)의 1/9는 2.2 - 3.3(sec)입니다. 아마, 경험하신
사이트의 어플리케이션 평균응답속도가 2.2 - 3.3 초 범위에 있었나보지요. 그런데
지금 테스트하려는 어플리케이션의 Virtual User증가에 따른 평균응답속도가 얼마인지
알고 10%가정을 할 수 있겠습니까?]
[사족5: 위 예에서 동시단말사용자가 500명이라면(ThinkTime 25초가정하에), Active유저는
몇명일까요? [수식6]에서,
Active유저수 = 500(명) x 2.5(sec)/{2.5(sec)+25(sec)} = 45명 이 됩니다.
이 수치는 동시단말사용자 500명일 당시의 평균응답시간을 알고 있기 때문에 구할 수
있습니다.]
6. 다음과제.
하나 이상의 응용어플리케이션을 테스트하는 경우는 다소 복잡한 이론 및 결과를
초래합니다. 핵심은 각 응용어플리케이션의 호출빈도의 서로간 비율을 정확히 산정해야
한다는 것입니다. 나름대로 연구한 [임계성능방정식]을 통해, 하나 이상의 응용
어플리케이션들이 실제 서비스를 할 경우, 몇명의 동시단말사용자수를 견디겠느냐와,
각각의 평균응답시간이 어떻게 될지를 판단하는 벤치마크테스트 방법에 관한 문서를
작성할 예정입니다.
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:011-898-7904
================================================