Scent of Life __ ACT(Application Center Test) Stress Test

몇 년 전에 Stress Test 툴인 ACT(Application Center Test)를 사용하여 간편 테스트를 수행해본 적이 있다. 그때 작성한 문서인데 실제 시스템의 명칭은 MOMS(모 Management System :)로 변경하였다. 내공이 부족하여 내용이 그리 좋진 않다. -_- 지금도 마찬가지지만... ^^;

툴 소개에 의미를 가지려 한다.. :^)

１ 개요

MOMS의 업그레이드 관련 자료로 활용하기 위한 MOMS의 1차적인(정식이 아닌 시험적인) 성능 측정을 실시해보았습니다. 범위를 최소화하여 MOMS의 시스템 업무 중 Response Time이 길다고 생각되는 특정 페이지를 대상으로 한 간편 테스트이므로 이 자료를 통해서 MOMS의 정확한 performance를 파악할 수는 없습니다. 시스템의 가장 이상적인 performance를 측정하기 위해서는 정식 시나리오를 작성하고 대상 시스템을 최적화하는 초기 작업이 필요하며 외부의 개입으로 발생할 수 있는 변수를 최소화하고 시스템 전체를 포괄하는 범위 내에서 반복 작업을 수행해야 합니다. 결과에 수많은 오류가 있을 수 있지만 바로 그러한 작업을 하기위한 기초 다지기로서 의미가 있는 측정이라 생각합니다.

가) 성능 측정(Stress Test)의 목적

① 현 시스템의 대략적 performance를 측정.

- 응용 프로그램에서 사용한 최대 하드웨어(CPU 사용률, 메모리 사용) 용량을 확인.

- 처리량을 근거로 동시 사용자(Concurrent User)와 초당 요청 수(RPS)의 임계값 측정

② Windows 2003 Server와 IIS 6.0의 환경 설정 튜닝의 근거 자료로 활용.

③ MOMS업그레이드 시 ASP(classic Active Server Pages)와 ASP.Net의 비교 자료로 활용.

④ 성능 테스트 자체를 위한 노하우와 자료 수집.

２ Stress Test 환경

성능 테스트의 대상인 MOMS 시스템의 대략적 구성 및 테스트 환경을 정의합니다. 자세하게는 하드웨어 및 소프트웨어의 구성을 확인하고 서버의 구성과 보안 구성 등 시스템 전반에 대한 사항을 확인해야 합니다.

Internet Information Server와 데이터 액세스 구성 요소에 대해 스트레스 테스트를 효과적으로 실행하고 결과를 정확하게 진단하려면 모니터링 및 기록 통계 방법이 중요한데, 이것을 위해 OS에서 제공하는 성능 모니터 중 대상 성능 모니터를 지정합니다.

가) H/W

① 모델 - IBM eServerxSeries 255

② 스펙 - Xeon MP 2.7GHZ * 4CPU, 4G Memory

③ 네트워크 대역폭 -

나) S/W

① OS - Windows 2003 Server

② WAS - Internet Information Service 6.0

③ DB - SQL Server 2000

④ Application – ASP(COM+), ASP.Net(Remoting, Microsoft .NET Framework 1.1)

다) 대상 업무

① 공사관리(70) - 운영서버의 공사관리시스템(ASP.Net)의 로그인, 마이페이지 등

② 수불현황(70) - 운영서버의 시설관리(ASP)의 자재 업무 중 수불현황 페이지

③ 수불현황(72) - 개발서버의 시설관리(ASP)의 자재 업무 중 수불현황 페이지(옵션)

라) 테스트 방법(원칙)

① Stress Tool(Web Spiders)로서 ACT(Application Center Test)를 사용한다.

② 서버의 CPU 사용률이 최소한 80% 이상이 될 때까지 브라우저(동시 사용자) 수를 늘려가며 반복 측정하도록 한다. 80%는 일반적으로 웹 서버와 웹 응용 프로그램의 최대 용량을 알아 보기 위한 기준점이다.

마) 모니터링 대상 성능 카운터(Performance Counter)

