Internet Information Services 5.0

Internet Information Services 의 이해와 성능 분석

Microsoft 고객 기술 지원부

작성자: 최 준 (Microsoft 기술 지원 전문가)

September , 30, 2002

Internet Information Services 5.0 1

유의사항: 본 문서에 포함된 정보는 발행일 당시에 논의된 문제들에 대한 Microsoft Corporation 의 현재 입장을 반영한 것입니다. Microsoft 가 기술의 변화와 고객의 사고 및 네트워크 환경의 변화에 부응하여야 하는 이유로, 본 문서는 Microsoft 의 어떠한 보장으로도 해석되어서는 아니되며, Microsoft 는 발행일 이후에 제공되는 어떠한 정보의 정확성에 대해서도 보증할 수 없습니다. 본 문서는 오로지 지원 및 정보를 제공하기 위한 것입니다. 본 문서의 내용은 명시적, 묵시적, 법적 또는 다른 어떠한 보증도 없이 “있는 그대로” 귀사에게 정보 제공만을 목적으로 제공됩니다. 어떠한 경우에도 본 정보의 사용으로 인하여 야기될 수 있는 간접적, 파생적, 부수적, 특별 또는 징벌적 손해 (이는 영업 이익 손실, 영업 방해, 영업 정보의 손실 또는 기타 금전적인 손해를 포함하나 이에 국한되지 않음)에 대하여 Microsoft 나 그 공급자는 책임을 지지 아니합니다. 어떠한 경우에도 Microsoft 또는 그 공급자의 책임은 총체적으로 귀사의 계약에 따라 귀사가 Microsoft 에 지불한 금액을 초과하지 아니합니다.

Internet Information Services 5.0 2

소개..........................................................................................................4

Internet Information Services 의 이해.........................................5

가용성.......................................................................................................6

IIS 성능분석의 필요성.............................................................................7

웹 서버 성능을 저하 시키는 요인.............................................................8

응용프로그램, 서비스 구성요소............................................................10

IIS 구성의 저장,백업.............................................................................11

IIS 구성사항과 설정 분석......................................................................12

웹 서버 성능 분석...................................................................................14

스트레스 테스트.....................................................................................16

성능카운터 분석.....................................................................................17

메모리 17

프로세서 용량 19

네트워크 용량, 대기 시간 및 대역폭 20

디스크 최적화 21

보안 22

웹 응용 프로그램 모니터링 23

부록 1. HTTP 에러코드........................................................................25

부록 2. ASP 에러코드..........................................................................26

참고자료.................................................................................................30

Microsoft Windows 2000 서버와 Internet Information Services 5.0 의 성능과 가용성 분석을 수행하기 위한 검토 사항을 분석, 정리 하였습니다. 이러한 자료는 직접 성능 데이터와 구성 요소를 확인하기 전에 견고한 시나리오를 구성해서 효율적인 시간 활용과 함께 유용한 분석 결과를 도출하는데 도움이 될 수 있습니다.

Internet Information Services 5.0 3

소개

분석 결과에 따라 웹 서비스의 설정과 구성이 더 나은 서비스를 제공할 수 있도록 변경하는 결과를 얻을 수 있으며, 서비스의 병목 구간과 문제가 예상되는 구성 요소를 찾아내어 가용성을 증가시킬 수 있습니다.

올바른 성능과 가용성 분석을 위해서는 해당 작업을 진행하기 전에 무엇을 모니터링 하고 무엇을 분석할 것인지 분명히 정의해야 합니다. 또한 웹 서버에 서비스 한계치를 결정하고, 서비스의 평균적인 부하를 측정하여 현재 상황과 기대치를 설정해야 합니다. 그러한 수치적인 자료를 바탕으로 실질적인 성능 분석작업을 진행하였을 때 필요한 비교 자료와 구체적인 결과들을 얻을 수 있습니다.

IIS 의 성능을 정확하게 분석하기 위해서는 IIS 가 사용하는 시스템의 자원을 명확하게 이해하고, 웹사이트에 전송한 요청이 처리되기까지의 일련의 과정에 대한 이해가 선행되어야 합니다. 그러한 이해를 바탕으로 성능모니터링에 필요한 카운터를 정하고, 해당 카운터의 수치가 나타내는 성능개체의 상태를 분석해야 합니다.

Microsoft Windows 2000 서버와 IIS 는 다양한 툴을 리소스킷이나 관리도구 등으로 제공하고 있습니다. 성능 분석에 필요한 다양한 툴을 활용하여 시스템과 서비스의 성능 분석을 진행합니다. 또한 툴 이상으로 중요한 것은 시스템과 서비스에 대한 이해와 분석을 위한 경험입니다. 다양한 성능 분석을 돕기 위한 툴은 툴 그 이상은 아닙니다. 따라서 본 문서에서 제시하는 여러 참고자료를 참조하실 것을 권합니다.

웹 서버의 성능 분석에 대해 일반적인 접근과 분석 방법을 제시하게 될 것입니다. 혹 특정한 문제에 직면에 있는 경우에 문제해결 방법과 문제 접근 방법은 본 문서의 내용과 별개의 사항입니다. 그러나 서비스의 장애 등의 문제는 성능 문제와 연관되는 사항이므로 일반적인 IIS 문제의 접근 방법을 다루게 될 것입니다.

IIS 는 기본적으로는 클라이언트의 브라우저에서 요청에 대해 처리하는 기능 이외에도 스크립트와

응용프로그램 활용 등의 다양한 처리를 효과적으로 수행하기 위해서 여러 구성요소를 갖고 있습니다. 기본적으로 웹 서비스(Inetinfo.exe)는 고유 프로세스에서, 기타 응용 프로그램은 풀링된 단일 프로세스

(DLLHost.exe)에서 실행됩니다. 풀에 있는 응용 프로그램 하나가 오류를 일으키면 나머지 응용 프로그램

모두에 영향이 가지만 웹 서버는 계속 실행됩니다. 응용프로그램을 보호하려면 우선 순위가 높은

응용프로그램을 정해 DLLHost.exe 의 다른 인스턴스를 사용하여 격리 프로세스로 실행할 수 있습니다.

Internet Information Services 5.0 4

Internet Information Services의 이해

웹 서비스 프로세스(inetinfo.exe)에서 실행되는 응용 프로그램은 성능 면에서 빠르지만 잘못된 동작으로 인해 웹 서비스를 사용할 수 없게 만들 수 있으므로, 그림에서와 같이 inetinfo.exe 등의 주요 응용 프로그램은 고유 프로세스에서 따로 실행하고 나머지 응용 프로그램은 풀링된 공유 프로세스에서 실행하도록 구성하는 것이 좋습니다. 성능에 미치는 영향을 고려해 격리된 응용 프로그램을 10 개 이상 실행하지 않는 것이 좋습니다.

가용성의 정의는 필요할 때 정상적인 작동 조건에서 서버가 의도하는 기능을 수행할 확률로, 보통 백분율로 나타냅니다. 예를 들어 단일 서버에서 99.9%의 가용성을 확보하려면 서버는 연간 8.76 시간 이내로 작동 중단되어야 합니다. 작동 중단 측면에서 보면 이 수치는 복구 시간이 각각 5 분과 10 분일 때, 작동 중단이 연간 50회(5 분)와 25회(10 분) 이내로 발생해야 함을 의미합니다.

표1 가용성과 작동 중단 시간 비교

서버 가용성(%)

연간 작동 중단 시간

연간 허용되는 최대 작동 중단 횟수(복원 시간이 5 분일 경우)

연간 허용되는 최대 작동 중단 횟수(복원 시간이 10 분일 경우)

99.9% 8.76 시간 50 25

99.95% 4.38 시간 25 12

99.99% 52 분 10 5

99.999% 5 분 1 .5*

참고 자료 :

Windows2000 웹 서버의 가용성을 높이는 방법http://www.microsoft.com/korea/technet/prodtechnol/iis/deploy/rollout/websrvbp.asp

아래 목록에서 기업이 웹 서버의 안정성과 가용성을 향상시키는 데 사용할 수 있는 10 가지 권장 사항을 살펴 보십시오. 가용성 증대를 위해 고려할 사항을 확인할 수 있습니다.

Visual Basic 으로 응용 프로그램을 개발하는 경우 VBCHKW2K 라는 유틸리티를 사용하여 컴파일 설정이 올바른지 확인합니다. KR286036 : VB Check Utility 와 컴파일 설정http://www.microsoft.com/Korea/support/xmlkb/kr286036.asp

사용하는 하드웨어와 소프트웨어가 Windows 2000 과 완전하게 호환되는지 철저히 테스트합니다.

공용 프로세스 ASP 페이지를 가능한 많이 사용합니다.

Internet Information Services 5.0 5

가용성

CGI 보다는 공용 프로세스 COM 구성 요소를 가능한 많이 사용합니다. 웹 용량 분석 도구와 HTTP 모니터를 사용하여 응용 프로그램의 스트레스 테스트를 수행합니다. 웹 서버 구축 계획을 문서화하고 준수합니다. IIS 5 Recycle 도구를 설치하고 사용하여 웹 서버 가용성을 높입니다. 핫픽스 및 보안 업데이트가 출시될 때 이러한 프로그램을 평가하고 우선 순위를 정하는

