Q . 동시 접속자수가 많을 때, IIS의 급격한 성능 저하 또는 서버 장애 현상
Tuesday, March 14, 2000

A . IIS와 관련된 문제 중 성능이 떨어 진다거나 마치 서버가 죽은 것처럼 되는 경우, 대부분 특별한 오류 이벤트나 오류 메시지가 발생하지 않으므로 원인을 추정하기가 어려운 경우가 대부분입니다. 하지만, 대부분의 그런 경우는 ASP 프로그램상에 문제가 있는 경우가 많다는 사실이 지금까지의 기술지원 경험을 통해서 밝혀졌습니다. 여기서는 이를 위한 기본적인 ASP 프로그래밍 가이드 및 서버 장애 현상을 분석하는 방법을 소개합니다.

IIS는 ASP 프로그램이 실행되는 운영체제와 같습니다. 따라서 ASP 프로그램을 잘못 만들게 되면 IIS는 비정상적인 상태로 빠지게 되고 그로 인해 장애현상 또는 속도 저하가 발생하게 됩니다. 따라서 그러한 문제가 발생하였다면 근본적으로 ASP 프로그램 또는 ISAPI/COM 프로그램들을 바꾸지 않고서는 해결이 불가능합니다. 하지만 다행스러운 것은 프로그램을 변경하는 작업이 매우 어렵게 느껴지나 사실은 매우 단순한 작업이고 해야 하는 일도 어렵지 않습니다. 다음은 ASP에서 흔히 하는 실수 입니다.
유의: 시중에 ASP관련 책자들의 내용과 다른 부분이 있을 수 있으므로 혼동이 되는 부분이 있을 수 있을 것입니다. 하지만, ASP 프로그램이 서버에서 수행되는 프로그램인 만큼 하나의 작은 실수가 전체 성능에 엄청난 영향을 끼친다는 것을 감안할 때, 기존에 방법을 따르지 마시고 반드시 여기서 제시되는 프로그래밍 지침을 지켜주십시오. 실제 기술 지원을 통해서 이와 같은 방법으로 90% 이상이 해결 되었습니다.
유의: ASP 튜닝 지침은 http://www.microsoft.com/korea/support/kb/k001353.htm 에 있습니다. 반드시 함께 참조 하십시오. 여기서는 IIS 서버관점에서 내용을 좀 더 보강한 것 입니다.

1. Object 변수는 반드시 Nothing 시켜 주어야 합니다.

- Object 변수는 생성을 한 뒤 사용을 한 후 동일 ASP 페이지에서 즉시 Nothing으로 사용된 메모리를 Free 시켜주어야 합니다. 통상적으로 변수를 Nothing 처리 시켜주지 않아도 IIS 가 자체적으로 ASP 페이지 프로그램 종료 때 자동으로 반환하므로 이 작업을 하지 않는데 동시 사용자 수가 많은 경우는 이것을 하지 않게 되면 서버가 메모리를 적시에 반환을 못하게 되어 결국 메모리 부족현상이 일어나는 경우가 있습니다. 그리고 오류 처리를 하는 경우 오류가 난 시점에서 그때까지 만들어진 모든 Object 변수를 Nothing 처리하여 주어야 하는 것을 잊어서는 안됩니다. 오브젝트 변수를 Nothing 시키는 방법은 ‘Set 변수명 = nothing’ 입니다.

2. 변수 Nothing 처리는 페이지 레벨로 이루어져야 합니다.