개체	성능 카운터	표시 내용
Processor	% Processor Time/_Total	서버의 프로세서 사용 수준
Memory	Available Bytes	서버의 가용 메모리의 양
Active Server Pages	Requests Queued	이 숫자는 0에 가까워야 한다. 이 숫자가 IIS 대기열 길이를 초과하면 "서버 사용량이 많습니다." 오류가 발생한다.
Active Server Pages	Requests/Sec	초 당 ASP 요청 수
SQL Server:General Statistics	Logins/sec	초 당 SQL Server에 로그인하는 수
SQL Server:General Statistics	User Connections	활성 상태의 SQL 사용자 수
SQLServer:Locks	Lock Waits/sec	현재 프로세스가 완료될 때까지 다른 프로세스가 대기하도록 하는 초 당 잠금 요청 수를 표시한다. 이 숫자가 지속적으로 0보다 크면 트랜잭션 문제를 나타낸다.
SQLServer:Locks	Number of Deadlock/sec	Deadlock
SQL Server:Databases	Transactions/sec	시작된 총 트랙잭션 수 입니다.

３ Stress Test 실행

위에 기술한 세가지 테스트 대상에 대해 ACT의 브라우저 수를 1, 5, 10, 15, 20, 30, 40, 50, 60, 70, 80, 90로 변경하면서 각각 1분 단위로 12회의 테스트를 진행하였습니다.

다음은 세가지 테스트 대상 중 운영서버의 공사관리시스템(ASP.Net)과 MOMS 수불현황 페이지에 대한 테스트 실행 그래프를 나타냅니다.

* 테스트 실행 그래프 – 공사관리(70)

* 테스트 실행 그래프 – 수불현황(70)

참고로 브라우저 수는 Concurrent User 혹은 Active Client와 유사한 의미를 갖습니다. 이 숫자는 실제 사용자와 비교하여 1/10로 보는 것이 맞단 내용을 보았지만 정확하지는 않습니다. 이 경우 위의 수에 각각 * 10을 해줘야 실제 사용자 수가 된다는 의미입니다.

가) 결과 보고서 - 그래프

① 수불현황(70) 및 수불현황(72)의 RPS(평균) 대 브라우저 연결

② 수불현황(70) 및 수불현황(72)의 TTLB(평균) 대 브라우저 연결

③ 수불현황(70) 및 수불현황(72)의 대역폭(평균) 대 브라우저 연결

④ 공사관리(70)의 RPS, TTBL, bandwidth(평균) 대 브라우저 연결

나) 결과 보고서 - 성능 카운터

테스트 시 모니터링한 성능 콘솔 화면 샘플입니다. ACT의 실제 결과치는 아래 표로 작성되었으며, 동시 브라우저 수인 1, 5, 10, 15, 20, 30 항목들은 생략되었습니다.

① % Processor Time/_Total (평균, 단위:%)

	40	50	60	70	80	90
수불현황(70)	75.99	62.87	70.86	71.60	79.96	89.63
수불현황(72)	93.09	98.20	93.31	98.45	99.01	85.09
공사관리(70)	75.08	75.96	85.87	54.20	45.06	55.44

② Memory (평균, 단위:MByte)

	40	50	60	70	80	90
수불현황(70)	1637	1648	1627	1509	1535	1591
수불현황(72)	97	100	94	98	97	185
공사관리(70)	1643	1651	1634	1629	1647	1547

③ Requests Queued (평균 평균, 단위:건)

	40	50	60	70	80	90
수불현황(70)	2.00	0.57	1.00	0.00	0.00	0.57
수불현황(72)	0.54	36.69	7.54	61.00	110.77	26.18
공사관리(70)	6.00	8.86	16.14	19.86	21.14	27.71

④ User Connections (평균 평균, 단위:건)

	40	50	60	70	80	90
수불현황(70)	203.86	222.43	240.71	248.00	255.29	291.43
수불현황(72)	135.46	189.54	101.62	213.92	208.54	3975.46
공사관리(70)	78.00	67.29	310.86	89.57	57.00	290.00