프로세스를 문서화하고 준수합니다. HFCheck 및 QFECheck 를 사용하여 서버에서 표준 OS 설치 방식을 구현합니다.

서버 가용성 목표를 선택하고 Microsoft 도구를 사용하여 해당 목표의 달성 과정을 확인합니다.

서버의 성능 병목 현상을 찾아 조정할 수 있습니다. 웹 서버를 조정하면 많은 이점이 있습니다. 가령, 서버 대기 시간이 감소되어 사용자의 작업이 향상되며, 현재 보유하고 있는 하드웨어의 사용을 최대화하고, 앞으로의 용량 증가에 대해 적절히 예산을 세울 수 있습니다. 성능과 서버 가용성 간에는 명확한 상관 관계가 있습니다. 예를 들어, 메모리 누수가 제대로 점검되지 못하여 응용 프로그램의 작동이 느려질 수 있으며 이러한 경우 모든 시스템 리소스가 소비되고 서버 작동이 중단될 수 있습니다.

웹 서버에 병목 현상이 있는지 확인하려면 프로세서 사용률, 디스크 I/O, 네트워크 I/O 및 메모리 사용률 등 네 가지 주요 리소스를 면밀하게 모니터링 해야 합니다. 이러한 리소스의 사용률이 장기간 높게 나타나면 리소스를 추가하거나 조정하는 작업이 필요합니다.

또한 구축 프로세스의 전 단계에서 응용 프로그램 및 서버의 성능 모니터링을 수행해야 합니다. 테스팅 환경에서 성능을 모니터링 하여, 구축 단계와 프로덕션 환경에서 시스템에 발생할 수 있는 병목 현상을 정확하게 찾아내야 합니다. 하드웨어나 소프트웨어가 제대로 구성되지 않으면 병목 현상이 발생할 수 있으며 최악의 경우 하드웨어 리소스가 부족해서 로드를 처리할 수 없을 수도 있습니다. Microsoft 는 하드웨어 모니터링에서 웹 응용 프로그램 모니터링에 이르기까지 Windows 서버의 다양한 성능 측면을 측정하는 데 도움이 되는 도구를 제공하고 있습니다. 성능 도구를 사용하여 Windows 2000 서버에 영향을 미칠 수 있는 성능 병목 현상을 찾아내고 이해하는 데 도움을 얻을 수 있을 것입니다. 시작 – 프로그램 – 관리 도구 – 성능을 통해 성능 도구를 실행할 수 있습니다..

IIS Performance Tuning 에 대한 자세한 사항은 이 문서의 [성능 카운터의 분석]절을 참조하십시오.

성능 및 안정성 모니터링

http://www.microsoft.com/korea/technet/iis/prfrelmn.asp

일반적인 서버의 성능 저하 현상은 여러 원인으로 나타나게 됩니다. 최종적으로 원인을 발견하기 전에는 일반적인 성능 저하 원인들에 대해 이해하고 접근을 시작해야 합니다. 원인을 찾아내었다는 경험도 매우 중요한 것이지만 분명하게 구성한 시나리오를 활용하여 시스템을 분석하고, 사전에 예방하는 것 또한 중요한 관리의 요소입니다. 본 문서에서는 시스템의 성능을 저하시키는 요소를 정리하고, 각각의 확인 사항을 기술하였습니다.

1. 과도한 메모리 할당과 해제의 사용

Internet Information Services 5.0 6

IIS 성능분석의 필요성웹 서버 성능을 저하 시키는 요인

특정 응용프로그램이나 프로세스에 의해 불필요하게 자주, 많은 양의 메모리가 할당되고 해제되어 다른 서비스에 영향을 줄 수 있습니다. 이러한 상황은 많은 객체, 메모리 안의 불필요한 배열, 잘못된 캐시 사용 같은 경우를 의미합니다. 이와 같은 상황을 모니터링 하기 위해서 성능모니터에서 아래와 같은 카운터를 사용할 수 있습니다. 각 카운터에 대한 세부 설명은 이 문서의 [성능 카운터 분석]절을 참조하십시오.

Memory : Available BytesMemory : Committed BytesMemory : Page Faults/sec

2. 임의로 생성시키는 쓰레드 문제쓰레드풀(Thread Pool model)을 사용하지 않고 임의로 쓰레드를 생성하여, 특정수 이상의 쓰레드를 생성하게 되면, 쓰레드를 사용함으로써 얻을 수 있는 장점보다는 프로세서가 쓰레드를 관리하는데 어려움을 주게 됩니다. 이러한 경우는 컨텍스트 전환 횟수의 증가를 모니터링 해야 합니다. IIS 는 프로세서당 작업 쓰레드 수를 25 개로 기본 설정되어 있습니다. 성능모니터에서는 아래와 같은 카운터를 사용할 수 있습니다.

Process : Thread Count : dllhostProcess : Thread Count : dllhost#1, #2, …, #NProcess : Thread Count : InetinfoThread : % Processor Time : Inetinfo => Thread #Thread : Context Switches / sec : Inetinfo => Thread #

3. 측정, 분석 하지 않은 자원의 사용기본적으로 Windows 2000 Server 는 Operating System 으로서 필수적인 모니터링 카운터들을 내장하고 있습니다. 그러나 여러 디바이스(프로세서, 네트워크, 저장장치)와 사용자 응용 프로그램 등의 구성요소를 갖고 있는 시스템의 각 요소들도 또한 정형화된 성능 수치를 보유하고 있어야 합니다.

4. 단일클라이언트에서 단일 서버로의 테스트충분히 실제 환경을 고려한 부하테스트를 수행하지 않고, 간단한 환경으로 검증한 응용프로그램은 실제 환경에서 미처 발견하지 못했던 문제를 야기합니다. 따라서 예측되는 부하를 설정하고 스트레스 툴을 활용하여 충분히 검증하고 서비스 해야 합니다. 사전에 예측되는 부하를 설정하기 위해서 성능모니터에서는 다음과 같은 카운터를 사용할 수 있습니다.

Web Service : Get Requests/secWeb Service : Post Requests/secProcessor : % Processor Time(Windows2000 only)Active Server Pages : Requests/sec

5. 실제 사용자 환경을 고려하지 않음부하에 대한 분석과 테스트를 실시할 때 다양한 사용자의 환경과 응용 프로그램 버전, 그리고 시스템 환경 등을 최악의 상황으로 고려하지 않고, 기술적인 순서와 구성으로 짜여진 테스트를 수행하면 안됩니다.

Internet Information Services 5.0 7

6. 공유자원에 대한 잠금 설정(Overprotecting data through the use of global locks can lead to lock contention and low CPU utilization)잠금에 대한 대상은 파일, 데이터베이스, 디스크 등 모든 입출력이 일어나는 자원이 될 수 있습니다. 가벼운 부하에서는 전혀 문제가 되지 않는 사항이지만 심한 부하가 걸릴 경우에는 서비스 상태가 전혀 다른 상황이 전개될 수 있는 부분이 바로 이러한 부분입니다.

성능을 저하시키는 요인에 대한 자세한 사항은 아래의 링크를 참조하십시오.Server Performance Killershttp://msdn.microsoft.com/workshop/server/iis/tencom.asp

각 웹사이트 별로 주로 서비스하는 구성요소와 페이지의 처리 방식이 많이 다릅니다. 기업의 인트라넷 웹사이트의 경우에는 주로 데이터베이스에 액세스하는 Active Server Page 와 리포트를 위한 구성요소로 사용되는 경우가 일반적입니다. 반면 윈도우 미디어 서비스 등을 활용해 다양한 멀티미디어 서비스를 제공하는 사이트도 흔하게 볼 수 있습니다. 따라서 사이트의 응용프로그램 구성 요소들을 분류하고, 접속자들이 가장 선호하는 페이지와 프로그램을 분류하여 시스템 성능 분석 테스트의 시나리오에 반영하는 것이 좋습니다.Visual Basic 등으로 개발한 COM+ 구성요소를 많이 사용하는 경우 각 구성요소는 VBCHKW2k 라는 유틸리티를 사용하여 컴파일 설정을 확인해야 합니다. 또한 이벤트로그 등을 살펴 관련 오류가 발생하고 있지 않은지 확인합니다. Access Violation 등의 오류는 서비스에 치명적인 중지를 일으키기도 합니다.KR286036 : VB Check Utility 와 컴파일 설정http://www.microsoft.com/Korea/support/xmlkb/kr286036.asp

Active Server Page 로 주로 구성되어 Data Access Component 를 활용하는 경우는 Data Access Model 과 Cache 의 활용, 그리고, 예외오류 처리 등을 고려하여 확인합니다. 각각의 구성에 따라 서비스에 지나치게 부하를 주는 요청이 발생하거나, 불필요한 반복적인 요청을 웹 서버로 하여금 자주 실행하게 하는 경우가 발생할 수 있습니다.ASP 의 활용과 최적화에 대한 자세한 사항은 아래의 링크를 참조하십시오.성능과 스타일 향상을 위한 25+ ASP 정보http://www.microsoft.com/korea/msdn/workshop/server/asp/asptips.asp

