성능 및 스타일 향상에 도움이 되는 28가지 ASP 팁 6 ~ 10

>> 출처: https://www.microsoft.com/korea/technet/iis/tips/asptips17_06.mspx

6. 세션 개체를 올바르게 사용하십시오. 

지금까지 데이터를 응용 프로그램 및 세션 개체에 캐시함으로써 얻을 수 있는 장점들에 대해 얘기했으며, 이제는 세션 개체를 사용하지 말라는 제안을 하려고 합니다. 세션 개체는 아래에 설명된 바와 같이 사용량이 많은 사이트에서 사용할 때 발생하는 수많은 곤란한 문제들을 가지고 있습니다. 여기서 사용량이 많은 사이트는 일반적으로 1초 당 사용되는 페이지 수가 수 백개에 달하거나 동시에 접속하는 사용자 수가 수 천명에 달하는 사이트를 의미합니다. 수평으로 확장해야 하는 사이트, 즉 여러 대의 서버를 사용하여 로드를 분산시키거나 내결함성을 구현하는 사이트에서는 이 팁이 더욱 중요합니다. 인트라넷 사이트와 같이 소규모 사이트인 경우에는 세션 사용으로 인한 편리함이 크기 때문에 오버헤드가 생기는 단점을 보상할 수 있습니다. 

재생을 위해 ASP는 웹 서버에 접속하는 모든 사용자에 대해 세션을 자동으로 만듭니다. 각각의 세션은 10KB 정도의 메모리 오버헤드를 가지며 모든 요청을 약간씩 느려지게 만드는데, 이 때 오버헤드는 종류에 상관없이 데이터가 세션에 저장될 때마다 항상 맨 위에 놓여집니다. 세션은 구성 가능한 초과 시간이 경과할 때까지 계속 사용되며 그 초과 시간은 보통 20분입니다. 

세션에 관련된 가장 큰 문제는 성능이 아닌 확장성에 관련된 문제입니다. 세션은 웹 서버를 스팬하지 않습니다. 즉, 일단 세션이 한 대의 서버에서 만들어진 이후에는 그 데이터가 그대로 보존됩니다. 따라서 웹 그룹에서 세션을 사용하고 있다면, 사용자의 세션이 있는 서버로 향하도록 각 사용자의 요청을 처리하기 위한 전략을 세워야 합니다. 이러한 전략을 세우는 작업은 웹 서버에 대한 사용자 "Sticking"이라고 합니다. "Sticky Session"이라는 용어는 바로 여기에서 유래된 것입니다. 세션은 디스크에 영구적으로 저장되지 않기 때문에, "sticky 상태의" 사용자는 웹 서버의 작동이 중단되면 자신의 세션 상태를 잃게 됩니다. 

Sticky Session을 구현하기 위한 전략에는 하드웨어 및 소프트웨어 솔루션이 포함됩니다. Windows 2000 Advanced Server의 네트워크 로드 균형 조정 및 Cisco사의 Local Director 등과 같은 솔루션을 사용하면 약간의 확장만으로도 Sticky Session을 구현할 수 있습니다. 이러한 솔루션들은 완벽하지가 않습니다. 이 시점에서는 자기만의 소프트웨어 솔루션은 사용하지 않는 것이 좋습니다. Microsoft에서는 ISAPI 필터와 URL 맹글링(mangling) 등을 사용했습니다. 

응용 프로그램 개체는 서버를 스팬하지 않기 때문에, 웹 그룹에 걸쳐 응용 프로그램 데이터를 공유하고 업데이트해야 할 경우에는 백엔드 데이터베이스를 사용해야 합니다. 단, 읽기 전용 응용 프로그램 데이터는 웹 그룹에서 그대로 사용할 수 있습니다. 

업무상 중요한 대부분의 사이트에서는 가동 시간을 늘리려는 이유가 아닌 다른 이유, 즉 장애 조치 및 서버 유지 관리를 처리하기 위해 두 대 이상의 웹 서버를 구축하려고 할 것입니다. 따라서 업무상 중요한 응용 프로그램을 설계할 때, "Sticky Session"을 구현하거나 그렇지 못하면 세션 사용을 피해야 합니다. 또한 사용자 상태를 개별 웹 서버에 저장하는 다른 상태 관리 기술들도 사용해야 합니다. 

