민우아빠[사가]의 잼있는세상

http://blog.naver.com/altx1/21908366

Q . IIS 튜닝 하는 방법 자료에 대해서

A . 웹컨텐트에 대한 보안과 함께 액세스가 빈번한 대용량 사이트라면 기본설정으로는 무리가 따르게 되므로 적절한 튜닝이 더욱 필요하다. 이런 튜닝 기술은 단순한 직감으로 수행될 수 없으므로 원리와 효과를 예측할 수 있도록 지식을 쌓는 것이 중요하다. 하지만 사용하는 시스템 환경에 따라 경우가 천차만별이므로 절대적인 기준을 제시하기는 어렵다. 그러므로 웹서버 트래픽 분석 및 적절한 벤치마킹을 통해 전문가들이 가이드라인을 제시하는 것이 일반
적이다. (이 튜닝 포인트 가이드는 IIS 4.0을 기준으로 함). 다시 강조하지만 이러한 가이드조차 절대적인 것이 없으므로 웹관리자 스스로 서버 벤치마크 도구와 트래픽 분석을 통해 본인의 사이트에 맞는 기준을 설립하는 것이 중요하다.

1. 전체적인 튜닝 포인트

NT 서버는 그 사용도에 따라 서버를 최적화할 수 있도록 '사용 메모리 최소화', '균형 유지', '파일 공유 처리량 최대화', '네트워크 응용 프로그램 처리량 최대화' 등 4개의 서버 옵션을 제공한다.

NT 도움말을 보면 네트워크에 연결에 할당된 메모리와 사용자 컴퓨터에서 실행중인 응용 프로그램에 할당된 메모리 사이의 관계를 바로 이 옵션을 통해 조정할 수 있다고 돼 있다. 그러나 독자들의 관심사는 웹서버인 IIS 4.0일 것이므로 서버 최적화 옵션을 '네트워크 응용 프로그램 처리량 최대화'로 설정해 IIS 서버가 보다 많은 메모리를 사용하도록 하면 성능을 높일 수 있다.

IIS 서버는 파일 서버에 비해 페이지 오류(page fault)가 더 많이 발생하므로 파일 캐시 기능을 강화하기 위해 서버 옵션을 위와 같이 설정해야 한다고 되어 있다. 페이지 오류란 가상 메모리와 관련된 기술용어로 응용 프로그램에서 사용하는 가상 메모리 중 물리적인 메모리에 적재돼 있지 않은 곳을 프로그램에서 읽으려고 할 때 발생하는 시스템 이벤트다. 일단 페이지 오류가 발생하면 운영체제는 응용 프로그램에서 하던 일을 전부 멈추고 이 문제를
해결하기 위해 디스크로 스왑핑돼 있던 가상 메모리 영역 중 프로그램에서 요구한 부분을 물리적인 메모리로 읽어 오는 작업을 하게 된다. 그런데 문제는 디스크 읽기/쓰기 작업이 메모리 읽기/쓰기 작업에 비해 엄청나게 시간이 오래 걸린다는 점이다. 따라서 페이지 오류가 많이 발생하는 응용 프로그램에서 사용하는 가상공간은 가능한 물리적인 메모리 안에 두는 것이 성능을 극대화시킬 수 있는 것이다. 이것 서버 최적화 옵션을 선택하는 원인과 예
상할 수 있는 효과이다.

초창기 웹서버인 NCSA부터 시작해 거의 모든 웹서버는 '로깅(logging)' 기능을 가지고 있다. 로그에는 웹컨텐트 사용자에 대한 각종 정보가 담겨져 있어 문제점을 파악하고 사용자의 취향에 대한 판단을 할 수 있는 중요한 근거가 된다. 그러나 수백명이 웹서버를 이용하고 있는 상황에서 웹서버는 사용자가 원하는 파일을 개별적으로 가져다주기도 힘겨운데, 요구한 각 파일마다 로그기록을 남기도록 한다면 웹서버가 스트라이크(?)를 일으키는 상황이 종종 발생하게 된다. 이에 대해 튜닝 가이드는 사용자 경향을 어느 정도 파악한 사이트라든지, 성능이 무척 중요한 사이트라면 IIS 로깅 기능을 끄도록 권하고 있다. 로그를 반드시 봐야 한다면 일부 파일에 대한 로깅만 수행하는 '부분로깅'을 동작시키던지, 아니면 로그를 기록하는 디스크에 대한 부담을 줄이기 위해 스트라이프 파티션에 로그 파일을 두면 서버 성능 저하를 피할 수 있다.