⑤ Number of Deadlock/sec (평균 평균, 단위:건)

	40	50	60	70	80	90
수불현황(70)	0.00	0.00	0.00	0.00	0.00	0.37
수불현황(72)	-	-	-	-	-	-
공사관리(70)	0.03	0.00	0.00	0.00	0.00	0.00

４ 결론

먼저 테스트에 영향을 줄 수 있는 좋지 않은 외부 요인들 몇 가지를 짚어보고 Stress Test의 결과 보고 내용을 분석해보겠습니다.

그전에 미리 언급할 내용으로, 수불현황(70), 수불현황(72), 공사관리(70) 등의 테스트 결과 그래프 중 “RPS(평균) 대 브라우저 연결”을 보면 수불현황(70)을 제외한 두 결과의 경우 전형적이지 못한 비정상적인 그래프를 나타내고 있습니다. 테스트 환경이 최적화되지 않은 상태에서 공사관리(70)의 경우 외부 요인의 개입이 있었던 것으로 추측되며 특히 수불현황(72)의 경우 말 그대로 잘 관리되지 않는 개발서버가 가지는 불안요소 들로 인해서 운영서버에서의 수불현황과 달리 전형적인 그래프를 보여주지 못하고 있습니다. 개발서버에서의 수불현황(72)는 단지 운영서버에서의 수불현황(70)에 비해서 성능상의 확연한 갭이 존재함을 확인하는 수준에서 더 이상의 언급은 하지 않겠습니다. 공사관리(70)는 아래 결과에서 보면 알겠지만 테스트 순서 상의 미숙한 조작으로 인해서 상호 영향이라기보다는 일방적으로 수불현황(70)의 테스트 영향을 적지 않게 받은 듯 합니다. 두 테스트를 동일한 사용자 수에 맞춰서 번갈아 가면서 테스트를 진행했는데, 상위의 해당 공사관리(70)의 RPS 그래프를 보면 지그재그를 그리고 있는 것이 단적인 근거가 될 듯 합니다. 좀더 정확한 테스트를 위해서 공사관리(70)는 재 시도해볼 필요가 있습니다.

가) 테스트 결과에 반영해야 할 전제 조건(고려 사항)

① 시험적인 간편 테스트로서 정식 시나리오가 없으며 전체 시스템 범위를 포괄하지 않았다. 이로 이해 결과가 시스템 전체의 정확한 성능을 나타내지는 않는다.

② 최적화된 환경이 아니다.

테스트에 적합하도록 시스템을 최적화 하는 작업이 선행되지 못했다. 또한, 오버헤드와 메모리 누수를 비롯한 대부분의 문제는 응용 프로그램이 과도한 시간동안 실행된 후에야 나타난다. 아무런 방해가 없는 실제 사용자 환경에서 충분히 긴 시간동안 stress test를 실행해야 하는데 실제로는 업무가 과중하지 않은 점심 시간 및 저녁 무렵에 1분 단위로 테스트되었을 뿐이다. 외부 요인으로 인하여 테스트 대상에 대한 성능에 오차가 있다.

③ 외부 요인이 없었다 하더라도 운영 서버와 테스트 서버의 동기 문제(h/w, s/w, application version)가 있으므로 수불현황(70)과 수불현황(72)의 결과는 차이가 있을 수 밖에 없다.

④ 공사관리(70)의 경우 수불 현황에 비해 좀 더 넓은 범위의 테스트가 진행되었다. 마이페이지 외에 몇몇 현황 업무 페이지 로드를 포함하며 로그인 프로세스에 원스탑이 포함되어 외적인 변수가 많았다.

나) 테스트 결과에 대한 고찰

① CPU 사용률

MS에서는 peak time일 때 프로세서 평균 사용량이 75%를 넘지 않아야 정상적인 웹서비스가 가능하다고 권고하고 있다. 좋은 장치에서는 최대 로드일 때 프로세서 사용률이 50% 이상이어야 한다. 사용률 값이 낮으면 시스템에서 해결해야 하는 다른 병목 현상이 있음을 나타내며 스레드 충돌 문제일 수 있다.

