상용으로 Application Vantage, 로드러너 로 성능측정 하는 경우를 보았습니다만... 가격이 고가라는... ^^;
Application Vantage -
http://www.operativesoft.com/html/application_vantage.htm 에서 평가판을 받을 수 있다고 합니다.
리눅스에도 apachebench라는 툴이 있는데 사용을 해보지는 않아서....
업계에서는 Application Vantage나 로드러너의 성능 측정치가 공신력이 있다는 분위기가.... ^^
Network Vantage라는 툴은 네트웍진단에 사용한다고 합니다... 요것도 가격이...;;
무료로는 Microsoft Web Application Stress Tool이 있습니다.
MS Stress Tool Guide -
http://support.microsoft.com/default.aspx?scid=kb;ko;313559
Web
Application Stress Test
목 차
1 Web Application Stress Test
Overview.
2 Web
Application Stress Test Tool
A. ACT(Microsoft
Application Center Test)
? 스크립트 작성법..
? 테스트 속성 설정..
B. OpenSTA(Open
System Testing Architecture)
? 스크립트 작성법..
? 테스트 속성 설정..
C. ACT
vs OpenSTA.
D. Performance
Monitor(성능 모니터)
? 성능 카운터 항목..
? 성능 모니터 사용 권고 사항..
3 Web Application Stress Testing.
A. 스트레스 테스트 계획..
? 테스트 목적 설정..
? 테스트 환경 설정..
? 테스트 시나리오 정의..
B. 스트레스 테스트 실행..
? System Performance(응답시간)
? System Capacity(용량)
C. 스트레스 테스트 분석..
? 테스트 결과 분석 가이드..
웹 어플리케이션 개발 후 실제
운용 상황을 가상하여 테스트를 실시함으로써 어플리케이션, 시스템, 네트워크
상황들을 점검해보는 목적이다. 안정적으로 동시 사용자 x 명까지
수용할 수 있는 시스템이다라는 가정을 검증하는 과정이다.
ACT(Microsoft
Application Center Test)는 웹
어플리케이션에 대한 성능 테스트를 수행하고 관련 성능 정보를 수집하여 해당 웹 어플리케이션의 성능을 가늠해 볼 수 있게 해주는 툴이다. 웹 어플리케이션이 이용되는 상황을 스크립트로 작성하여 시뮬레이션 할 수 있다.
1. [시작] -> [프로그램] -> [Microsoft Visual Studio .NET] ->[ Visual Studio .NET
Enterprise Features] -> [Microsoft
Application Center Test]를 선택하여 ACT를 시작한다.
2. [파일]->[새 프로젝트]를 선택하여 프로젝트 이름과 저장될 위치를 지정한다. 이름 : WooriBanca Stress Test , 위치 : \
WooriBanca\Stress Test\
3. 새로 생성된 프로젝트 폴더의 [테스트]에서 마우스 오른쪽을 눌러 [새 테스트(N)…]를 선택한다. 5단계의 테스트 마법사가 실행된다.
4. 마법사 2번째 단계 ‘테스트 원본 선택’에서 “새
테스트 기록하기”를 선택한다. 이는 매크로 기능처럼 사용자가
취한 행위를 vbs 스크립트로 자동 생성해준다. 4번째 단계
‘브라우저 기록’에서 “기록시작”을 누르면 신규 브라우저가 화면에 나타난다. 이 페이지에서 시작하여
우리은행 Bancassurance 의 특정 업무를 수행하는 과정을 실제 시뮬레이션 한다. 끝나면, 기록중지를 누른다. 테스트
명을 지정(Woori Banca test)하고 마친다.
테스트 속성에는 일반 / 사용자 / 카운터 3개의
탭 페이지가 있다.
l
일반 : 테스트 회수, 시간 등을 설정
Ø
테스트
로드 수준 브라우저 동시 연결 수 : ACT는 지정된 수만큼 동시에 브라우저 연결을 설정한다. 실제 프로세스가 뜨는 것은 아니다.
Ø
테스트
지속 시간 : 지정한 시간 동안 반복적으로 테스트를 수행한다.
Ø
지정한
횟수만큼 테스트 실행 : 실행시간에 상관없이 스크립트 수행을 지정된 회수만큼 수행한다.
l
사용자 : 사용자 인증과 쿠키 처리 방식을 설정
l
카운터 : 테스트시 모니터링할 서버, 클라이언트의 성능 카운터 설정
Ø
테스트
수행과정에서 서버 및 클라이언트에서 모니터링 할 카운터를 설정한다.
Ø
원격 컴퓨터의 성능카운터를 확인하려면 관리자 권한이 있어야 한다.
OpenSTA(Open
System Testing Architecture)는 WAE(Web
Application Environment)하에서 동작하는 웹 서버, 어플리케이션 서버
및 데이터베이스 서버 등에 부하테스트를 수행할 수 있는 성능 테스팅 툴(Performance Testing
Tool)이다. 가상 유저(Virtual User)를
이용한 실 사용자와 동일한 부하를 생성할 수 있고 생성된 스크립트의 결과 등 분석 자료를 추출할 수 있다. http://opensta.org/download.html 에서
프로그램을 다운로드 할 수 있고 http://portal.opensta.org/
에서 필요한 기술 정보를 얻을 수 있다.
1.
[시작]
-> [프로그램] -> [OpenSTA] -> [OpenSTA Commander]를 선택하여 OpenSTA를 시작한다.
2. 아래의 그림의 메뉴를 이용해 새로운 테스트 스크립트를 생성하고 디폴트 이름을
적절하게 변경한다.
3. 생성된 스크립트를 더블 클릭하여 나온 아래와 같은 화면에서 
버튼을
클릭하여 브라우저를 통해서 테스트 시나리오를 레코딩한다.
4. 아래의 그림의 메뉴를 이용해 새로운 테스트를 생성하고 디폴트 이름을 적절하게
변경한다.
5. 테스트를 더블 클릭하여 나타난 화면에 테스트하고자 하는 Script를 끌어다 놓는다. 하나의 테스트에는 여러 개의 테스트 그룹이
포함될 수 있고 하나의 테스트 그룹에서는 순차적으로 실행되는 200개의 Script가 포함될 수 있다. 각각의 테스트 그룹별로 속성을 다르게
지정할 수 있다.
테스트 속성에는 VUs(가상 유저수) / Start(시작설정) 속성 등이 있다.
l
VUs(가상 유저수) : 스크립트를 실행하는 가상 유저수를 Task Group 별로 지정한다.
l
Start(시작설정) : 시작을 즉시할 것인지/스케줄을 사용할 것이지 등의 시작 설정과
반복 회수/실행 시간등을 지정한다.
|
|
ACT
|
OpenSTA
|
|
시나리오
|
단일 스크립트 방식 : 여러 개의 ACT를 동시에 실행할 경우 멀티 스크립트 가능
|
멀티 스크립트 방식 : 시나리오별 Virtual User 지정 가능 => 실제 사용 모습을 재현하는데 ACT에 비해서 용이
|
|
부하 단위
|
동시 브라우저 수
|
Active
Virtual User : 이해가 쉬움
|
|
분석 리포트
|
요약 / 페이지별 강력한 분석 보고서
|
ACT에 비해서 취약 : HTTP Data를
분석할 수 있음
|
|
용도
|
Capacity
측정을 위한 부하시 사용 적합
|
Capacity
측정을 위한 부하 및 낱개 페이지별 Response Time 측정에 적합
|
|
개별 특성
|
.vbs
파일 수정 가능
|
성능 테스트를 실행하는
클라이언트 리소스를 적게 사용(CPU 등 확인시)
|
|
Exchange
사서함 주소가 한글 사이트에 대해서 Auto recorded script를 일부 수정해 주어야 함
|
www.openSTA.org 공개 소스
|
l
클라이언트
사이드 : 성능 테스트를 수행하는 클라이언트에서 확인해야 할 내용.
|
개체
|
성능 카운터
|
표시 내용
|
|
Processor
|
% Processor Time/_Total
|
테스트 클라이언트의 프로세서 사용 량이다.
|
|
Memory
|
Available Bytes
|
테스트 클라이언트에서 사용할 수 있는 메모리의 양.
|
|
Network Interface
|
Bytes Total/sec
|
테스트 클라이언트에서 또는 테스트 클라이언트로 이동하는 네트워크 소통 량.
|
l
서버 사이드 : 성능 테스트를 수행하는 서버에서 확인해야
할 내용
|
개체
|
카운터
|
설명
|
해석
|
|
.NET CLR
Exceptions
|
# of
Exceps Thrown
|
응용 프로그램이 시작된 이후에 throw된 총 예외 수 이다. 이 값은 .NET 예외 및
.NET 예외로 변환되는 unmanaged 예외가 포함된 값. 예: unmanaged code의 null 포인터 참조 예외는 managed code에서 .NET System.NullReferenceException으로 다시
throw된다.
|
예외는 아주 드문 경우에만
나타나야 하며 프로그램의 정상적인 제어 흐름에는 존재하지 않는 것이 바람직.
|
|
ASP.NET
|
Requests Queued
|
처리 대기중인 요청수.. 이 숫자가 IIS 대기열
길이를 초과하면 "서버 사용량이 많습니다." 오류가
발생한다.
|
이 숫자는 0에 가까워야 한다.1보다 큰 경우, Request Wait Time을 동시에 해석하여 큐 대기시간을 동시에 파악해야 한다.
|
|
ASP.NET
|
Request
Execution Time
|
가장 최근 요청을 실행하는데 소요된 시간(ms)
|
적은 값일수록 요청을 빨리
처리했다는 증거.
|
|
ASP.NET
|
Worker Process Restarts
|
워커 프로세스(aspnet_wp.exe)의 재시작 회수.
|
웨커 프로세스의 recycling 시 이벤트 로그에도 그 기록이 남는다.
|
|
ASP.NET
Appliacations
|
Requests/Sec
|
초 당 실행되는 요청 수이다.
|
시스템의 처리 능력을 가늠.
|
|
Internet Information Services Global
|
File Cache Flushes and File Cache Hits
|
이 카운터를 비교하면 캐시 정리에 대한 적중률을 알 수 있다. 플러시는 파일이 캐시에서
제거될 때 발생한다. 이들 카운터는 개체가 캐시에서 플러시되고 있는 속도를 표시하고 있으며, 플러시가 너무 느리게 발생하면 메모리가 불필요하게 사용되는 것이다.
ObjectCacheTTL, MemCacheSize 및 MaxCacheFileSize 레지스트리
설정을 조정하면 이 값을 조정할 수 있다.
|
|
|
Internet Information Services Global
|
File Cache Hits %
|
이 카운터는 총 캐시 요청에 대한 캐시 적중률을 표시.
|
정적 페이지가 있는 사이트의
캐시 적중률은 약 80%이어야 한다.
|
|
Memory
|
Available Bytes
|
이 숫자는 남아 있는 사용 가능한 실제 메모리의 양 표시함.
|
|
|
Memory
|
Cache Bytes
|
정적 파일에 사용된 캐시 크기를 표시. 기본적으로 캐시 바이트는 사용 가능한 메모리의 약 50%로 설정되지만 사용 가능한 메모리가 감소하여 시스템 성능이 저하되면 더 낮게 설정된다.
|
|
|
Memory
|
Pages/sec
|
서버의 메모리가 부족하여 서버의 작업 부하를 처리할 수 없으면 이 숫자는 지속적으로 올라갑니다.
|
|
|
Memory
|
Pool Paged Bytes and Pool Nonpaged Bytes
|
풀에는 응용 프로그램과 운영 체제에서 만들고 사용한 개체가 저장됩니다. 풀이 채워지면 메모리
누실이 있을 수 있습니다.
|
|
|
Network Interface
|
Bytes Total/sec
|
사용 가능한 대역폭과 이 값을 비교하면 발생할 수 있는 네트워크 병목 상태를 명확하게 표시할 수 있습니다. 일반적으로 바이트 수/초는 사용 가능한 총 대역폭의 50% 이하로 유지해야 합니다.
|
|
|
Object
|
Threads
|
Threads는 프로세서에서 명령을 실행할 수 있는 기본 실행 엔터티입니다. 이 숫자가 시간에 따라 계속 커지면 Process:Thread Count
카운터를 열어 모든 스레드를 만들고 있는 인스턴스를 확인합니다.
|
|
|
PhysicalDisk
|
% Disk time
|
읽기/쓰기 작업을 하는 디스크의 경과된 시간을 비율로 표시합니다. 이 카운터 숫자가 높고 프로세서 및 네트워크 대역폭이 포화되어 있지 않으면 디스크 병목 현상이 발생할 수
있습니다. 이 카운터를 로깅하기 전에 Windows 2000 명령줄에서 "diskperf -yD"를 실행하십시오. 지속적으로
숫자가 80% 이상이면 메모리 누실을 나타내는 것일 수 있습니다.
다중 디스크 시스템에 대해 이 카운터의 0 인스턴스에서 x 인스턴스까지 추가하도록 합다.
|
|
|
PhysicalDisk
|
Disk Queue Length
|
아직 해결되지 않은 요청 수를 디스크에 표시합니다. 한 디스크에 표시되는 대기열 길이가
지속적으로 3 이상이면 디스크, 메모리 또는 SQL Server 구성 문제를 나타냅니다.
|
|
|
Process
|
Private Bytes - _Total
|
다른 프로세스와 공유할 수 없는 모든 인스턴스가 할당한 현재 바이트 수를 표시합니다. 목록에서 _Total 인스턴스를 선택합니다. 메모리를 모두 소모하고 있는
것으로 간주되는 다른 모든 인스턴스를 선택.
|
|
|
Process
|
Private
Bytes(inetinfo 인스턴스)
|
Private Bytes(inetinfo)는 다른 프로세스와
공유할 수 없는 HTTP/ASP 서비스가 할당한 현재 바이트 수 입니다. 이 숫자가 지속적으로 커지면 서버쪽 개체에 누실이 있을 수 있습니다.
Process: Private Bytes(_Total)와 비교해야 한다.
|
COM+내 Server
Type(dllhost.exe)의 카운터 값도 모니터링해야 한다.
|
|
Process
|
Thread Count(inetinfo 인스턴스)
|
웹 서버 프로세스에서 만든 스레드 수입니다.
|
|
|
Processor
|
% Processor Time(_Total 인스턴스)
|
이 카운터를 통해 프로세서 포화 상태를 가장 잘 볼 수 있습니다. 모든 CPU에서 스레드를 처리하는 데 소비된 시간을 표시합니다. 하나
이상의 프로세서에서 숫자가 지속적으로 90% 이상이면 하드웨어에 대한 테스트가 지나치게 집중되어
있다는 것을 나타냅니다. 다중 프로세서 서버에 대해 이 카운터의
0 인스턴스에서 x 인스턴스까지 추가하십시오.
|
|
|
Processor
|
Interrupts/sec
|
프로세서 사용률이 90% 이상이고 인터럽트 시간 백분율이
15%보다 크면 프로세서는 지나치게 인터럽트됩니다.
|
|
|
Server
|
Bytes Total/sec
|
네트워크 동작을 표시합니다.
|
|
|
System
|
Processor Queue
Length
|
이 카운터는 웹 서버의 모든 프로세서가 공유하는 대기열에서 실행 대기하고 있는 스레드 수를 표시합니다.
|
프로세서 병목 상태가 되면 지속적으로 값이 2보다
커질 수 있습니다.
|
|
System and Thread
|
Context Switches/sec, Context Switches/sec:
dllhost(thread # instance) 및 Thread:
Context Switches/sec: inetinfo(thread # instance)
|
이들 카운터는 시스템 전체에서 발생하는 컨텍스트 전환 수와 IIS 5.0 내에서만 발생하는
컨텍스트 전환 수를 표시합니다.
|
|
|
Thread:
|
% Processor Time: InetInfo => Thread #
|
InetInfo 프로세스의 각 스레드가 사용하는
프로세서 시간을 나타냅니다.
|
|
|
Thread:
|
Context Switches/sec: InetInfo => Thread #
|
IIS 서비스의 스레드가 프로세서의 설정 또는 해제를 전환하는
횟수를 나타냅니다.
|
|
|
Web Service
|
Bytes Total/sec
|
웹 서버에서 보내고 받은 바이트의 합계를 표시합니다.
|
|
|
Web Service
|
Current Anonymous Users
|
인증되지 않은 스트레스 테스트 동안 서비스에 연결되어 있는 현재 연결 수를 표시합니다.
|
|
|
Web Service
|
Current Connections
|
HTTP 서버에 현재 연결되어 있는 인증된 사용자 수입니다.
|
Current Non-Anonymous Users 수와 동일.
|
|
Web Service
|
Not Found Errors
|
반환된 404 응답 코드 수를 표시합니다.
|
|
l
최대 4시간까지 모니터링하는 경우 모니터링 빈도는 15sec(Default)을
유지한다. 8시간이상 모니터링하는 경우 시스템의 Overhead를
줄이기 위해 300sec(5분)이상으로 설정한다.
l
모니터링
주기는 15분을 기본으로 한다.
l
사용자 임계치 정의
예) 급여오픈시 3,000 User가 30분간 집중적으로 로그인함
예) 출근 직후 혹은 퇴근 직전 1시간동안 1,000 User가 집중적으로 로그인 후 보험 실적 입력
예) 동시 사용자 200 User가 3초안에 로그인 할 수 있도록
l
L4 Switch의 Balancing Algorithm을 고려하여 각 서버 그룹을 1대를
대상으로 할 것인지 서버 그룹 내 2대의 서버를 모두 대상으로 할 것인지 등을 결정
예) 사용자 요구 사항이 동시
사용자 200 User 일 때 전체 Web/App 서버가 4대로 구성될 경우 한 서버에 동시 사용자 50 User를 테스트, Web/App 서버 이후의 Back-End 서버는 모두 정상 가동
l
스트레스
테스트에 사용되는 데이터베이스를 테스트 환경에 맞추어 설정한 후 반복적인 테스트에 쉽게 대응할 수 있도록 백업하거나 원상 복구용 스크립트를 작성해
주는 것이 좋다.
l
테스트
시나리오 범위
Ø
전체
시스템 중 다른 서버와의 연계 및 시스템의 핵심 기능, 성능에 영향을 미칠 것으로 보이는 모든 접점을
범위로 하여 시나리오 구성 : 로그인, 게정계와의 연동, 타보험사와의 연동 등
l
테스트
시나리오 정의 예
Ø
로그인 (동시 사용자 200명) : 동시
사용자 200명 로그인 테스트
Ø
로그인 -> 계정계와의 연동(동시 사용자 100명) : 동시 사용자 100명으로
로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 100명의 동시 사용자를 [로그인 -> 계정계와의 연동]
테스트
Ø
로그인 -> 타보험사와의 연동(동시사용자 50명) : 동시 사용자 100명으로
로그인 단계에 부하를 가하고 있는 상태에서 추가적으로 50명을 [로그인 -> 계정계와의 연동] 시나리오로 부하를 준다. 이 상태에서 다시 50명의 부하를 [로그인 -> 타보험사와의 연동]에
가한다.
l
현상계
사용 시나리오에 준해서 OpenSTA로 부하를 가하고 ACT를
이용해서 Performance에 대한 보고서를 얻어낸다.
예) 로그인 -> 타보험사와의 연동(동시사용자 50명)
[OpenSTA]
Ø
로그인 : 동시 사용자 100명 부하
Ø
로그인 -> 계정계와의 연동 : 동시 사용자 50명 부하
Ø
로그인 -> 타보험사와의 연동 : 동시 사용자 50명 부하
[ACT]
Ø
로그인 -> 타보험사와의 연동 : 동시 브라우저수 1개로 부하를 가하면서 Performance 보고서를 취득
l
성능
모니터를 이용한 성능 카운터(메모리, CPU, 디스크, 프로세스 등)를 이용해서 보고서를 얻어낸다.
l
테스트
결과에서 많은 양의 에러(응답 코드 200번 보다 큰 응답
코드)를 발견할 경우, 에러 발생 지점은 성능이나 병목 이슈의
후보가 될 수도 있다.
l
스트레스
테스트 도구들은 Ramping Up 스트레스를 준다. 즉, 처음에는 부하의 수준을 조금 주다가 시간이 흐를수록 부하의 수준을 늘려가게 된다. 시스템에 어느 정도의 부하에서 테스트가 실패하는지도 살펴볼만한 요소가 되나.
l
시스템의
성능의 관점에서 RPS(Request Per Second)의 값은 서버의 Capacity와 테스트 시나리오에 모두 관련이 있다. RPS값은
테스트 시나리오의 복잡성, 서버의 Capacity와 관련이
있으므로 절대적인 응답시간이나 Capacity의 기준으로 간주해서는 안되며 하나의 참조자료가 될 수
있다.
l
시나리오의
응답시간은 ACT의 결과인 “반복 당 평균 TTLB(밀리초)”가 좋은 척도가 된다.
l
부하분석
결과 예)
|
부하 시나리오
|
서버용량
|
응답속도
|
|
시나리오
|
|
CPU%
|
RPS
|
Queue
|
CC
|
평균(Sec)
|
최소
|
최대
|
|
로그인
|
10
|
10
|
6
|
0
|
24
|
5.67
|
4.00
|
9.00
|
|
20
|
19
|
12
|
0
|
49
|
5.57
|
4.00
|
7.00
|
|
50
|
34
|
28
|
0
|
113
|
5.71
|
4.00
|
11.00
|
|
75
|
58
|
43
|
0
|
188
|
5.61
|
4.00
|
10.00
|
|
100
|
84
|
50
|
1
|
235
|
7.08
|
4.00
|
12.00
|
|
125
|
86
|
54
|
1
|
350
|
8.33
|
4.00
|
14.00
|
|
150
|
86
|
54
|
1
|
349
|
12.00
|
4.00
|
20.00
|
|
200
|
92
|
51
|
3
|
450
|
16.24
|
5.00
|
28.00
|
|
300
|
91
|
48
|
20
|
672
|
31.24
|
6.00
|
46.00
|
Ø
위의
로그인 프로세스의 경우 동시 사용자 100명일 경우가 현재 시스템이 커버할 수 있는 최대수로 보여진다. 100명일 경우와 150명일 경우 CPU 평균 사용량(84~86)과
RPS(50~54)등이 모두 비슷하지만 응답시간의 경우 많은 차이(7.08~12.00)를
보인다. 따라서 시스템이 커버할 수 있는 적정 동시 사용자수는 100명으로
볼 수 있다.
l
부하
테스트의 결과 현재의 시나리오에서 시스템이 커버할 수 있는 동시 사용자수와 응답 속도가 사용자의 요구에 만족스럽지 않을 경우
Ø
ACT의 페이지별 TTLB를 확인하여 오래 걸리는 페이지에 대한 추가적인 조사 작업을 수행
Ø
OpenSTA의 결과인 HTTP Data List의 데이터를 이용하여 특정 시나리오내의 구간을 정의하여 구간별 응답시간을 상세히 분석해
볼 수 있다(수작업 필요).
Ø
다른
요소(Database 등)에 성능상의 문제가 없는지 확인.
출처 : http://www.gosu.net/GosuWeb/Article-detail.aspx?ArticleCode=321