2. 네트워크 튜닝 포인트

웹서버의 기반 프로토콜인 HTTP, FTP는 TCP/IP 위에서 동작하기 때문에 TCP/IP 설정 방법에 따라 성능차가 크게 나게 된다. 일반적인 응용 프로그램 서버로 NT 서버를 사용할 때에는 굳이 TCP/IP 설정을 바꿀 필요가 없지만, 사이트 규모가 큰 경우에는 보다 효율적인 운영을 위해 손질할 필요가 있다.
여기서는 NIC 파라미터와 TCP 파라미터에 대한 튜닝에 대한 포인트를 설명하기로 하고, 참고로 HTTP도 1.1 스펙을 보면 성능 향상을 위해 몇 가지 추가된 기능이 들어 있다. 이 기능은 클라이언트와 서버 모두에서 HTTP 1.1 스펙을 지원해야 하기 때문에 한계가 있지만 TCP/IP 상위 프로토콜에서도 튜닝할 부분이 있다는 점만은 알아두는 것이 좋다(보다 자세한 내용은 옵션팩 온라인 도큐먼트 중 IIS 서버 관리, 성능 튜닝 부분을 참조).

TCP/IP 프로토콜에서는 슬라이드 윈도우 기법을 사용해 흐름 제어(flow control)를 수행한다. 흐름 제어란 물리적인 네트워크에 통신 패킷들이 어느 한 곳에서 막히지 않고 원활히 지나다닐 수 있도록 제어하는 기법을 말한다. 여러 가지 흐름제어 방법 중 TCP/IP는 특정 윈도우 크기만큼 데이터 패킷들을 보내고 ACK를 받는 방식으로 흐름을 제어한다. 따라서 빠른 네트워크를 사용할 때는 윈도우 버퍼 크기를 크게 잡으면 잡을수록 보다 많은 데이터를
한꺼번에 전송할 수 있으므로 성능이 높아진다. 하지만 느린 네트워크에서는 오히려 문제가 발생할 소지가 있으므로 이 방법이 항상 좋은 것은 아니다. 이 값은 레지스트리 편집기인 regedt32.exe를 사용해 HKEY_LOCAL_MACHINE\CurrentControlSet\TCPIP 파라미터를 찾아보면 알 수 있는데, TcpWindowSize이다. 튜닝 가이드에 의하면 약 0x4470 정도로 값을 설
정하면 된다.

또다른 TCP/IP 파라미터로 'MaxUserPort'라는 것이 있다. 이 파라미터는 웹클라이언트에서 웹서버에 접속할 때 사용하는 사용자 포트의 최대 개수를 지정하는 키값을 의미하기 때문에 많은 사용자들이 서비스를 받고자 할 때 사용자 포트의 부족으로 패킷이 드롭(drop)돼 재전송되는 현상을 줄이고자 크게 잡는다. 튜닝 가이드에 의하면 0xfffe 정도로 설정하라고 되어있다.

3. 멀티 CPU 튜닝 포인트

여러 개의 CPU가 있는 시스템은 보다 빠르게 처리하도록 작업을 여러 CPU에 배분시킨다. 이렇게 배분된 작업은 쓰레드란 단위로 각 프로세서에서 실행된다. 쓰레드란 프로세서보다 가벼운 실행 단위로 순차적으로 실행되는 쓰레드(thread)를 의미한다. 요즘 출시되는 대부분의 서버는 다중쓰레드 구조를 가지고 있어, 동시에 여러 작업을 서버 내에서 처리하도록 되어 있다. IIS 4.0도 다중쓰레드를 사용해 웹클라이언트에서 요청한 작업을 여러 CPU에 분산시켜 처리 성능을 높인다. 그런데 만약 웹클라이언트에서 특정 파일을 요구하
고 난 후 IIS 서버가 그 작업용으로 쓰레드를 할당하려고 하는데 사용할 수 있는 쓰레드가 없는 경우가 발생한다면? 요구 자체를 지연(block)시킬 수밖에 없고, 사용 가능한 쓰레드가 생길 때까지 멈추게 된다. 결국 사용할 수 있는 쓰레드수의 부족으로 웹서버 성능이 저하될 수 있다는 얘기다.