정적인 페이지로 구성된 웹사이트는 그 성능에 대한 확인과 분석이 비교적 간단합니다. 따라서 동적으로 구성된 페이지 중 정적으로 변환이 가능한 부분이 있는지 확인하고, 정적인 구성으로 동작 가능하도록 유도하는 것이 성능 측면에서 바람직 합니다.성능향상을 위한 동적 페이지의 활용은 아래를 참고하십시오.DHTML 페이지 성능 향상 http://msdn.microsoft.com/workshop/author/dhtml/dude/dude1201.asp

웹서버 이외의 다른 서버의 서비스나 DBMS 등에 연계된 경우에는 해당 네트워크 구간과 다른 서버의

Internet Information Services 5.0 8

응용프로그램, 서비스 구성요소

응답이 중요한 변수가 될 수 있습니다. 이러한 경우는 네트워크에 대한 모니터링과 IIS 의 처리요청대기 시간 등을 고려하여 분석하게 됩니다. 또한 외부 오류가 발생했을 경우에 필요한 확인 방법과 대안을 준비하여야 합니다. 각각의 ASP / COM+ 구성요소들의 요청은 모두 브라우저의 요청에 대해 IIS 에 의해서 로그로 남게 됩니다. IIS 의 로그를 통해서 요청한 브라우저의 정보와 요청페이지, 페이지에서 리턴한 상태 코드를 참조할 수 있습니다.미디어 서비스를 주로 활용하는 경우에는 가장 중요한 요소로 네트워크와 디스크의 입출력 대기여부 입니다. Windows Media Technologies 를 활용하는 경우는 이 문서에서 언급하지 않은 별도의 성능 분석 카운터를 활용해야 합니다.

Windows Media Technologies 에 대한 정보http://www.microsoft.com/korea/technet/win2000/wmtbest.asp

IIS 의 설정 변경과 성능의 조정을 시작하기 전에 IIS 의 구성을 저장하는 것이 바람직합니다. IIS 의 구성은 메타베이스에 저장됩니다.

메타베이스란 IIS 구성 설정을 저장하기 위한 구조를 말합니다. 메타베이스는 Windows 시스템 레지스트리와 동일한 기능을 수행하기도 하지만 Internet Information Server 버전 4.0 에만 한정된다는 차이점을 가지고 있습니다. IIS5 는 더 정밀하고 유연하게 제어할 수 있도록 새로운 키와 값이 추가되었습니다.

시스템을 IIS 3.0 이전에서 IIS 4.0 으로 업그레이드하면 레지스트리에 설정되었던 구성 매개 변수가 메타베이스로 마이그레이션 됩니다. IIS 를 시작하면 메타베이스가 메모리로 로드 되어 IIS 를 종료할 때까지 사용할 수 있습니다. 기본적으로 메타베이스는 IIS 가 설치되어 있는 Inetsrv 폴더에 Metabase.bin 이라는 특수 파일 형식으로 저장됩니다.

백업을 위해서는 인터넷서비스 관리자에서 [구성 백업/복원]을 실행하면 됩니다. 기본적으로 “c:\winnt\system32\inetsrv\metaback”에 저장됩니다.

KR302573 - HOWTO: IIS 백업 및 복원http://www.microsoft.com/korea/support/xmlkb/kr302573.asp

메타베이스 손상에 대한 복원방법KR300672 - HOWTO: IIS 5 를 사용하여 메타베이스 백업 만들기http://www.microsoft.com/Korea/support/xmlkb/KR300672. asp  IIS 카운터 컬렉션 DLL 은 IIS 메타베이스를 사용합니다. 카운터를 보는 동안, IIS 메타베이스를 관리하는 IIS Admin service 는 종료 되지 않을 것입니다. 심지어 WWW 와 FTP 서비스가 종료되지만, LOCK 이 발생한 것으로 나타날 수 있습니다. 이벤트에서는 성능 모니터가 동작하는 동안 IIS Admin service 는 멈춘 것으로 나오고 IIS Admin service 나 Event Viewer 는 LOCK 이 발생한 것으로 나타납니다. 따라서 원격에서 성능 모니터를 실행하는 동안 IIS 서버가 (비정상) 종료하는 경우 메타베이스 손상을 야기할 수 있습니다. 항상 성능모니터를 종료하고 IIS Admin service 를 정지해야 합니다.

웹 사이트에서 로깅 기능 설정

Internet Information Services 5.0 9

IIS 구성의 저장,백업IIS 구성사항과 설정 분석

IIS 는 Windows 2000 의 이벤트 로깅 또는 성능 모니터링 기능의 범위를 확장합니다. 로그에는 사이트 방문자, 방문자의 검색 내용, 정보가 마지막으로 검색된 시간 등의 정보가 포함됩니다. 또한 성공 여부에 관계 없이 웹 사이트, 가상 폴더 또는 파일에 대한 액세스 시도를 분석할 수 있습니다. 여기에는 파일 읽기 및 쓰기 등의 이벤트가 포함됩니다. 사이트, 가상 폴더 또는 파일에 대하여 감사할 이벤트를 선택할 수 있습니다. 이들 파일을 주기적으로 검토하여 공격에 노출되어 있거나 기타 보안 문제가 있는 서버 또는 사이트 영역을 감지할 수 있습니다. 각 웹 사이트에 대한 로깅 기능을 설정하고 로그 형식을 선택할 수 있습니다. 로깅 기능이 설정되어 있으면 사이트의 모든 폴더에 대해 적용되지만 특정 디렉터리에 대해서는 로깅 기능을 해제할 수 있습니다. 설정 세부 항목은 아래의 링크를 참조하십시오.

IIS 의 사이트 로깅 기능을 설정http://support.microsoft.com/default.aspx?scid=kb;ko;KR30039 0

IIS 5.0 에 대한 세션 상태 설정

응용 프로그램 옵션 탭을 누르고 세션 정보 사용을 선택/취소합니다. 적용을 누른 다음 확인을 차례로 두 번 눌러 설정을 저장합니다. 세션 상태가 설정 해제되면 ASP 간에 Global.asa 또는 pass 변수를 사용할 수 없습니다. 자세한 설정 사항은 아래의 링크를 참조하십시오.

HOWTO: IIS 5.0 에 대한 세션 상태 설정 해제http://support.microsoft.com/default.aspx?scid=kb;ko;KR29987 8

IIS 5.0 실행에 필요한 NTFS 권한

IUSR_ComputerName 및 IWAM_ComputerName 계정의 사용자 이름과 암호는 다음 세 위치에 저장되어 있습니다.

Internet Information Server(IIS) 메타베이스 도메인 사용자 관리자(Windows NT) 또는 로컬 사용자 및 그룹(Windows 2000) Microsoft Transaction Server(Windows NT) 또는 구성 요소 서비스(Windows 2000)

각 시스템 관리자의 필요에 맞게 사용 권한을 특수화할 수도 있지만 IUSR_MACHINE 계정 대신 Everyone 그룹을 사용하는 것이 좋습니다. Everyone 그룹은 사용자 그룹, IUSR_MACHINE 계정 및 IWAM_MACHINE 계정을 포함합니다.

IIS 5.0 에서는 웹 페이지를 실행하는 데 별도의 두 가지 계정을 사용합니다. 익명 인증을 사용할 경우 IIS 는 IUSR_MACHINE 계정을 사용하여 해당 페이지를 봅니다. 그러나, Dllhost.exe 라는 별도의 프로세스를 시작할 때는 IWAM_MACHINE 을 사용합니다. 모든 ASP(Active Server Page), 구성 요소 개체 모델(COM) 구성 요소 또는 기타 ISAPI 확장(ASP 는 ISAPI 확장으로 간주됨)이 Dllhost.exe 프로세스 내부에서 실행됩니다. 이것은 주로 안정성을 위한 것입니다. ASP 페이지에서 호출된 사용자 지정 COM 구성 요소가 동작하지 않아도 즉, 액세스 위반으로 인해 프로세스가 중단되어도 Inetinfo.exe 가 영향을 받지 않아 웹 서비스가 계속 실행됩니다.

IIS 5.0 의 세 가지 보호 수준은 아래와 같습니다.

Internet Information Services 5.0 10

낮음(IIS 프로세스): 이 설정은 IIS 4.0 의 기본 설정과 유사합니다. 모든 웹 페이지가 HTM인지 아니면 ASP 인지에 관계 없이 Inetinfo.exe 프로세스 내부에서 실행됩니다.

보통(풀링됨): 이것이 기본값입니다. IIS 4.0 에서처럼 이 설정은 모든 ASP 및 COM 구성 요소가 실행되는 Dllhost.exe 라는 별도의 프로세스를 시작합니다. 이 프로세스는 IIS 4.0에서처럼 IWAM_MACHINE 계정에 의해 시작됩니다. 또한, 이 설정은 IIS 에서 실행하는 모든 웹 사이트가 ASP 페이지를 실행하는 데 이 단일 Dllhost.exe 를 공유하므로 ‘풀링됨’ 이라고도 합니다. Windows 2000 에서는 Mtx.exe 가 Dllhost.exe 로 대체됩니다.