테스트 결과, 표, “% Processor Time/_Total” 성능 카운터에서 볼 수 있듯이 먼저 수불현황(70)은 브라우저 수가 70 까지는 75%의 범위 내의 사용률을 보여주고 있다. 표에 표시되지는 않았지만 최소 사용률도 50%를 약간 상회하는 것으로 보여진다. 공사관리(70)의 경우 브라우저 수가 90을 넘어서서도 사용률이 크게 올라가지 않았다. 단 최소 사용률은 50%를 약간 밑돌고 있다.

특이할만한 것은 수불현황(70)이 공사관리(70) 보다 평균 사용률이 높다는 점이다. 또한 성능 콘솔을 관찰한 결과에서도 차이가 나는데, 두 테스트가 비슷한 70%의 사용률인 경우라 하더라도 수불현황(70)은 최대 100%를 차지하는 구간이 꽤 긴 반면에 공사관리(70)은 구간 내내 70% 대를 유지하고 있다.

이것은 두 테스트에 사용된 기술(ASP vs ASP.Net)과 데이터 액세스 컴포넌트(COM+ vs Remoting Object) 등에서 기인하는 차이로 생각된다.

② 메모리 사용

표, “Memory” 성능 카운터에서 확인할 수 있듯이 크게 이상이 있는 부분은 없다. 당연하지만 동시 사용자수가 증가할수록 사용할 수 있는 메모리가 조금씩 줄어드는 것을 볼 수 있다.

③ 데이터

각 페이지를 기본으로 연결 개체를 만든 다음 바로 해제하면 데이터베이스는 열린 데이터베이스 연결 수를 최소로 하여 수많은 동시 사용자를 처리할 수 있다. 이렇게 하면 데이터베이스 리소스가 절약되고 더 많은 확장성이 제공된다. 데이터 서버에서 성능 모니터로 사용자 연결 수를 추적하여 이러한 성능을 모니터한 결과, 표, “Usr Connectiions”에서 보는 바와 같이 수불현황(70)에서 사용자 연결 수가 현저히 높아짐을 알 수 있다. 공사관리(70)의 경우에도 특정 부분에서 매우 높은 경향이 있는데, 이것은 테스트 진행 순서의 문제로 수불현황(70)의 영향을 받은 것으로 생각된다.

처리량이 증가하려면 데이터 서버에서 실제로 만들어진 연결 수를 풀링(리소스/연결)에서 제어할 때 사용자 연결 수가 안정적으로 유지되도록 해야한다. 수불현황(70)의 경우 좀 더 정확한 원인을 파악해볼 필요가 있다.

또한 표, “Number of Deadlock/sec”를 보면 부분 적으로 경미한 교착 상태가 발생하는 부분이 있다. 이러한 충돌을 피하기 위해서 해당 코드의 알고리즘을 확인해볼 필요가 있다.

④ 처리량

대기열에 존재하는 요청은 0에 가까워야 한다. 이 숫자가 IIS 대기열 길이를 초과하면 "서버 사용량이 많습니다."와 같은 오류가 발생한다. 표, “Requests Queued” 성능 카운터를 보면 수불현황(70)의 경우 요청 처리가 원활하지만 공사관리(70)의 경우 다소의 딜레이가 발생하고 있음을 확인할 수 있다.

결과 보고서 그래프에 따르면 수불현황(70)의 경우 동시 브라우저 수 80을 기점으로 RPS가 크게 떨어진다. TTLB 역시 동시 브라우저 수 80을 기준으로 선형적인 증가 곡선의 조짐을 보이고 있다. 또한 동시 브라우저 수 80에서의 CPU 점유율은 79.96%이고 대기열의 Request는 0에 가깝다. 따라서 수불현황(70)은 최대 동시 브라우저 수가 80 일때 초당 180 정도의 요청 수를 처리하는 성능을 최적으로 볼 수 있다. 단 순간 CPU 점유율이 100% 대에서 유지되는 부분이나 데이터베이스 사용자 연결 수가 지나치게 많은 점을 감안한다면 성능은 다소 감소할 것이다. 이 부분에 대한 튜닝이 필요하다.