세션을 사용하고 있지 않으면 세션 기능을 반드시 해제해야 합니다. 인터넷 서비스 관리자를 통해 응용 프로그램의 세션 기능을 해제할 수 있습니다. 자세한 내용은 ISM 설명서를 참조하십시오. 세션을 사용하는 경우에는 다양한 방법으로 세션이 성능에 미치는 영향을 최소화할 수 있습니다. 

도움말 화면, 방문자 영역 등과 같이 세션에 필요하지 않은 내용은 세션 기능이 해제되어 있는 별도의 ASP 응용 프로그램으로 옮길 수 있습니다. 각 페이지 단위로 해당 페이지에서 세션 개체를 필요로 하지 않는 ASP에게 힌트를 제공할 수 있습니다. 다음과 같은 지시어를 ASP 페이지의 맨 위에 넣으십시오. 

<% @EnableSessionState=False %>

위와 같은 지시어를 사용해야 하는 중요한 이유는 세션으로 인해 프레임셋 관련 문제가 생길 수 있기 때문입니다. ASP를 사용하면 세션으로부터 발생하는 요청이 한 번에 하나씩만 실행되도록 만들 수 있습니다. 따라서 브라우저가 한 명의 사용자에 대해 여러 개의 페이지를 요청하더라도 한 번에 한 개의 ASP 요청만 세션을 사용하게 되므로, 세션 개체에 액세스할 때 다중 스레드 문제가 유발되지 않습니다. 결과적으로 볼 때, 프레임셋에 있는 모든 페이지는 동시에 표시되는 것이 아니라 순차적으로 한 번에 하나씩 표시됩니다. 모든 프레임이 표시될 때까지 사용자가 장시간 기다려야 할 경우도 있습니다. 참고: 특정 프레임셋 페이지가 세션에 대한 신뢰를 가지고 있지 않은 경우에는 @EnableSessionState=False 지시어를 사용하여 반드시 ASP에게 알려야 합니다. 

세션 개체를 사용하는 대신, 세션 상태 관리용으로 제공되는 많은 수의 옵션들을 사용할 수도 있습니다. 상태의 크기가 4KB 미만으로 작은 경우에는 일반적으로 쿠키, QueryString 변수 및 숨겨진 서식 변수를 사용하는 것이 좋습니다. 쇼핑 카트와 같이 데이터 크기가 큰 경우에는 백엔드 데이터베이스를 사용하는 것이 가장 좋습니다. 웹 서버 그룹에는 상태 관리 기술에 대한 많은 정보들이 들어 있습니다. 자세한 내용은 세션 상태 설명서를 참조하십시오.

 

7. 코드를 COM 개체에 캡슐화하십시오. 

VBScript 또는 JScript가 매우 많은 경우, 간혹 그 코드를 컴파일된 COM 개체로 옮기면 성능을 개선할 수 있습니다. 컴파일된 코드의 실행 속도는 보통, 해석된 코드의 실행 속도보다 빠릅니다. 컴파일된 COM 개체는 스크립트에 사용된 "후기 바인딩"이 아니라, 보다 효과적으로 COM 개체 메서드를 불러오는 "초기 바인딩"을 통해 다른 COM 개체에 액세스할 수 있습니다. 

성능 측면 뿐만 아니라, 코드를 COM 개체에 캡슐화하면 다음과 같은 장점도 얻을 수 있습니다. 

COM 개체는 비즈니스 로직으로부터 표현 로직을 분리하는 성능이 매우 우수합니다. 

COM 개체는 코드 재사용을 가능케 합니다. 

대부분의 개발자들은 VB, C++ 또는 Visual J++로 작성된 코드가 ASP로 작성된 코드보다 디버깅하기 쉽다는 점을 알고 있습니다. 