높음(격리됨): 이 설정은 각 웹 사이트나 응용 프로그램에 대해 전용 Dllhost.exe 프로세스를 시작합니다. 5 개의 웹 사이트가 있고 각각 높은 수준의 보호로 설정되어 있으면 총 6 개의 Dllhost.exe 프로세스 즉, 5 개의 Dllhost.exe 프로세스 외에 시스템 응용 프로그램 아래에서 COM+가 시작하는 추가 Dllhost.exe 프로세스 하나가 더 시작됩니다.

IIS 계정 정보의 확인과 재구성에 대한 정보는 아래의 링크를 참조하십시오.http://support.microsoft.com/default.aspx?scid=kb;ko;KR29798 9

웹서버의 성능을 분석하기 위해서 일반적으로 성능모니터를 사용합니다. 성능 모니터는 설정한 시간간격으로 모니터링을 원하는 개체의 카운터를 로깅 합니다. 대표적인 카운터 중 하나인

Internet Information Services 5.0 11

웹 서버 성능 분석

프로세서와 메모리 등의 사용률을 저장할 수 있으며 웹서비스와 ASP 그리고, 디스크, 프로세스, 쓰레드 등의 카운터를 로깅하게 됩니다.실행방법은 [프로그램]-[관리도구]-[성능]을 실행합니다.

표2 웹서비스 성능 분석을 위한 카운터

Object CounterMemory Available bytes　 Committed bytes　 Page faults/sec　 Pages input/sec　 Page reads/sec　 Cache Bytes　 Pool Paged Bytes　 Pool Nonpaged Bytes　 Pages/secInternet Information Service Global File Cache Hits %　 File Cache Hits　 File Cache FlushesProcess Private Bytes (inetinfo, dllhost)　 Virtual Bytes (inetinfo, dllhost)　 Pool Paged Bytes : Inetinfo　 Pool Nonpaged Bytes : Inetinfo　 Pool Paged Bytes : dllhost#N　 Pool Nonpaged Bytes : dllhost　 %Processor Time (inetinfo, dllhost)　 Thread Count : inetinfoPaging File % UsageSystem Processor Queue Length　 Context Switches/secProcessor %Processor Time　 Interrupts/sec　 %DPC Time

ThreadContext Switches/sec : Dllhost#N : Thread#

　 Context Switches/sec : Inetinfo　 %Processor Time: Inetinfo=>Thread#　 %Processor Time: Dllhost=>Thread#Network Interface Bytes Total/secWeb Service Maximum Connections　 Total Connection Attempts　 CGI Requests/sec　 ISAPI Extension Requests/sec　 Get Requests/sec　 Post Requests/sec　 Bytes Total/sec　 Current Anonymous Users

Internet Information Services 5.0 12

　 Current Non-Anonymous Users　 Current Connections　 Not Found Errors/secPhysical Disk %Disk Time　 Avg. Disk Queue LengthActive Server Pages Requests/sec　 Requests Executing　 Request Wait Time　 Request Execution Time　 Requests Queued　 Errors/sec　 Requests RejectedObject ThreadsServer Bytes Total/sec

[표 2]의 카운터를 수집하기 위해 카운터로그를 추가 설정하고 저장한 후 필요한 웹 서버에서 모니터링을 시작합니다. 필요에 따라 특정 카운터를 추가할 수 있으며, 상기 카운터는 일반적인 분석을 위한 최소한의 카운터입니다. 각 카운터의 의미는 이후 절의 내용에서 확인할 필요가 있습니다. 또한 카운터의 의미와 함께 각 저장값 수치에 대한 과도한 부하를 판단하는 기준도 중요합니다. 그러한 기준에 따라서 병목이 발생하는 구간을 확인합니다. 즉 특정 개체의 대기열 카운터가 증가하면 해당 개체를 병목이 발생하는 부분으로 검토하게 됩니다.

성능로그의 다른 결과는 시스템의 최대 부하가 걸리는 시간과 해당 시간대의 시스템 상태입니다. 그러한 시간대를 확인하기 위해서 충분히 긴 시간의 성능로그를 수집할 필요가 있습니다. 따라서 성능을 조정하기 전에 필요한 시스템 성능 평균치와 임계치를 확인할 수 있습니다.카운터 로그 수집 방법은 아래를 참조하십시오.KR302509: 시스템 모니터 카운터 로그 작성 및 구성http://www.microsoft.com/Korea/support/xmlkb/KR302509.ASP스트레스 테스트는 스트레스 테스트 툴을 사용하여 부하를 줄 시간, 특정 페이지, 그리고 동시 사용자수 등을 설정하고 시스템에 부하를 주는 테스트 입니다.

상기 테스트를 진행하기 위하여 WAS(Web Application Stress) 툴을 사용하게 됩니다. 테스트를 위하여 설정할 수 있는 값들은 아래와 같습니다.

동시 사용자 수 클라이언트의 요청에 대한 유형, 크기. 요청할 페이지 요청 간격

위와 같은 설정값들을 지정한 후 스트레스 테스트를 완료하면 아래와 같은 사항들이 보고서로 작성됩니다.

클라이언트에서의 요청수 페이지당 요청수

Internet Information Services 5.0 13

스트레스 테스트

소켓에러 발생수 초당 요청수 테스트 진행중 모니터링 하도록 지정한 성능카운터 페이지의 각 아이템에 해당하는 TTFB(Time to first byte), TTLB(Time to last byte).

이러한 결과를 유용하게 활용하기 위해서는 스트레스를 주기 위한 시나리오가 적절하게 구성되어야 합니다. WAS 툴은 사용자가 브라우저에서 요청하는 페이지들을 순서대로 로깅 할 수 있습니다. 그리고, 실제 테스트 시에 로깅한 페이지를 순서대로 요청하여 스트레스를 가하게 됩니다.

페이지에 대한 정상처리 여부와 에러코드를 보고서에 포함하는 기능이 있으므로 부하를 많이 주거나 문제가 있는 페이지를 집중적으로 요청하는 것도 테스트 방법이 될 수 있습니다.

웹서버의 서비스를 분류하여 구성요소와 제공하는 응용프로그램에 따라 요구되는 시스템 자원의 활용을 모니터링 하여 웹 서비스 성능을 분석하게 됩니다. 성능의 분석을 위한 도구로 성능 모니터와 스트레스 툴을 사용하며 그 결과로 서비스의 병목 구간이나 성능수치를 확인합니다.

응용프로그램 구성과 사이트의 구성요소 설계/설정에 따라 시스템 장애가 발생할 수 있으며 이러한 장애는 이벤트로그, IIS 로그, 브라우저의 에러코드 등으로 확인할 수 있습니다. 따라서 가용성을 저하시키는 장애의 원인을 분석하거나 예방하여 가용성을 목표치에 가깝게 증가시킵니다.

스트레스 툴 다운로드 페이지 : http://homer.rte.microsoft.com/

스트레스 테스트에 대한 자세한 사항은 아래의 링크를 참조합니다.http://webtool.rte.microsoft.com/tutor/default.htm

메모리

메모리 성능데이터의 분석은 IIS 성능뿐 아니라 시스템 전반적인 문제를 접근하는 일반적인 데이터로 활용될 수 있습니다. 하지만 가상 메모리를 Virtual Memory Manager 가 캐시메모리는 Cache Memory Manager 가 조정합니다. 따라서 성능분석 데이터는 현재 메모리가 충분한지 판단하고, 사용 상태를 보는 것이 중요합니다. 메모리 부족으로 문제가 발생했는데 시스템의 다른 부분에 문제가 발생한 것처럼 표시되는 경우가 있습니다. 먼저 서버에 메모리가 충분한지 분석한 다음 다른 구성 요소를 확인해야 합니다. Windows 2000 및 IIS 5.0 을 실행할 경우 전용 웹 서버에 필요한 최소 RAM 크기는 128MB 지만 256MB 에서 1GB 정도는 있어야 불편 없이 사용할 수 있습니다. 기본적으로 IIS 파일 캐시가 사용 가능한 메모리의 절반까지 사용하도록 설정되기 때문에 메모리가 많을수록 IIS 파일 캐시가 커집니다. (Windows 2000 Advanced Server 는 RAM 크기를 8GB 까지 지원하지만 IIS 파일 캐시는 4GB 이하의 메모리만 사용합니다.)

메모리와 관련된 성능 병목이 있는지 확인하려면 다음 카운터를 수집하십시오. Memory: Available Bytes, Memory: Committed Bytes. 사용 가능한 최대

메모리 크기의 10%는 여유 메모리로 남겨 두십시오. IIS 5.0 은 기본적으로 파일 캐시에

Internet Information Services 5.0 14

성능카운터 분석

사용할 수 있는 메모리를 50%까지 사용합니다. Committed Bytes 는 실제 운영 가능한 가상메모리의 양을 말합니다. 총 물리적 메모리의 75%가 넘지 않도록 합니다.