현재 얼마나 많은 쓰레드가 실행중인가를 확인하려면 윈도우 NT 성능 모니터를 실행시킨 후 'System' 개체에서 'Processor Queue Length' 카운터를 차트에 추가하면 현재 시스템의 프로세서 큐 길이를 지켜볼 수 있다. 이 값은 현재 실행중인 쓰레드를 표시하지 않기 때문에 보통 상황에서는 1의 값을 가진다. 이 값은 프로세서가 N개일 때, N에서 3×N 정도로 설정하면 좋다. 이 값이 의미하는 바나 적절한 값을 잘 모르겠으면 건드리지 말고 디폴트로 놓도록 하되, IIS에서 사용하는 쓰레드수를 늘려주고 컨텍스트 스위치 횟수를 줄
이는 방향으로 튜닝해야 한다. 예를 들면, IIS 로드가 일정한 정적 환경에서는 MaxPoolThreads는 1로, PoolThreadLimit를 N으로 설정하도록 권장하고 있다. 이렇게 구성하면 프로세서 당 1개씩 쓰레드를 배치시켜 컨텍스트 스위치 횟수를 줄이는 동시에 IIS에서 사용할 수 있는 쓰레드의 개수를 늘려주므로 좀더 나은 성능을 얻을 수 있다.

4. 정적 환경에서의 튜닝 포인트

IIS 4.0에서는 객체 캐시 기능을 제공해 객체에 대한 사용이 끝나도 일정한 시간 동안 메모리에 가지고 있다가 다시 사용할 때 디스크에서 읽어올 필요 없이 곧바로 캐시 안에 있는 객체를 사용한다. 객체가 캐시 내에서 유지되는 시간을 TTL(Time To Live)라고 하며, 디폴트 값은 30초로 되어 있다. 만약 웹사이트 내용이 메모리에 적재될 정도이고 자주 바뀌는 것이 아니라면, 아에 TTL을 0xffffffff로 설정해 객체가 항상 캐시 안에 있도록 할 수도 있지
만, 대다수의 경우에는 메모리 안에 웹컨텐트가 모두 적재되지 않기 때문에 TTL값을 적절히 조절해야 할 필요가 있다.

아주 자주 사용되는 파일이 있다면, 이 TTL값을 크게 설정해 성능 향상을 꾀할 수도 있다. 반면 자주 요청되는 파일들이 많은 경우에는 TTL값을 크게 해도 성능 증대를 기대할 수 없고, TLL 값을 낮춰 캐시 안에 있는 객체수를 줄임으로써 시스템 자원이 고갈되는 것을 막을 수 있다. 캐시 안에 유지되는 파일수는 다음에 설명될 OpenFileInCache값을 조절하면 조정이 가능하다.
TTL 값은 레지스트리키인
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters안에 있는 ObjectCacheTTL값으로 설정된다.

IIS는 또한 캐쉬 안에 유지되는 파일 핸들의 수를 지정할 수 있도록 OpenFileInCache라는 레지스트리값을 제공한다. 이 값은 한번 열려진 파일에 대한 핸들을 몇 개나 저장하겠느냐를 의미하는 것으로 IIS 캐시용으로 할당할 수 있는 메모리양과 캐시 내에 저장하길 원하는 파일 핸들의 수에 따라 달라진다. 일반적으로 큰 웹사이트에서는 보다 많은 파일핸들을 캐싱시켜 성능을 높일 수 있으며, 일정한 파일만을 가진 웹사이트의 경우에는 그 파일
수보다 큰 값으로 OpenFileInCache값을 설정해 모든 파일들을 디스크 입출력 없이 메모리에서 파일을 읽어옴으로써 성능을 극대화할 수도 있다. 이 값을 적절히 선택하기 위해서는 NT성능 모니터를 사용해 'Internet Information Server Gobal' 개체 중 'Cached File Handles' 카운트값을 모니터링함으로써, 메모리 낭비없이 어느 정도면 많이 사용하는 파일 핸들을 캐시 내에 저장할 수 있을지를 예상할 수 있을 것이다.