COM 개체는 초기 개발 기간이 길고 다양한 프로그래밍 기술을 필요로 한다는 단점들을 가지고 있습니다. 작은 양의 ASP를 캡슐화하면 성능상 얻을 수 있는 장점보다는 단점이 많을 수 있다는 점에 주의하십시오. 일반적으로 이러한 상황은 작은 양의 ASP 코드가 COM 개체에 포함될 때 발생합니다. 이러한 경우에는 컴파일된 코드를 통해 얻을 수 있는 장점보다 COM 개체를 만들어 불러오는데 걸리는 오버헤드로 인한 단점이 더 많습니다. 어떤 방식으로 ASP 스크립트와 COM 개체 코드를 결합할 때 최적의 성능을 얻을 수 있는지를 판별하려면 여러 번의 시행 착오를 거쳐야 합니다. Microsoft는 Windows NT� 4.0/IIS 4.0에 비해 Windows 2000/IIS 5.0의 스크립트와 ADO 성능을 다양하게 개선했습니다. 따라서 ASP 코드에 비해 컴파일된 코드를 통해 얻을 수 있는 성능상의 장점들은 IIS 5.0의 도입과 함께 줄어들었습니다. 

COM 개체를 ASP에 사용함으로써 발생하는 장단점에 대한 자세한 내용은 ASP Component Guidelines and Programming Distributed Applications with COM and Microsoft Visual Basic 6.0을 참조하십시오. COM 구성 요소를 구축하는 경우에는 반드시 스트레스 테스트를 수행해야 합니다. 실제로 모든 ASP 응용 프로그램들은 당연히 스트레스 테스트를 거쳐야 합니다.

 

8. 최신의 리소스를 얻어 신속하게 릴리스하십시오. 

일반적으로 최신의 리소스를 얻어 신속하게 릴리스하는 것이 좋습니다. 이러한 팁은 파일 핸들 및 기타 리소스 뿐만 아니라 COM 개체에도 적용됩니다. 

ADO 연결 및 레코드 집합이 이러한 최적화에 가장 적합합니다. 레코드 집합을 사용하는 경우, 그 데이터를 사용하여 테이블을 채운 후 페이지 끝에 도달할 때까지 기다리지 말고 즉시 릴리스하십시오. VBScript 변수는 Nothing으로 설정하는 것이 가장 좋습니다. 레코드 집합이 범위를 벗어나지 않게 하십시오. 또한 관련된 모든 명령 또는 연결 개체를 릴리스하십시오. = Nothing으로 설정하기 전에 레코드 집합 또는 연결에 대해 Close()를 호출하는 것을 잊지 마십시오. 그러면 데이터베이스에서 리소스를 저글링하는 기간이 단축되며 데이터베이스 연결이 최대한 빠르게 연결 풀에 릴리스됩니다.

 

9. 독립 프로세스 실행을 통해 성능과 안정성을 적절히 안배하십시오. 

ASP와 MTS/COM+에는 모두 성능과 안정성이 적절히 안배되도록 조정할 수 있는 구성 옵션들이 있습니다. 응용 프로그램을 만들고 구축할 때 그 장단점을 이해하고 있어야 합니다. 

ASP 옵션

세 가지 방법들 중 하나로 실행되도록 ASP 응용 프로그램을 구성할 수 있습니다. IIS 5.0에서는 이러한 옵션들에 대해 설명할 목적으로 "격리 수준(isolation level)"이라는 용어를 도입했습니다. 격리 수준 값에는 낮음, 보통 및 높음의 세 가지가 있습니다. 

낮음 격리. 모든 IIS 버전에서 지원되며 속도가 가장 빠릅니다. 낮음 격리는 Inetinfo.exe로 ASP를 실행하는데, 이는 기본 IIS 프로세스입니다. ASP 응용 프로그램의 작동이 중단되면 IIS의 작동도 중단됩니다. IIS 4.0의 경우, IIS를 다시 시작하려면 웹 마스터가 InetMon 등과 같은 도구들을 사용하여 사이트를 모니터하고 서버 오류가 발생한 경우 배치 파일을 실행하여 서버를 다시 시작해야 합니다. IIS 5.0에서는 오류가 발생한 서버를 자동으로 다시 시작하는 안정적인 재시작 기능을 도입했습니다. 