Memory: Page Faults/sec, Memory: Pages Input/sec 및 Memory: Page Reads/sec. 프로세스가 메모리의 페이지를 요청하는데 시스템이 요청한 위치에서 해당 페이지를 찾을 수 없으면 페이지 부재가 발생합니다. 요청한 페이지가 메모리의 다른 위치에 있을 경우 소프트 페이지 부재 오류라고 합니다. 디스크에서 페이지를 검색해야 할 경우는 하드 페이지 부재 오류라고 합니다. 대부분의 프로세서가 큰 영향 없이 많은 수의 소프트 페이지 부재를 처리할 수 있습니다. 그러나 하드 페이지 부재를 처리하려면 심각한 지연이 발생할 수 있습니다. 초당 페이지 부재는 프로세서가 하드 및 소프트 페이지 부재를 포함하여 전체 부재 페이지를 처리하는 속도입니다. 초당 페이지 입력은 하드 페이지 부재를 해결하기 위해 디스크에서 읽는 총 페이지 수입니다. 초당 페이지 읽기는 하드 페이지 부재를 해결하기 위해 디스크를 읽는 횟수입니다. 초당 페이지 입력은 초당 페이지 읽기보다 크거나 같고, 이 값으로 하드 페이지 부재율을 알 수 있습니다. 이 값이 작으면 서버가 요청에 빠르게 응답하는 것입니다. 이 값이 크면 캐시에 너무 많은 메모리를 사용해서 시스템의 나머지 구성 요소에서 사용할 메모리가 부족하기 때문입니다. 서버의 RAM 을 늘려야 할 수도 있지만 캐시 크기를 줄여 효율을 높일 수도 있습니다.

Memory: Cache Bytes, Internet Information Services Global: File Cache Hits %, Internet Information Services Global: File Cache Flushes 및 Internet Information Services Global: File Cache Hits, Process: Private Bytes(Inetinfo,dllhost). 첫째 카운터, Memory: Cache Bytes는 사용 가능한 실제 메모리의 50%까지 사용하도록 기본 설정된 파일 시스템 캐시의 크기를 나타냅니다. 메모리가 부족할 경우 IIS 가 자동으로 캐시를 조정하므로 이 카운터가 어느 쪽으로 변하는지 계속 확인해야 합니다. 둘째 카운터는 전체 캐시 요청에 대한 캐시 적중률로 IIS 파일 캐시에 대한 설정이 제대로 작동하는지를 나타냅니다. 주로 정적 파일로 구성된 사이트의 경우 캐시 적중률이 80% 이상이면 양호한 상태입니다. 원하는 속도로 캐시에서 개체를 플러시 하는지 확인하려면 3,4번째 카운터, IIS Global: File Cache Flushes (IIS 가 캐시의 파일 제거 속도), IIS Global: File Cache Hits 에 대한 로그를 비교하십시오. 플러시 속도가 너무 빠르면 필요 이상으로 자주 캐시에서 개체가 플러시될 수 있습니다. 또 플러시 속도가 너무 느리면 메모리를 제대로 활용하지 못할 수 있습니다.(ObjectCacheTTL값 조정). Private Bytes 는 다른 프로세스와 공유할 수 없는 메모리 양으로 메모리의 누수확인이 가능합니다. 격리수준의 설정에 따라 Inetinfo 나 dllhost 를 모니터링 합니다. IIS는 메모리가 부족할 때 자동으로 캐시의 데이터를 지우므로, 메모리 부족은 Cache Bytes 감소여부 확인으로도 가능합니다.

Paging File Bytes: Total. 이 카운터는 시스템의 페이징 파일 크기를 나타냅니다. 페이징 파일이 클수록 시스템이 많은 메모리를 페이징 파일에 커밋합니다. Windows 2000 은 시스템 드라이브에 페이징 파일을 만들지만 사용자가 각 논리 디스크에 페이징 파일을 만들고 기존 파일의 크기를 변경할 수 있습니다. 실제로 하나의 페이징 파일을 여러 개의 실제 드라이브에 분리해 놓으면 페이징 파일 성능이 향상됩니다. 사이트의 컨텐트나 로그 파일이 포함되지 않은 드라이브를 사용하십시오. 시스템 드라이브의 페이징 파일 크기가 실제 메모리 크기의 두 배 이상이 되어야 시스템이 중단될 경우에 RAM 의 내용을 모두 디스크에 쓸 수 있습니다.

Internet Information Services 5.0 15

Memory: Pool Paged Bytes, Memory: Pool Nonpaged Bytes, Process: Pool Paged Bytes: Inetinfo, Process: Pool Nonpaged Bytes: Inetinfo, Process: Pool Paged Bytes: dllhost#n 및 Process: Pool Nonpaged Bytes: dllhost. Memory: Pool Paged Bytes 및 Memory: Pool Nonpaged Bytes 는 서버의 모든 프로세스에 사용되는 풀 공간을 모니터링 합니다. 위에 있는 나머지 카운터는 서버에서 인스턴스화 되어 Inetinfo 프로세스(IIS 를 실행하는) 또는 Dllhost 프로세스(격리되거나 풀된 응용 프로그램을 실행하는)에 의해 IIS 5.0 에 직접 사용되는 풀 공간을 모니터링합니다. 서버의 모든 Dllhost 인스턴스에 대한 카운터를 모니터링 해야 합니다. 모든 카운터를 모니터링 하지 않으면 IIS 에 사용되는 풀 공간을 정확하게 알 수 없습니다. 시스템의 메모리 풀에는 응용 프로그램과 운영 체제가 만들어 사용하는 개체가 보관됩니다. 메모리 풀의 내용은 권한 모드로만 액세스할 수 있습니다. 즉, 운영 체제의 커널만이 직접 메모리 풀을 사용할 수 있고 사용자 프로세스는 사용할 수 없습니다. IIS 5.0 을 실행하는 서버에서는 연결 서비스를 제공하는 쓰레드가 서비스에 사용되는 다른 개체(예: 파일 핸들 및 소켓)와 함께 비페이지 풀에 저장됩니다. 페이징된 풀의 총 크기가 시스템의 물리적 크기에 접근하면, 메모리를 추가 해야할 필요가 있습니다. 또한 페이징 되지 않은 풀의 크기가 가상 메모리 크기에 접근하면 가상 메모리 크기를 증가 시킵니다.

Internet Information Services 5.0 16

프로세서 용량

사용자는 웹 사이트의 빠른 응답을 원하고 동적으로 생성되는 요청의 양이 증가하고 있으므로 빠르고 효율적인 프로세서를 사용하는 것이 중요합니다. 하나 이상의 프로세스가 프로세서 시간의 대부분을 사용할 경우에 병목이 발생합니다. 그러면 실행 준비된 프로세스 쓰레드가 프로세서를 사용할 수 있을 때까지 대기열에서 대기합니다.

Windows 2000 Server 에서 실행하는 IIS 5.0 은 프로세서를 2 개부터 4 개까지 효율적으로 확장합니다. 프로세서를 추가하려는 경우에는 웹 사이트에 필요한 비즈니스 요구사항을 고려하십시오. 예를 들어, 주로 정적 컨텐트를 호스트하는 서버의 경우 프로세서 2 개면 충분합니다. 동적으로 생성되는 컨텐트를 호스트하는 경우에는 프로세서를 4 개 설치해야 문제를 해결하는 경우도 있습니다. 그러나 사이트의 작업 부하가 CPU 에 집중되면 한 대의 컴퓨터로 요청을 모두 처리할 수 없습니다. 이 경우에는 사이트를 여러 서버로 확장해야 합니다.

그러나 Windows 2000 및 IIS 5.0 에서 성능을 최대로 향상시키려면 먼저 메모리 문제를 해결해야 합니다. 웹 서버의 프로세서 수를 변경하는 결정을 내리기 전에 메모리 문제를 제외하고 다음 성능 카운터를 모니터링 하십시오.

System: Processor Queue Length. 이 카운터에는 시스템의 모든 프로세서가 공유하는 대기열에서 실행을 위해 대기하는 쓰레드 수가 표시됩니다. 이 카운터에 두 개 이상의 쓰레드 값이 계속 유지되면 프로세서 병목을 고려해야 합니다. 웹서버의 경우 10 개 이하를 유지하는 것이 좋습니다.

Processor: %Processor Time. 프로세서 병목은 Processor: % Processor Time 값은 크고 네트워크 어댑터와 디스크 I/O 는 용량보다 작게 유지되는 상태를 나타냅니다. 복수 프로세서 컴퓨터에서는 Processor: % Processor Time 카운터를 검사하여 불균형 상태를 확인할 수 있습니다. 70% 이하의 사용률을 유지하도록 해야 합니다.