5. 액티브 서버 페이지 튜닝 포인트

IIS 4.0은 MTS 2.0과 통합돼 각종 ASP 스크립트나 COM 컴포넌트들에 대해 트랜잭션 성격을 부과할 수 있게 됐다. IIS는 MTS의 실행을 위해 CPU당 일정한 수의 쓰레드를 할당해 놓는다. 이 값은 레지스트리 키 중 HKEY_LOCAL_MACHINE\System\CurrentControlSet\ServicesW3SVC\ASP\Parameters안에 있는 ProcessorThreadMax값으로 설정할 수 있다. 잘 만들어진 ASP의 경우라면 이 값이 적을수록 경쟁 감소 효과가 일어나므로 이 값을 줄여보고 성능을 모니터링한 뒤, 만약 성능이 떨어지면 원상태로 복귀하는 방식으로 튜닝하면 된다.

ProcessorThreadMax와 연계된 튜닝 포인트로 AspScriptEngineCacheMax라는 값이 있다. 이 값은 대개 ProcessorThreadMax값에 시스템에서 제공하는 프로세서의 수를 곱한 값으로 설정한다. 이렇게 설정함으로써 각 ASP 쓰레드가 좀더 효과적으로 ASP 페이지들을 처리하도록 스크립트 엔진들을 하나씩 캐시하게 된다.

또한 ASP 응용 프로그램들에서 클라이언트로 출력되는 모든 내용을 버퍼링한 후 마지막에 한꺼번에 출력시킴으로써 성능을 높일 수도 있다. 이 기능은 MS 관리 콘솔에서 인터넷 인포메이션 서버 스냅인(snap-in)을 선택하고, 특성을 선택한 후 'Home/Virtual Directory' 특성 페이지를 열고, 'Configuration' 버튼을 누르고, 'App Options'에서 'Enable Buffering'을 클릭하면 된다.

ASP 안에서 세션을 유지하기 위해 '세션객체(session object)'를 사용하는데, 이 객체를 계속해서 유지하려면 시스템 자원을 점유하게 된다. 만약 1000명의 사용자가 동시에 연결된다면, 각 사용자당 세션 상태를 유지시키기 위해 굉장히 많은 양의 시스템 자원을 점유해야 한다. 세션을 유지하는 한 시스템 자원을 점유해야 하므로 세션 타임 아웃값을 적절히 설정한다면, 서버 자원 사용을 최적화할 수 있을 뿐만 아니라 성능 또한 증대시킬 수 있다.
웹 응용프로그램은 또한 In-process와 Out-of-process를 지원하는데 성능면에서는 In-process를 사용하는 것이 바람직하다. Out-of-process는 주로 개발 기간에 웹 응용프로그램에 Bug가 내제 되어 있는 시점에 전체 IIS 서버에 영향을 안 끼치기 위한 방법으로 사용된다.

성공적인 NT 웹서버 관리를 위해

NT 서버의 성능 및 보안체계 튜닝 작업은 가상 시뮬레인션인 벤치마킹과 실제 데이터인 로그 데이터, 성능 데이터를 기반으로 하고 있으므로 실제 튜닝 작업에 들어가기 전에 관련 도구 및 데이터 분석 능력도 함께 키워야 제한된 능력만을 가진 서버 관리자에서 벗어나 고급 관리자로 탈바꿈할 수 있을 것이다.

저작권 (주)마이크로소프트
http://www.microsoft.com/korea/support/kb/K000987.htm

출처 : ntfaq.co.kr

크리에이티브 커먼즈 라이센스