- ASP 프로그램에 세션 변수라는 것이 있어 세션이 활성화 되어 있는 동안 계속 재사용할 수 있습니다. 흔히들 하는 “DB Connection Object 변수를 세션 변수로 만들어 세션 종료시점에 Nothing하면 된다” 라는 우를 범하게 됩니다. 이것은 사실이 아닙니다. DB Access를 하는 ASP 프로그램에서 가장 속도가 많이 걸리는 부분은 SQL 서버의 응답시간이 늦어져서 발생하는 속도 저하 현상입니다. 따라서 가능한 SQL서버의 부하를 덜어야만 응답속도를 최소화 할 수 있는데 위에서 말한 Connection 변수를 세션변수로 사용하게 되면, SQL 서버가 처리하는 동시 접속자수가 계속해서 증가하므로 SQL 서버가 현저히 늦어지는 문제가 발생하며, 실제로 SQL 서버가 답을 느리게 주므로 IIS 서버가 마치 죽은 것처럼 속도가 매우 떨어지는 현상이 발생합니다. 즉, 세션/응용프로그램 수준의 Object 변수는 가능한 사용하지 말아야 합니다.
따라서 DB Connection 변수는 Page 레벨에서 만들어서 바로 그 Page에서 Nothing 시켜주어야 합니다.

3. 변수 Nothing 처리는 가능한 빨리 이루어져야 합니다.

- 흔히 ASP 프로그램을 짜는 경우 Object 변수를 ASP 맨 처음에 생성하여 맨 뒤에서 Nothing을 하는 습관을 가진 분들이 있는데 이것 또한 IIS에 동시 접속사용자 수가 많아지면 문제가 될 수 있습니다. Object 변수를 만드는 시점은 그 변수를 사용하는 시점에서 생성을 해야 하고 사용이 끝난 시점에서 바로 Nothing을 시켜야 합니다. 예를 들면, DB Connection 변수의 사용도 한번 Connection을 맺고 페이지 맨 끝에서 Nothing 시켜 주는 것보다 ASP가 다소 길어지지만 여러 번에 걸쳐 필요한 그 시점마다 Connection을 맺게 하는 것이 더 효율적일 수가 있습니다.

4. SSI (Server Side Include)는 아주 필요한 곳 이외는 가급적 사용하지 말아야 합니다.

- ASP 가 실행하기 위해서는 IIS에 의해서 매번 Compile을 하여야 하므로 ASP 파일 사이즈가 커지면 컴파일 속도로 인해서 CPU를 많이 사용하게 되며 이것 또한 속도 저하 현상과 매우 밀접한 관계에 있습니다. 따라서 ASP 크기를 줄이기 위해서라도 불필요한 SSI의 사용을 절제해야 합니다. 또한 하나의 ASP 페이지에 HTML 코드가 많이 들어 있어 파일 크기가 많이 늘어나는 경우가 종종 있는데 이것 또한 문제가 됩니다. 확장명 .ASP 인 것들은 언제나 IIS 가 컴파일을 해야 하므로 무조건 파일을 작게 해야 함을 명심하여야 합니다.

5. DB Access를 하는 경우 DB 튜닝을 하지 않아서 속도 저하가 발생하는 경우가 있습니다.

- SQL 서버 자체적인 튜닝은 여러 가지 단계가 있습니다. 담당 SQL 관리자에게 문의하시고 특히 Table에 인덱스가 효율적으로 만들어졌는지 Query Optimizaition 이 이루어져야 합니다.

6. Object 변수를 사용할 때는 매뉴얼 참조하여 정확히 사용하십시오.

- 예를 들면 SQL Connection 변수나 Record Set 변수는 Nothing을 하기 전에 반드시 .Close 를 실행해 주어야 합니다. 하지만 이것을 생략하여도 어떠한 오류가 발생하지 않으므로 무시하는 경우가 있는데 이것은 잠재적으로 SQL 서버에 부하를 주는 원인이 됩니다. 따라서 Object 변수를 사용할 때는 그 사용방법을 정확히 알고 사용하셔야 한다는 것을 명심하십시오.

7. MDAC 2.1 이후 부터는 DB Connection 을 할 때 Provider를 반드시 명시하여야 합니다.