Thread: Context Switch/sec:Dllhost#N=>Thread#, Thread: Context Switches/sec:Inetinfo=>Thread# 및 System: Context Switches/sec. 쓰레드 풀의 크기를 증가시키려면 이 세 가지 카운터를 모니터링 해야 합니다. 쓰레드 수를 증가시키다 보면 성능이 더 높아지지 않고 다시 떨어지는 지점까지 컨텍스트 전환 횟수가 증가할 수 있습니다. 각 요청에 대한 컨텍스트 전환 횟수가 10 이상이면 높은 것이므로 쓰레드 풀의 크기를 줄이십시오. 연결과 요청에 의해 측정된 전체 성능을 기준으로 쓰레드의 균형을 조정하기가 어려울 수도 있습니다. 쓰레드를 조정한 후에는 항상 전체 성능 모니터링을 통해 성능이 높아졌는지 아니면 낮아졌는지 확인하십시오. 쓰레드 수를 조정해야 하는지 판단하려면 프로세스의 쓰레드 수와 각 쓰레드에 대한 프로세서 시간을 전체 프로세서 시간과 비교하십시오. 쓰레드가 항상 실행되고 있지만 프로세서 시간을 완전히 사용하지 않을 경우에는 추가 쓰레드를 만들어 성능을 향상시킬 수 있습니다. 그러나 모든 쓰레드가 실행되고 프로세서가 최대 용량에 근접하면 쓰레드 수를 늘리는 것보다 다른 서버를 추가하여 부하를 분산시키는 것이 좋습니다. AspThreadGateEnabled 및 AspProcessorThreadMax 메타베이스 설정의 변경을 고려할 수 있습니다.

Internet Information Services 5.0 17

Processor: Interrupts/sec 및 Processor: % DPC Time. 이 카운터를 사용하면 프로세서가 인터럽트 및 DPC(지연 프로시저 호출)에 사용하는 시간을 확인할 수 있습니다. 이 두 요소가 프로세서에 부하를 가중시키는 원인이 될 수 있습니다. 클라이언트 요청은 각각의 두 요소를 발생시키는 주 원인이 될 수 있습니다. 새로 나온 일부 네트워크 어댑터 카드에는 인터럽트 수준이 너무 높을 경우에 인터럽트를 버퍼에 모아 인터럽트를 완화시키는 기능이 있습니다.

네트워크 용량, 대기 시간 및 대역폭

네트워크는 클라이언트가 서버로 요청을 보내는 회선입니다. 서버로 요청을 보낸 다음 응답을 받을 때가지 걸리는 시간이 사용자가 가장 크게 느끼는 서버 성능 제한 요소 중 하나입니다. 이 요청/응답 주기를 대기 시간이라고 하는데, 대기 시간은 대부분 웹 서버 관리자가 제어할 수 없습니다. 예를 들어, 인터넷 상의 느린 라우터 또는 클라이언트와 서버 사이의 물리적 거리는 관리자가 해결할 수 없습니다.

주로 정적 컨텐트로 구성된 사이트에서는 네트워크 병목이 성능 병목의 가장 큰 원인입니다. 아주 작은 서버가 T3 연결(45mbps)이나 100mbps 고속 이더넷 연결을 완전히 포화시킬 수도 있습니다. 네트워크 연결을 조정하고 효과적인 대역폭을 최대로 활용하면 이러한 문제를 조금 줄일 수 있습니다.

효과적인 대역폭을 판단하는 가장 간단한 방법은 서버가 데이터를 보내고 받는 속도를 확인하는 것입니다. 서버의 여러 구성 요소에서 여러 가지 성능 카운터를 사용하여 데이터 전송을 측정할 수 있습니다. 사용할 수 있는 카운터는 웹, FTP 및 SMTP 서비스, TCP 개체, IP 개체, 네트워크 인터페이스 개체 등입니다. 각 카운터는 서로 다른 OSI(개방형 시스템 상호 연결) 계층을 측정합니다.

Network Interface: Bytes Total/sec. 네트워크 연결에서 병목이 발생하는지 확인하려면 Network Interface: Bytes Total/sec 카운터를 네트워크 인터페이스 카드의 총 대역폭과 비교하십시오. 급격히 증가하는 트래픽에 대비하려면 용량의 50% 이하를 사용해야 합니다. 이 값이 연결 용량에 거의 근접하고 프로세서와 메모리 사용량에 문제가 없으면 연결에서 문제가 발생한 것입니다.

Web Service: Maximum Connections 및 Web Service: Total Connection Attempts. 네트워크 연결을 사용하는 컴퓨터에서 다른 서비스를 실행할 경우 Web Service: Maximum Connections 및 Web Service: Total Connection Attempts 를 모니터링하여 웹 서버에 필요한 만큼의 연결을 사용할 수 있는지 확인해야 합니다. 이 값을 메모리 및 프로세서 사용률 값과 비교하면 다른 구성 요소에 문제가 있는 것이 아니고 연결에 문제가 있다는 것을 확인할 수 있습니다.

디스크 최적화

IIS 5.0 은 디스크에 로그를 쓰기 때문에 클라이언트 캐시 적중률이 100%일 경우에도 주기적으로 디스크 작업을 합니다. 로깅 작업보다 디스크 읽기 작업이 많으면 시스템의 다른 영역을 조정해야

Internet Information Services 5.0 18

합니다. 예를 들어, 하드 페이지 부재가 발생하면 많은 양의 디스크 작업이 수행되지만 RAM 은 부족하다는 것을 나타냅니다.

메모리 액세스가 디스크 검색보다 백만 배 정도 빠르기 때문에 요청에 응답하기 위해 하드 디스크를 검색하면 성능이 떨어지는 것이 당연합니다. 호스트 하는 사이트 종류가 디스크 검색 빈도에 큰 영향을 미칠 수 있습니다. 사이트에 불규칙적으로 액세스 되는 큰 파일이 있거나, 사이트에 있는 파일이 점점 커지거나, RAM 크기가 아주 작은 경우에는 IIS 가 빠른 액세스를 위해 파일 사본을 RAM 에 유지할 수 없습니다.

일반적으로 서버에 요청이 많을 경우에 디스크 읽기 횟수가 급격히 증가하는 것을 보려면 물리적 디스크 카운터를 사용합니다. RAM 이 충분할 경우에는 동일한 서버에 데이터베이스가 저장되어 있거나 클라이언트가 다른 쿼리를 만들지만 않으면 대부분의 연결에서 캐시 적중 결과를 얻을 수 있습니다. 이 경우에는 캐싱이 수행되지 않습니다. 로깅도 디스크 병목의 원인이 될 수 있습니다. 서버의 디스크에 부하를 주는 문제가 없는데도 많은 양의 디스크 작업이 수행되면 즉시 서버의 RAM 크기를 검사하여 메모리가 충분한지 확인해야 합니다.

디스크 액세스 빈도를 확인하려면 다음 카운터를 로깅 하십시오. Processor: % Processor Time, Network Interface Connection: Bytes

Total/sec 및 PhysicalDisk: % Disk Time. 세 카운터의 값이 모두 높으면 하드 디스크 때문에 사이트에 병목이 발생하는 것이 아닙니다. 그러나 PhysicalDisk: % Disk Time 은 높고 Processor: % Processor Time 및 Network Interface Connection: Bytes Total/sec 에는 여유가 있으면 하드 디스크 때문에 병목이 발생하는 것입니다. 서버에서 실제 디스크 성능 카운터를 실행하지 않을 경우 명령줄을 열고 diskperf -yd 명령을 사용하십시오.

Internet Information Services 5.0 19

보안

웹 응용 프로그램의 보안 문제와 성능 사이의 균형을 조정하는 것은 중요한 문제 중 하나입니다. 보안 웹 통신을 하려면 보안을 하지 않는 웹 통신보다 많은 리소스가 필요하기 때문에 어떤 경우에 SSL 프로토콜이나 IP 주소 확인과 같은 다양한 보안 기술을 사용해야 하는지 그리고 어떤 경우에 보안 기술을 사용하지 않아도 되는지 알아야 합니다. 예를 들어, 홈 페이지나 검색 결과 페이지는 SSL 을 통해 실행할 필요가 없습니다.

SSL 을 사용할 경우 첫 번째 연결을 구성하는 비용이 SSL 세션 캐시의 보안 정보를 사용해서 다시 연결하는 비용보다 5배 정도 많이 듭니다. SSL 세션 캐시에 대한 시간 초과 기본값이 Windows NT 4.0 에서는 2 분이었는데 Windows 2000 에서는 5 분으로 변경되었습니다. 이 데이터가 플러시되고 나면 클라이언트와 서버가 완전히 새로운 연결을 구성해야 합니다. 긴 SSL 세션을 지원할 계획이면 ServerCacheTime 레지스트리 설정을 사용해 시간 초과 설정을 늘릴 수 있습니다. 수천 명의 사용자가 SSL 을 사용하여 사이트에 연결할 것으로 예상될 경우 SSL 세션의 지속 시간을 예측한 다음 ServerCacheTime 매개 변수를 예측한 값보다 조금 길게 설정하면 안전합니다. 시간 초과를 이 값보다 훨씬 길게 설정하면 서버 캐시에 오래된 데이터가 남아 있을 수 있습니다. 또 HTTP 연결 유지 기능도 사용하십시오. HTTP 연결 유지 기능을 사용하면 브라우저에서 연결을 종료할 때까지 SSL 세션이 만료되지 않습니다.