보통 격리. IIS 5.0에서 새로 도입된 이러한 보통 격리 수준은 ASP가 IIS 프로세스와는 별도로 실행되므로 독립 프로세스라고도 불립니다. 보통 격리에서 보통으로 실행되도록 구성된 모든 ASP 응용 프로그램은 하나의 프로세스 공간을 공유합니다. 따라서 한 개의 상자에서 여러 개의 독립 프로세스 ASP 응용 프로그램을 실행하는데 필요한 프로세스의 수가 줄어듭니다. 보통은 IIS 5.0의 기본 격리 수준입니다. 

높음 격리. IIS 4.0 및 IIS 5.0에서 지원되는 높음 격리도 역시 독립 프로세스입니다. ASP 작동이 중단되더라도 웹 서버 작동은 중단되지 않습니다. 다음 번 ASP 요청이 발생하면 ASP 응용 프로그램이 자동으로 다시 시작됩니다. 높음 격리를 사용하면, 높음으로 실행되도록 구성된 각각의 ASP 응용 프로그램은 자체 프로세스 공간에서 실행됩니다. 따라서 ASP 응용 프로그램들이 상호 보호됩니다. 하지만 각각의 ASP 응용 프로그램마다 별도의 프로세스를 필요로 한다는 단점이 있습니다. 이러한 단점 때문에, 하나의 컴퓨터에 많은 수의 응용 프로그램들을 호스트해야 할 경우에는 엄청난 오버헤드가 생길 수 있습니다. 

최상의 옵션은 무엇입니까? IIS 4.0에는 독립 프로세스를 실행하기에 좋지 않은 성능상의 단점들이 있습니다. IIS 5.0에서는 ASP 응용 프로그램을 독립 프로세스로 실행하는데 드는 비용을 최소화하기 위한 많은 작업들이 수행되었습니다. 실제로 대부분의 테스트를 거친 결과, IIS 5.0의 ASP 독립 프로세스 응용 프로그램이 IIS 4.0의 종속 프로세스 응용 프로그램보다 빠르게 실행되었습니다. 그럼에도 불구하고 종속 프로세스(낮음 격리 수준)는 두 플랫폼 모두에서 여전히 최상의 성능을 제공합니다. 그러나 상대적으로 방문 횟수가 적거나 최대 처리량이 낮은 경우에는 낮음 격리 수준을 통해 얻을 수 있는 장점들이 그다지 많지 않습니다. 따라서 각각의 웹 서버에서 1초에 수 백개 또는 수 천개의 페이지를 필요로 할 때까지는 낮음 격리 수준으로 설정할 필요성을 느끼지 못할 것입니다. 또한 다양한 구성들을 사용하여 테스트를 수행하고 그 장단점을 판별해야 합니다. 

참고 ASP 응용 프로그램을 독립 프로세스(보통 또는 높음 격리)로 실행하면 ASP 응용 프로그램은 Windows NT4의 경우 MTS에서 실행되고 Windows의 경우 COM+에서 실행됩니다. 즉, Windows NT4의 경우 Mtx.exe로 실행되고 Windows 2000의 경우 DllHost.exe로 실행됩니다. 작업 관리자를 살펴보면 이러한 프로세스의 실행 여부를 알 수 있습니다. 또한 IIS가 MTS 패키지 또는 COM+ 응용 프로그램을 ASP 독립 프로세스 응용 프로그램용으로 구성하는 방법도 알 수 있습니다. 

COM 옵션

ASP 옵션과 완전히 유사하지는 않지만, COM 구성 요소도 세 가지 구성 옵션들을 가지고 있습니다. COM 구성 요소는 "구성되지 않은" 구성 요소이거나 라이브러리 응용 프로그램으로서 구성된 구성 요소이거나 서버 응용 프로그램으로서 구성된 구성 요소입니다. 구성되지 않은 구성 요소는 COM+에 등록되지 않은 구성 요소를 의미합니다. 이러한 구성 요소는 호출자의 프로세스 공간에서 실행되므로 "종속 프로세스"입니다. 라이브러리 응용 프로그램도 종속 프로세스이지만 보안, 트랜잭션 및 컨텍스트 지원 등을 포함하여 COM+ 서비스의 장점을 활용합니다. 서버 응용 프로그램은 자체 프로세스 공간에서 실행되도록 구성됩니다. 