- DB 접속을 할 때 ‘DSN=~~,~~’ 식으로 Provider를 명시하지 않아도 문제가 없었으나 MDAC 2.1 이후 부터는 반드시 ‘Provider=SQLOLEDB,~~’ 와 같이 Provider를 명시하여야 합니다. 그렇지 않은 경우에 속도 저하 또는 서버 장애 현상이 일어날 수 있습니다.
유의: ASP 프로그램을 위의 가이드대로 되지 않은 것이 있다면 모두 수정하여 주십시오. 이것을 해결하지 않고 Machine을 늘리거나 메모리를 증설하는 것은 문제 해결에 도움이 되지 않습니다. ASP 수정작업이 모두 끝났다면 다음 가이드대로 IIS 시스템이 설치되어 있는 컴퓨터의 레지스트리를 조정하여 주십시오. 이것은 시스템 속도를 높이기 위한 기본적인 가이드입니다.
MaxPoolThreads : REG_DWORD
Range: 0 - 0xFFFFFFFF Default: 10 ======> 20 (변경가능 적정값)

MaxPoolThreads는 Processor 마다 생성될 수 있는 pool threads의 수를 명시합니다. 이 값은 inetinfo process의 i/o thread로 일반적으로 20이상의 값을 설정하는 것은 좋지 않습니다.
아래의 레지스트리에서 설정 :

[HKEY_LOCAL_MACHINE]
\SYSTEM
\CurrentControlSet
\Services
\InetInfo
\Parameters

ServerListenBacklog : INTEGER
Range: 0 - unlimited Default: 200 ======> 1000(변경가능 적정값)

이 값은 queue될 수 있는 미활성된 Socket의 수를 명시합니다.

설정 방법 : c:\winnt\system32\inetsrv\adminsamples\adsutil.vbs SET w3svc/ServerListenBacklog 1000

ServerSize: Long
Range: 0 ? 2 ======> 2 (변경가능 적정값)

이 값은 날마다 처리되는 클이언트 Request의 수에 의존한 서버의 일반적인 크기를 명시합니다. 이 값은 MMC를 통해서도 수정이 가능합니다. ( Web site의 등록정보에서 성능 탭에 성능 조정에서 설정 가능합니다.)
아래의 레지스트리에서 설정 :

[HKEY_LOCAL_MACHINE]
\SYSTEM
\CurrentControlSet
\Services
\InetInfo
\Parameters

MaxEndPointConnections : LONG
Range: 0 - unlimited Default: 200 ======> 1000(변경가능 적정값)

이 값은 네트워크 Endpoint에 모일 수 있는 Listen Socket의 최대 값을 명시합니다. 한 포트에 연결될 수 있는 Connection 의 수를 말합니다.
설정 방법 : c:\winnt\system32\inetsrv\adminsamples\adsutil.vbs SET w3svc/MaxEndPointConnections 1000

ProcessorThreadMax REG_DWORD
Range: 1 - 0x000000C8Default: 10 ===> 20(변경가능 적정값)
이 값은 ASP 처리를 위해 Processor마다 생성될 수 있는 Worker Thread의 개수를 명시합니다. 이 값은 일반적으로 20을 넘지 않는 것이 좋습니다.
아래의 레지스트리에서 설정 :

[HKEY_LOCAL_MACHINE]
\SYSTEM
\CurrentControlSet
\Services
\W3SVC
\ASP
\Parameters

RequestQueueMax REG_DWORD

Range: 1 - 0xFFFFFFFFDefault: 500 ===> server too busy message 가 없다면 바꿀 필요는 없습니다.
이 값은 각 Thread 에 유용한 Request Queue의 최대 개수를 명시합니다. Request Queue는 사용자로부터의 .asp Request가 처리되기 전에 일시적으로 저장되는 곳이다. Queue의 크기가 너무 적으면 client 사용자는 Server too busy라는 메시지를 보게 될 수 있습니다.
아래의 레지스트리에서 설정 :

[HKEY_LOCAL_MACHINE]
\SYSTEM
\CurrentControlSet
\Services
\W3SVC
\ASP
\Parameters

자료참조 : MS

저도 그와 같은 현상이 발생 해서 문제가 많았습니다. 동시 사용자가 400-500 명 정도가 나타날시 꼭 그와 같은 문제가 있더군요
그래서 고민 하다가 IE 5.0 을 삭제 후 4.0 로 사용 했습니다.
그랬더니 해결이 되었는데...
글세요
여러가지 문제가 있겠죠