Windows 2000 및 IIS 5.0 보안 서비스는 성능 비용이 드는 보안 기술 외에도 많은 운영 체제 서비스에 통합됩니다. 따라서 각 서비스와 분리하여 보안 기능을 모니터링 할 수 없습니다. 대신 일반적인 방법으로 보안 기능을 사용하는 경우와 사용하지 않는 경우에 테스트한 서버 성능을 비교하여 보안 오버헤드를 측정할 수 있습니다. 이 테스트를 수행할 때는 작업 부하와 서버 구성을 고정하여 보안 기능을 유일한 변수로 만들어야 합니다. 다음과 같은 항목을 측정하여 테스트할 수 있습니다.

프로세서 작업 및 프로세서 대기열: 인증, IP 주소 확인, SSL 프로토콜, 암호화 구성 등은 상당한 작업이 필요한 보안 기능입니다. 권한 모드와 사용자 모드에서 모두 프로세서 작업이 증가하고 컨텍스트 전환 속도와 인터럽트가 증가하는 것을 확인할 수 있을 것입니다. 서버의 프로세서가 부족해서 늘어난 부하를 처리할 수 없으면 대기열이 커질 수 있습니다. 이 경우에는 암호화 가속기와 같은 사용자 정의 하드웨어를 사용하는 것이 좋습니다.

SSL 프로토콜을 사용하는 경우에는 lsass.exe 프로그램이 CPU 를 상당히 많이 사용할 수도 있습니다. 이것은 SSL 처리가 발생하기 때문입니다. 따라서 Windows NT 에서 CPU 사용률을 모니터링 했던 관리자는 Inetinfo.exe 프로그램이 프로세서를 적게 사용하고 Isass.exe 프로그램이 프로세서를 많이 사용하는 것을 확인할 수 있습니다.

실제 메모리 사용: 보안 기능을 사용하려면 시스템이 사용자 정보를 보다 많이 저장하고 검색해야 합니다. 또 SSL 프로토콜이 메시지를 암호화하고 해독하는 데 긴 키(40비트에서 1,024 비트)를 사용합니다.

네트워크 트래픽: 로그온 암호를 인증하고 IP 주소를 확인하는 데 사용되는 도메인 컨트롤러와 IIS 5.0 기반 서버 사이의 트래픽도 증가하는 것을 확인할 수 있을 것입니다.

대기 시간 및 지연: SSL 과 같이 복잡한 보안 기능 때문에 발생하는 가장 큰 성능 저하는 많은 프로세서 주기를 사용하는 암호화 및 해독에 드는 비용과 노력입니다. 서버로부터 SSL 프로토콜을 사용해서 파일을 다운로드 하면 SSL 을 사용하지 않는 경우보다 10배에서 100배까지 느려질 수 있습니다.

Internet Information Services 5.0 20

서버에서 IIS 5.0 을 실행하면서 도메인 컨트롤러로도 사용하면 도메인 서비스에 필요한 프로세서 사용, 메모리, 네트워크 및 디스크 작업 등의 비율이 높아져서 이 리소스에 대한 부하가 크게 증가됩니다. 작업이 증가하면 IIS 5.0 서비스가 효율적으로 실행되지 않을 수 있습니다. 따라서 도메인 컨트롤러에서는 IIS 5.0 을 실행하지 않는 것이 좋습니다.

웹 응용 프로그램 모니터링

완벽하게 설계하여 철저하게 테스트한 응용 프로그램으로 불완전한 응용 프로그램을 업그레이드하면 성능을 크게 향상시킬 수 있습니다. 그러나 웹 응용 프로그램이 백 엔드 대기 시간(예: AS/400 과 같은 레거시 시스템)의 영향을 받을 수 있습니다. 여러 가지 이유로 원격 데이터 원본이 성능 문제를 일으킬 수 있습니다. 개발자가 다른 웹 사이트에서 데이터를 가져오도록 응용 프로그램을 설계했는데 해당 웹 사이트가 중단되면 서버에 병목이 발생할 수 있습니다. 응용 프로그램이 원격 SQL Server 데이터베이스에 액세스할 경우 데이터베이스가 받은 요청을 처리하는 데 문제가 발생할 수 있습니다. 사용자가 사이트의 SQL 데이터베이스 관리자일 수도 있지만 데이터베이스가 원격 시스템에 있을 경우에는 서버를 모니터링 하기 어려울 수도 있습니다. 또 데이터베이스 서버나 다른 백 엔드 서버를 제어하는 권한이 없을 수도 있습니다. 제어할 수 있으면 응용 프로그램과 작업을 하는 백 엔드 서버를 모니터링하고 웹 서버와 같은 방법으로 조정하십시오.

웹 응용 프로그램이 서버에 병목을 발생시키는지 확인하려면 다음 성능 카운터를 모니터링 하십시오. Active Server Pages: Requests/Sec, Active Server Pages: Requests

Executing, Active Server Pages: Request Wait Time, Active Server Pages: Request Execution Time 및 Active Server Pages: Requests Queued: 서버에서 ASP 응용 프로그램을 실행할 경우 이 카운터를 통해 응용 프로그램이 제대로 수행되고 있는지 확인 할 수 있습니다. Active Server Pages: Requests/Sec 카운터는 정적 파일이나 다른 동적 컨텐트에 대한 요청을 포함하지 않고 ASP 페이지의 복잡성과 웹 서버의 용량에 따라 크게 변합니다. 서버에 트래픽이 급격히 증가했을 때 이 카운터 값이 낮으면 응용 프로그램이 병목을 발생시킬 수 있습니다. Requests Executing 카운터에는 현재 실행 중인 요청 수가 표시되고, Request Wait Time 카운터에는 최근 요청이 대기열에서 대기한 시간이 1/1000 초 단위로 표시되고, Request Execution Time 카운터에는 최근 요청을 실행하는 데 걸린 시간이 1/1000 초 단위로 표시됩니다. Requests Queued 와 Request Wait Time 은 0에 가까운 것이 좋지만 부하 변화에 따라 증가하고 감소합니다. Requests Queued 최대값은 AspRequestQueueMax 에 대한 메타베이스 설정에 따라 결정됩니다. 제한에 도달하면 클라이언트 브라우저에 "HTTP 500/ ServerToo Busy" 메시지가 표시됩니다. 이 값이 예상 범위를 크게 벗어나면 ASP 응용 프로그램을 다시 작성해서 성능을 향상시켜야 합니다.

Request Execution Time 은 평균이 아니기 때문에 잘못 이해할 수도 있습니다. 예를 들어, 10ms 에 실행되는 페이지에 대한 요청 30 개와 500ms 에 실행되는 요청 하나를 주기적으로 받을 경우 평균 실행 시간은 25ms 가 넘지만 카운터에는 10ms 로 표시됩니다. 실행 중인 요청에 대하여 적절한 값을 정하기는 어렵습니다. 페이지가 빠르게 실행되어 I/O(파일 로드 또는 데이터베이스 쿼리)를 위해 대기할 필요가 없으면 이 값이 작을(시스템을 사용하고 있을 경우 프로세서 수보다 약간 큰) 것입니다. 페이지가 I/O 를 위해 대기해야 하는 경우에는 실행 중인 페이지 수가 AspProcessorThreadMax 값에 프로세서 수를 곱한 값과 비슷하게 클 것입니다. Requests Executing 값과 Requests Queued 값은 큰데 CPU 사용률이 낮으면 AspProcessorThreadMax 값을 높여야 할 수도 있습니다. 쓰레드 게이팅을 사용하면 Requests Executing 이 최적화됩니다. 사용자의 응답 시간은 Request Wait Time, Request Execution Time, 네트워크 대기 시간

Internet Information Services 5.0 21

등을 합한 값에 비례합니다.

Web Service: CGI Requests/sec 및 Web Service: ISAPI Extension Requests/Sec 는 서버가 CGI 및 ISAPI 응용 프로그램 요청을 처리하는 속도를 보고합니다. 부하가 증가하면서 이 값이 떨어질 경우 응용 프로그램 개발자에게 코드를 다시 검토하도록 의뢰해야 할 수도 있습니다. 참고로 ASP 는 ISAPI 확장이며 두 번째 카운터에 의해 포함됩니다.

Web Service: Get Requests/sec 및 Web Service: Post Requests/Sec 는 서버가 이 두 가지 종류의 HTTP 요청을 받는 속도를 나타냅니다. POST 요청은 일반적으로 양식에 사용되고 ISAPI(ASP 포함) 또는 CGI 로 전송됩니다. GET 요청은 POST 요청을 제외한 거의 모든 브라우저의 요청을 나타내고 정적 파일, ASP 및 기타 ISAPI 요청, CGI 요청 등을 포함합니다.

Error # Info Error Code