공사관리(70)의 경우 그래프 상으로는 적정 성능을 파악하기 힘들다. 외부 변수들을 제거한 후 다시 테스트를 해야겠지만, RPS를 보여주는 지그재그 형태의 그래프 상에서 각 상위 지점을 연결하여 생각한다면 동시 브라우저 수가 50에서 70으로 넘어가는 구간에서 RPS가 떨어진다고 생각할 수 있을 듯 하다. 해당 구간에서의 RPS는 100 정도의 수치로 수불현황(70)에 비해 떨어진다.

５ 정리하는 글

MOMS 업그레이드의 기술적 부분과 관련해서 현재 시스템이 가지는 성능상의 문제 요인을 유추해내고 정리하던 중 부족한 지식으로 시행착오를 거치며(또는 여전히 시행착오 중인) 부하 정도가 심한 특정 ASP 페이지와 ASP.Net(ASP-ASP.Net의 비교를 위해)으로 만들어진 페이지들을 대상으로 Stress Test를 진행하게 되었습니다. (개요 부분의 성능 측정의 목적을 참고)

운영 서버의 수불 현황 및 공사관리에 대해서 ACT로 부하 측정을 해본 결과 각 시스템(응용 프로그램)의 적정 성능은 동시 브라우저 수가 60, 80 정도인 경우에 포화상태에 도달하며 100에서 180 정도의 RPS 임계 수치를 나타내는 것으로 생각할 수 있습니다.

Stress Test의 결과 그래프로 전형적인 형태의 곡선을 얻기 위해서는 수없이 많은 테스트와 시스템의 튜닝이 필요하다고 알고 있습니다. 시스템에 기대할 수 있는, 또는 업무 상 필요로 하는 성능을 최대한 발휘할 수 있도록 시스템을 정비하고 환경 및 응용 프로그램의 아키텍쳐를 최적화 하고 데이터베이스를 튜닝하는 부단한 노력이 필요합니다. 또한 각 단계별로 시나리오에 근거한 Stress Test가 병행되어야 하며 그 결과에서 얻은 정보를 바탕으로 또 다시 시스템을 튜닝하는 작업이 반복되어져야 합니다.

적정 성능을 얻기 위해서 튜닝과 성능 측정은 상호 보완하는 셈입니다. 하지만 보다 큰 규모의 시스템에서는 정확한 테스트를 위해서 보다 많은 기능을 보유하는 상용 Tester가 필요할 수도 있고 튜닝만으로 원하는 성능을 얻기에 한계가 있을 수 있습니다. 이 경우, H/W 혹은 S/W를 업그레이드 해야 하는 경우도 있습니다. Internet Information Server를 실행하는 응용 프로그램의 수와 종류를 모니터링 하여 서버를 추가하고 응용 프로그램을 다른 서버로 이동하거나 로드 밸런싱과 분산 환경을 구축해야 원하는 성능을 얻을 수도 있습니다.

하지만 이것은 보다 큰 시스템을 포괄하는 성능 측정의 일반적인 이야기이고, 현 시점에서의 MOMS 성능 측정과 관련한 주요 이슈는, 바로 원하는 성능의 분기점이 어디인가라는 것입니다. IIS의 로그를 분석하여 peak time에서의 동시 사용자가 어느 정도 되는지, 사용자들이 받아 들일 수 있는 페이지 로드 한계 시간(8초 룰은 옛말, 현재는 4초 룰을 넘어 3초 혹은 2초 룰이 기본 요건화 되고 있습니다)은 몇 초인지 하는 등의 적정 성능의 목표를 도출해 놓고 그것을 기준으로 지금과 같은 시험적 테스트를 능가하는 보다 정확한 시나리오에 근거한 Stress Test와 시스템 업그레이드와 튜닝의 지속적인 반복 작업이 수행되어야 할 것입니다.