라이브러리 응용 프로그램에 비해 구성되지 않은 구성 요소를 사용하여 얻을 수 있는 장점이 약간 더 많다는 사실을 알 수 있습니다. 또한 서버 응용 프로그램에 비해 라이브러리 응용 프로그램을 사용하여 얻을 수 있는 성능상의 장점이 훨씬 많다는 사실도 알 수 있습니다. 그 이유는 라이브러리 응용 프로그램이 ASP와 동일한 프로세스에서 실행되는 반면에 서버 응용 프로그램은 자체 프로세스에서 실행되기 때문입니다. 프로세스간 호출은 종속 프로세스 호출보다 더 부담이 큽니다. 또한 레코드 집합 등과 같은 데이터가 프로세스 사이에서 전달될 때에는 모든 데이터가 두 프로세스 사이에서 복사되어야 합니다. 

주의! COM 서버 응용 프로그램을 사용할 때, ASP와 COM 사이에서 개체를 전달하는 경우에는 개체가 "값에 따른 마셜링" 또는 MBV를 구현해야 합니다. MBV를 구현하는 개체들은 하나의 프로세스에서 다른 프로세스로 자동 복사됩니다. 이러한 방식은 개체가 작성자의 프로세스에 그대로 남아 있으며 다른 프로세스가 개체를 사용하기 위해 작성 프로세스에 반복적으로 호출되는 방식보다 낫습니다. 연결이 끊긴 ADO 레코드 집합은 값에 따라 마셜링되지만, 연결된 레코드 집합은 그렇지 않습니다. Scripting.Dictionary는 MBV를 구현하지 않으며 프로세스 사이에서 전달되지 않습니다. 끝으로, VB 프로그래머는 MBV가 ByVal 매개 변수의 전달을 통해 구현되는 것이 아니라, 원래의 구성 요소 작성자에 의해 구현된다는 점에 주의해야 합니다. 

수행할 사항

성능과 안정성이 적절히 조정된 구성을 설정하려면 다음과 같은 권장 사항들을 수행해야 합니다. 

IIS 4.0에서는 ASP의 낮음 격리 수준을 사용하고 MTS 서버 패키지를 사용하십시오. 

IIS 5.0에서는 ASP의 보통 격리 수준을 사용하고 COM+ 라이브러리 응용 프로그램을 사용하십시오. 

이 권장 사항들은 매우 일반적인 지침들입니다. 기업 호스팅에서는 일반적으로 ASP가 보통 또는 높음 격리 수준에서 실행되는 반면에 단일 용도의 웹 서버는 낮음 격리 수준에서 실행될 수 있습니다. 그 장단점을 평가하여 어떤 구성이 자신의 환경에 맞는지를 스스로 판별하십시오.

 

10. Option Explicit를 사용하십시오. 

.asp 파일에 있는 Option Explicit를 사용하십시오. .asp 파일의 맨 위에 있는 이 지시어는 사용할 변수를 모두 선언하도록 개발자에게 강요합니다. 응용 프로그램을 디버깅할 때 이 지시어를 사용하면 MyXMLString= 대신에 MyXLMString=가 발생하는 경우처럼 변수 이름의 입력 오타가 생기거나 원치 않는 변수가 만들어질 가능성을 봉쇄하기 때문에, 대부분의 프로그래머들은 이 지시어가 매우 유용하다는 것을 알고 있습니다. 

보다 중요한 점은 선언된 변수가 선언되지 않은 변수보다 빠르게 실행된다는 것입니다. 스크립팅 실행 시간은 선언되지 않은 변수가 사용될 때마다 자동으로 변수 이름별로 그 선언되지 않은 변수를 참조합니다. 반면, 선언된 변수는 컴파일 시간 또는 실행 시간에서 서수를 할당받습니다. 결과적으로 볼 때, 선언된 변수는 이 서수에서 참조합니다. Option Explicit를 사용하면 변수를 선언하도록 강제 지정하므로, 모든 변수가 선언되어 빠른 액세스를 가능하게 합니다.