100 Information Codes Continue101 Information Codes Switching Protocols200 Success Codes OK201 Success Codes Created202 Success Codes Accepted203 Success Codes Non-Authoritative Information204 Success Codes No Content205 Success Codes Reset Content206 Success Codes Partial Content300 Redirection Codes Multiple Choices301 Redirection Codes Moved Permanently302 Redirection Codes Found303 Redirection Codes See Other304 Redirection Codes Not Modified305 Redirection Codes Use Proxy307 Redirection Codes Temporary Redirect400 Client Error Codes Bad Request401 Client Error Codes Unauthorized402 Client Error Codes Payment Required403 Client Error Codes Forbidden404 Client Error Codes Not Found405 Client Error Codes Method Not Allowed406 Client Error Codes Not Acceptable407 Client Error Codes Proxy Authentication Required408 Client Error Codes Request Timeout409 Client Error Codes Conflict410 Client Error Codes Gone411 Client Error Codes Length Required412 Client Error Codes Precondition Failed413 Client Error Codes Request Entity Too Large414 Client Error Codes Request-URI Too Large415 Client Error Codes Unsupported Media Type416 Client Error Codes Requested Range Not

Satisfiable417 Client Error Codes Expectation Failed500 Server Error Codes Internal Server Error

Internet Information Services 5.0 22

부록 1. HTTP 에러코드

501 Server Error Codes Not Implemented502 Server Error Codes Bad Gateway503 Server Error Codes Service Unavailable504 Server Error Codes Gateway Timeout505 Server Error Codes HTTP Version not supported

ASP 오류 코드 설명ASP 0100 메모리 부족ASP 0101 예기치 않은 오류ASP 0102 문자열 입력 예상ASP 0103 정수 입력 예상ASP 0104 작업을 허용하지 않음ASP 0105 범위를 벗어난 색인ASP 0106 형식 불일치ASP 0107 스택 오버플로ASP 0108 개체 만들기 실패ASP 0109 구성원 없음ASP 0110 알 수 없는 이름ASP 0111 알 수 없는 인터페이스ASP 0112 매개 변수 없음ASP 0113 스크립트 시간 초과ASP 0114 개체가 빈 쓰레드가 아님ASP 0115 예기치 않은 오류ASP 0116 스크립트 닫기 구문 기호 없음ASP 0117 스크립트 닫기 태그 없음ASP 0118 개체 닫기 태그 없음ASP 0119 클래스 ID 또는 프로그램 ID 특성 없음ASP 0120 잘못된 Runat 특성ASP 0121 개체 태그의 잘못된 영역ASP 0122 개체 태그의 잘못된 영역ASP 0123 ID 특성 없음ASP 0124 언어 특성 없음ASP 0125 특성 닫기 없음ASP 0126 포함 파일이 없음ASP 0127 HTML 설명 닫기 없음ASP 0128 파일 또는 가상 특성 없음ASP 0129 알 수 없는 스크립트 언어ASP 0130 잘못된 파일 특성ASP 0131 허용되지 않은 상위 경로ASP 0132 컴파일 오류ASP 0133 잘못된 클래스 ID 특성ASP 0134 잘못된 프로그램 ID 특성ASP 0135 순환적 포함ASP 0136 잘못된 개체 인스턴스 이름

Internet Information Services 5.0 23

부록 2. ASP 에러코드

ASP 0137 잘못된 글로벌 스크립트ASP 0138 중첩된 스크립트 블록ASP 0139 중첩된 개체ASP 0140 잘못된 페이지 명령ASP 0141 반복된 페이지 명령ASP 0142 쓰레드 토큰 오류ASP 0143 잘못된 응용 프로그램 이름ASP 0144 초기화 오류ASP 0145 새 응용 프로그램 실패

ASP 0146 새 세션 실패ASP 0147 500 서버 오류ASP 0148 서버 사용량이 많음ASP 0149 응용 프로그램 다시 시작ASP 0150 응용 프로그램 디렉터리 오류ASP 0151 변경 알림 오류ASP 0152 보안 오류ASP 0153 쓰레드 오류ASP 0154 HTTP 헤더 쓰기 오류ASP 0155 페이지 컨텐트 쓰기 오류ASP 0156 헤더 오류ASP 0157 버퍼링 설정ASP 0158 URL 없음ASP 0159 버퍼링 해제ASP 0160 로그 버퍼 꽉 참ASP 0161 데이터 형식 오류ASP 0162 쿠키를 수정할 수 없음ASP 0163 잘못된 콤마 사용ASP 0164 잘못된 시간 제한 값ASP 0165 SessionID 오류ASP 0166 초기화되지 않은 개체ASP 0167 세션 초기화 오류ASP 0168 허용되지 않는 개체 사용ASP 0169 없는 개체 정보ASP 0170 세션 삭제 오류ASP 0171 경로 없음ASP 0172 잘못된 경로ASP 0173 잘못된 경로 문자ASP 0174 잘못된 경로 문자ASP 0175 허용되지 않는 경로 문자ASP 0176 경로 찾을 수 없음ASP 0177 Server.CreateObject 실패ASP 0178 Server.CreateObject 액세스 오류ASP 0179 응용 프로그램 시작 오류ASP 0180 허용되지 않는 개체 사용ASP 0181 잘못된 쓰레드 모델

Internet Information Services 5.0 24

ASP 0182 없는 개체 정보ASP 0183 빈 쿠키 키ASP 0184 쿠키 이름 없음ASP 0185 기본 등록 정보 없음ASP 0186 인증서 구문 분석 오류ASP 0187 개체 추가 충돌ASP 0188 허용되지 않는 개체 사용ASP 0189 허용되지 않는 개체 사용ASP 0190 예기치 않은 오류ASP 0191 예기치 않은 오류ASP 0192 예기치 않은 오류ASP 0193 OnStartPage 실패ASP 0194 OnEndPage 실패ASP 0195 잘못된 서버 방법 호출ASP 0196 독립 프로세스 구성 요소를 시작할 수 없음ASP 0197 허용되지 않는 개체 사용ASP 0198 Server shutting downASP 0199 허용되지 않는 개체 사용ASP 0200 범위를 벗어난 '만료 날짜' 특성ASP 0201 잘못된 기본 스크립트 언어ASP 0202 코드 페이지 없음ASP 0203 잘못된 코드 페이지ASP 0204 잘못된 CodePage 값ASP 0205 알림 바꿈ASP 0206 BinaryRead 을 호출할 수 없음ASP 0207 Request.Form 을 사용할 수 없음ASP 0208 일반 Request 수집을 사용할 수 없음ASP 0209 TRANSACTION 속성의 잘못된 값ASP 0210 구현되지 않은 방법ASP 0211 영역을 벗어난 개체ASP 0212 버퍼를 지울 수 없음ASP 0214 잘못된 경로 매개 변수ASP 0215 ENABLESESSIONSTATE 속성의 잘못된 값ASP 0216 MSDTC 서비스를 실행하고 있지 않음ASP 0217 개체 태그의 잘못된 영역ASP 0218 LCID 가 없음ASP 0219 잘못된 LCIDASP 0220 GLOBAL.ASA 에 대한 요청이 허용되지 않음ASP 0220 스크립트를 트랜잭션하지 않음ASP 0221 잘못된 @ Command 디렉티브ASP 0222 잘못된 형식 라이브러리 지정ASP 0223 형식 라이브러리를 찾을 수 없음ASP 0224 형식 라이브러리를 로드할 수 없음ASP 0225 형식 라이브러리가 래핑될 수 없음ASP 0226 StaticObjects 를 수정할 수 없음

Internet Information Services 5.0 25

ASP 0227 Server.Execute 실패ASP 0228 Server.Execute 오류ASP 0229 Server.Transfer 실패ASP 0230 Server.Transfer 오류ASP 0231 Server.Execute 오류ASP 0232 잘못된 쿠키 사양ASP 0233 쿠키 스크립트 소스를 로드할 수 없음ASP 0234 잘못된 include 지시어ASP 0235 Server.Transfer 오류ASP 0236 잘못된 쿠키 사양ASP 0237 잘못된 쿠키 사양ASP 0238 없는 특성값ASP 0239 파일을 처리할 수 없음ASP 0240 스크립트 엔진 예외ASP 0241 CreateObject 예외ASP 0242 OnStartPage 인터페이스 예외 쿼리ASP 0243 Global.asa 에 있는 잘못된 METADATA 태그ASP 0243 Request 에서 IStream 을 사용할 수 없음ASP 0244 세션 상태를 사용할 수 없음ASP 0246 동시 사용자 수가 너무 많음. 나중에 다시 연결해 보십시오.ASP 0246 잘못된 기본 코드 페이지

Microsoft® Internet Information Services 5.0 Resource Guide

Art and Science of Web Server Tuning with Internet Information Serviceshttp://www.microsoft.com/TechNet/iis/ii5tune.asp

Windows2000 웹 서버의 가용성을 높이는 방법http://www.microsoft.com/korea/technet/prodtechnol/iis/deploy/rollout/websrvbp.asp

성능 및 안정성 모니터링http://www.microsoft.com/korea/technet/iis/prfrelmn.asp

WAS – Web Stress Tool Tutorialhttp://webtool.rte.microsoft.com/tutor/default.htm

Internet Information Services 5.0 26

참고자료