환경적인 요인과 성능 측정에 대한 이해 부족으로 인하여, 테스트를 진행함에 있어 주요한 팩터들이 누락되고 해석의 오류가 필연적으로 수반되었을 것입니다.

그러한 점을 지적해 주십시오.

프로젝트 개발 사이클에서 Stress Test의 비중은 결코 작지 않습니다. 그럼에도 불구하고 예전 모시스템 개발 시절에 모두들 PC 앞에 모여 앉아 신호에 맞춰 동시에 엔터 키를 누르던 기억이 납니다. 함께 고민하며 서로의 스킬을 증진 시킬 수 있는 기회가 될 수 있기를 바랍니다.

６ 부록 (관련 Resources)

가) Web Spiders – 무료 Stress Tool 소개

① ACT(Application Center Test)

- Microsoft Application Center Test 1.0, Visual Studio .NET Edition

② WAST(Web Application Stress Tools)

- MS Web Application Stress Tutorial

- Web Application Stress Tool 1.0 Download

나) 웹 테스팅에 필요한 주요 카운터 (MSDN 발췌)

테스트를 실행하는 동안 테스트 클라이언트의 성능 카운터 및 모든 웹 서버를 모니터링해야 합니다. Application Center Test는 테스트하는 동안 HTTP 성능 통계를 자동으로 모니터링하지만 성능 카운터는 테스트 실행 전에 명시적으로 구성해야 합니다.

성능 카운터 데이터는 테스트 클라이언트나 웹 서버가 최대 CPU 사용량에 도달한 시간을 확인하는 데 사용됩니다. 웹 응용 프로그램의 성능 병목 상태가 발생한 곳이 서버 CPU가 아닌 경우, 성능 카운터를 통해 병목 현상이 발생하는 위치를 가장 쉽게 확인할 수 있습니다.

모든 테스트에 사용할 수 있는 카운터(다음 목록에서 굵게 표시된 카운터)도 일부 있지만 성능 문제를 발생시키는 불확실한 원인을 찾을 때만 유용한 카운터도 있습니다.

① ACT 클라이언트의 성능 카운터

개체	성능 카운터	표시 내용
Processor	% Processor Time/_Total	테스트 클라이언트의 프로세서 사용 수준입니다.
Memory	Available Bytes	테스트 클라이언트에서 사용할 수 있는 메모리의 양입니다.
Network Interface	Bytes Total/sec	테스트 클라이언트에서 또는 테스트 클라이언트로 이동하는 네트워크 소통량입니다.

② Windows 2000 및 IIS 5용 성능 카운터

다음은 Microsoft Windows 2000, IIS 5 및 Microsoft SQL Server 7.0용 카운터입니다. 버전에 따라 사용하는 카운터가 다를 수 있습니다.

웹 서버의 성능 카운터를 기록하면 웹 응용 프로그램 어떤 부분이 성능 저하를 일으키는지에 대한 정보를 얻을 수 있습니다.

개체	성능 카운터	표시 내용
Active Server Pages	Memory Allocated	현재 Active Server Pages 개체에 할당된 총 메모리 양입니다. 사용하고 있는 ASP 비율을 확인하려면 Memory:Available Byte 및 Memory:Committed Bytes와 이 숫자를 비교하십시오. 테스트하는 동안 비율이 50%보다 크면 서버쪽 개체의 메모리 누수를 나타내는 것입니다.
Active Server Pages	Request Errors/Sec	연결 오류, 컴파일 오류 및 런타임 오류를 비롯한 초 당 오류 수를 나타냅니다. 해당 숫자가 0보다 크면 테스트 스크립트, 서버 구성 또는 ASP 스크립트에 문제가 있는 것입니다.
Active Server Pages	Requests Queued	이 숫자는 0에 가까워야 합니다. 이 숫자가 IIS 대기열 길이를 초과하면 "서버 사용량이 많습니다." 오류가 발생합니다.
Active Server Pages	Requests Rejected	이 숫자가 0 이상이면 테스트의 부하가 너무 높거나 서버 리소스가 충분하지 않습니다.
Active Server Pages	Requests/Sec	초 당 ASP 요청 수를 나타냅니다.
Internet Information Services Global	File Cache Flushes and File Cache Hits	이 카운터를 비교하면 캐시 정리에 대한 적중률을 알 수 있습니다. 플러시는 파일이 캐시에서 제거될 때 발생합니다. 이러한 전역 카운터는 개체가 캐시에서 플러시되고 있는 속도를 표시합니다. 플러시가 너무 느리게 발생하면 메모리가 불필요하게 사용됩니다. ObjectCacheTTL, MemCacheSize 및 MaxCacheFileSize 레지스트리 설정을 조정하면 이 값을 조정할 수 있습니다. 자세한 내용은 Windows 2000 Resource Kit를 참조하십시오.
Internet Information Services Global	File Cache Hits %	이 카운터는 총 캐시 요청에 대한 캐시 적중률을 표시합니다. 정적 페이지가 있는 사이트의 캐시 적중률은 약 80%이어야 합니다.
Memory	Available Bytes	이 숫자는 남아 있는 사용 가능한 실제 메모리의 양을 나타냅니다. 추가로 연결할 때마다 IIS 기본 수준인 2.5MB를 넘는 대략 10KB가 사용됩니다.
Memory	Cache Bytes	정적 파일에 사용된 캐시 크기를 표시합니다. 기본적으로 캐시 바이트는 사용 가능한 메모리의 약 50%로 설정되지만 사용 가능한 메모리가 감소하여 시스템 성능이 저하되면 더 낮게 설정됩니다.
Memory	Page Faults/sec	이 숫자는 페이지 폴트가 CPU에서 처리되는 전체 속도입니다. Page Faults/sec은 소프트 페이지 폴트와 하드 페이지 폴트를 구분하지 않지만 이들을 계산할 수 있습니다. Memory: Pages Input/sec은 하드 페이지 폴트를 해결하기 위해 디스크에서 읽는 페이지 수입니다. 또한 Memory: Page Reads/sec은 하드 페이지 폴트를 해결하기 위해 디스크를 읽은 횟수입니다. 비율로 표시하려면 Page Faults/sec과 이들 값을 비교하십시오. Page Reads/Sec 비율이 5로 지속되면 메모리 부족을 나타내는 것입니다.
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)와 비교하십시오.
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 Non-Anonymous Users	HTTP 서버에 현재 연결되어 있는 인증된 사용자 수입니다.
Web Service	Not Found Errors	반환된 404 응답 코드 수를 표시합니다.

③ 기타 성능 카운터

웹 응용 프로그램이 Microsoft SQL Server를 사용하거나 다른 응용 프로그램을 사용하여 응답을 생성시키는 경우 해당 프로그램의 성능 카운터도 모니터링해야 합니다.

개체	성능 카운터	표시 내용
SQL Server:General Statistics	Logins/sec	초 당 SQL Server에 로그인하는 수입니다.
SQLServer:Cache Manager	Cache Hit Ratio(모든 인스턴스)	캐시에서 데이터를 찾은 적중률을 표시합니다. 지속적으로 숫자가 85% 이하이면 메모리 문제를 나타내는 것입니다.
SQLServer:General Statistics	User Connections	활성 상태의 SQL 사용자 수를 표시합니다. SQL Server에서 작업 중인 스크립트 수를 알려면 이 숫자와 Active Server Pages:Requests/Sec 카운터를 비교하십시오. 차이가 크면 테스트 스크립트가 SQL Server의 유효한 스트레스가 아님을 나타냅니다.
SQL Server:Databases	Transactions/sec	시작된 총 트랙잭션 수 입니다.
SQLServer:Locks	Lock Waits/sec	현재 프로세스가 완료될 때까지 다른 프로세스가 대기하도록 하는 초 당 잠금 요청 수를 표시합니다. 이 숫자가 지속적으로 0보다 크면 트랜잭션 문제를 나타냅니다.