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


목 차

1. 자주 사용되는 데이터는 웹 서버에 캐시하십시오.
2. 자주 사용되는 데이터는 응용 프로그램이나 세션 개체에 캐시하십시오.
3. 데이터 및 HTML은 웹 서버 디스크에 캐시하십시오.
4. 비 agile 구성 요소는 응용 프로그램이나 세션 개체에 캐시하지 마십시오.
5. 데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마십시오.
6. 세션 개체를 올바르게 사용하십시오.
7. 코드를 COM 개체에 캡슐화하십시오.
8. 최신의 리소스를 얻어 신속하게 릴리스하십시오.
9. 독립 프로세스 실행을 통해 성능과 안정성을 적절히 안배하십시오.
10. Option Explicit를 사용하십시오.
11. 로컬 변수를 하위 루틴 및 함수에 사용하십시오.
12. 자주 사용되는 데이터를 스크립트 변수에 복사하십시오.
13. 배열 크기 재정의를 피하십시오.
14. 응답 버퍼링을 사용하십시오.
15. 인라인 스크립트 및 Response.Write 명령문을 일괄 처리하십시오.
16. 실행 시간이 긴 페이지를 만들 때 Response.IsClientConnected를 사용하십시오.
17. 태그를 사용하여 개체를 초기화하십시오.
18. TypeLib 바인딩을 ADO 및 기타 구성 요소에 사용하십시오.
19. 브라우저의 유효성 검사 기능을 활용하십시오.
20. 루프 형식의 문자열 연결을 피하십시오.
21. 브라우저 및 프록시 캐싱을 사용하십시오.
22. 가능하면 Response.Redirect가 아닌 Server.TRansfer를 사용하십시오.
23. 디렉터리 URL에 후행 슬래시를 사용하십시오.
24. 서버 변수 사용을 피하십시오.
25. 최신 구성 요소로 업그레이드하십시오.
26. 웹 서버를 조정하십시오.
27. 성능 테스트를 수행하십시오.
28. 관련 리소스 링크를 읽어보십시오.

Len Cardinal, 선임 컨설턴트, Microsoft Consulting Services
George V. Reilly, Microsoft IIS Performance Lead

Nancy Cluts가 작성한 기사에서 발췌
개발자 기술 엔지니어
Microsoft Corporation

소 개
성능은 일종의 기능입니다. 성능은 장래 환경에 맞게 설계해야 하며, 그렇지 않으면 나중에 응용 프로그램을 다시 작성해야 하는 일이 생길 수 있습니다. 즉, 'Active Server Pages(ASP) 응용 프로그램의 성능을 최적화하려면 어떤 전략이 좋지?'와 같은 의문이 발생하게 됩니다.

이 기사에서는 ASP 응용 프로그램과 Visual Basic® Scripting Edition(VBScript)을 최적화하는데 도움이 되는 팁을 제공하며 수많은 위험과 곤란한 문제에 대해서도 논의합니다. 이 기사에 나열된 제안 사항들은 http://www.microsoft.com 및 그외 다른 사이트에서 테스트를 거쳤으며 올바르게 작동합니다. 이 기사에서는 VBScript 및/또는 JScript, ASP 응용 프로그램, ASP 세션, 기타 ASP 고유 개체(요청, 응답 및 서버) 등을 포함하여 ASP 개발에 대한 기본 사항들을 이해하고 있다고 가정합니다.

ASP 코드 자체 이외의 다른 요소들에 의해 ASP 성능이 달라지는 경우가 간혹 있습니다. 이 기사에서 미처 다루지 못한 사항들에 대해서는 뒷부분의 성능 관련 리소스를 참조하십시오. 뒷부분에 나열된 링크에서는 ActiveX® Data Objects(ADO), Component Object Model(COM), 데이터베이스 및 Internet Information Server(IIS) 구성 등을 포함하여 ASP와 비 ASP 항목에 대해 설명합니다. 이러한 링크들은 Microsoft가 즐겨 찾는 링크들이므로 반드시 참조하시기 바랍니다.



1. 자주 사용되는 데이터는 웹 서버에 캐시하십시오
일반적인 ASP 페이지는 백엔드 데이터 저장소에 있는 데이터를 검색한 후 그 결과를 HTML(Hypertext Markup Language) 형식으로 표시합니다. 데이터베이스 속도에 상관없이, 메모리에 있는 데이터를 검색하는 속도는 백엔드 데이터 저장소에 있는 데이터를 검색하는 속도보다 훨씬 빠릅니다. 또한 로컬 하드 디스크에 있는 데이터를 읽는 속도도 데이터베이스에 있는 데이터를 검색하는 속도보다 빠른 것이 보통입니다. 따라서 데이터를 웹 서버의 메모리나 디스크에 캐시하면 일반적으로 성능이 향상됩니다.

캐싱은 전형적으로 속도 향상을 위해 공간을 희생시키는 작업입니다. 캐시 기능을 올바르게 사용하면 성능이 놀랄 만큼 향상되는 것을 볼 수 있습니다. 효과적인 캐시를 위해서는 자주 사용되는 데이터이면서 다시 연산하기에는 부담이 큰 데이터만 캐시에 보관해야 합니다. 사용 빈도가 낮은 데이터로 캐시를 가득 채우면 메모리가 낭비되는 결과를 낳게 됩니다.

자주 변경되지 않는 데이터는 시간이 지나더라도 데이터베이스에 동기화할 필요가 없으므로 캐시하는 것이 좋습니다. 콤보 상자 목록, 참조 테이블, DHTML 스크랩, XML(Extensible Markup Language) 문자열, 메뉴 항목과 데이터 원본 이름(DSN), 인터넷 프로토콜(IP) 주소 및 웹 경로를 포함하는 사이트 구성 변수 등은 캐시하는 것이 좋습니다. 데이터 자체를 캐시하는 대신에 데이터에 대한 표현을 캐시할 수도 있다는 점에 주목하십시오. 전체 제품 카탈로그와 같이 ASP 페이지가 자주 변경되고 캐시하기에 부담이 큰 경우에는 요청이 발생할 때마다 해당 ASP 페이지를 다시 표시하는 것이 아니라 미리 HTML을 생성하는 방법을 고려해 보십시오.

데이터는 어디에 캐시되어야 하며 캐싱 전략에는 어떠한 것들이 있습니까? 데이터는 간혹 웹 서버의 메모리 또는 디스크에 캐시됩니다. 다음 두 가지 팁에서는 이러한 옵션들에 대해 설명합니다.


2. 자주 사용되는 데이터는 응용 프로그램이나 세션 개체에 캐시하십시오.
ASP 응용 프로그램 및 세션 개체는 데이터를 메모리에 캐시하는 편리한 컨테이너를 제공합니다. 데이터는 응용 프로그램과 세션 개체에 모두 지정될 수 있으며 이렇게 지정된 데이터는 새로운 HTTP 호출이 발생할 때까지 메모리에 그대로 남아 있습니다. 세션 데이터는 각 사용자별로 저장되지만 응용 프로그램 데이터는 모든 사용자들 사이에서 공유됩니다.

데이터는 응용 프로그램이나 세션에 언제 로드됩니까? 데이터는 간혹 응용 프로그램이나 세션이 시작될 때 로드됩니다. 응용 프로그램이나 세션을 시작하면서 데이터를 로드하려면 적당한 코드를 Application_OnStart() 또는 Session_OnStart()에 각각 추가하십시오. 이러한 함수들은 Global.asa에 들어 있으며, 그렇지 않다면 이러한 함수들을 직접 추가할 수 있습니다. 또한 처음 데이터를 필요로 할 때 해당 데이터를 로드할 수도 있습니다. 이렇게 하려면 데이터가 있는지 검사하여 데이터가 없으면 데이터를 로드하는 일부 코드를 ASP 페이지에 추가하거나 재사용 가능한 스크립트 함수를 만드십시오. 다음은 지연 평가(Lazy Evaluation)라는 고전적인 성능 기술에 대한 예로, 필요할 때만 이를 사용하십시오.

<%
Function GetEmploymentStatusList
Dim d
d = Application(?EmploymentStatusList?)
If d = ??Then
' FetchEmploymentStatusList function (not shown)
' fetches data from DB, returns an Array
d = FetchEmploymentStatusList()
Application(?EmploymentStatusList?)= d
End If
GetEmploymentStatusList = d
End Function
%>

각각의 필요한 데이터에 대해 이와 유사한 함수를 작성할 수 있습니다.

데이터는 어떤 형식으로 저장됩니까? 모든 스크립트 변수는 변형이기 때문에, 모든 변형 유형이 저장 가능합니다. 예를 들어, 문자열, 정수 또는 배열을 저장할 수 있습니다. 간혹 ADO 레코드 집합의 내용을 이러한 변형 유형들 중 하나로 저장할 수 있습니다. ADO 레코드 집합의 데이터를 꺼내기 위해 데이터를 VBScript 변수에 한 번에 하나의 필드씩 수동으로 복사할 수 있습니다. ADO 레코드 집합 지속성 함수인 GeTRows(), GetSTRing() 또는 Save()(ADO 2.5) 중 하나를 사용하면 복사가 더 빠르고 편리해집니다. 이 기사에서는 자세한 세부 정보는 제공하지 않습니다. 다음은 GeTRows()를 사용하여 레코드 집합 데이터 배열을 반환하는 함수의 예입니다.

' Get Recordset, return as an Array
Function FetchEmploymentStatusList
Dim rs 
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GeTRows() ?Return data as an Array
rs.Close
Set rs = Nothing
End Function

배열이 아닌, 목록에 대한 HTML을 캐시하도록 위 예제를 변경할 수도 있습니다. 다음은 그에 대한 간단한 예입니다.

' Get Recordset, return as HTML Option list
Function FetchEmploymentStatusList
Dim rs, fldName, s
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?select StatusName, StatusID from EmployeeStatus?, _
?dsn=employees;uid=sa;pwd=;?
s = ?<select name=??EmploymentStatus??>?& vbCrLf
Set fldName = rs.Fields(?StatusName?)' ADO Field Binding
Do Until rs.EOF
' Next line violates Don't Do STRing Concats,
' but it's OK because we are building a cache
s = s & ? <option>?& fldName & ?</option>?& vbCrLf
rs.MoveNext
Loop
s = s & ?</select>?& vbCrLf
rs.Close
Set rs = Nothing ' See Release Early
FetchEmploymentStatusList = s ' Return data as a STRing
End Function

올바른 조건 하에서는 ADO 레코드 집합 자체를 응용 프로그램이나 세션 범위에 캐시할 수 있습니다. 이 때 다음 두 가지를 고려해야 합니다.

• ADO는 빈 스레드로 표시되어야 합니다.
• 연결이 끊긴 레코드 집합을 사용해야 합니다.

이 두 가지 요구 사항이 충족된다고 보증할 수 없으면 ADO 레코드 집합을 캐시하지 마십시오. 아래의 팁 4(비 Agile 구성 요소는 응용 프로그램이나 세션 개체에 캐시하지 마십시오)와 팁 5(데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마십시오)에서는 COM 개체를 응용 프로그램이나 세션 범위에 저장할 때 발생할 수 있는 위험에 대해 설명합니다.

데이터를 응용 프로그램이나 세션 범위에 저장하면, 프로그램을 통해 변경되거나 세션이 만료되거나 웹 응용 프로그램이 다시 시작될 때까지 데이터가 그대로 남아 있습니다. 데이터를 업데이트해야 할 경우에는 어떻게 할까요? 응용 프로그램 데이터의 업데이트를 강제로 수행하도록 지정하려면 데이터를 업데이트하는 관리자 액세스 전용 ASP 페이지로 호출할 수 있습니다. 또한 함수를 사용하여 정기적으로 데이터를 자동으로 새로 고치는 방법도 사용할 수 있습니다. 다음 예에서는 캐시된 데이터와 함께 시간 스탬프를 저장하고 일정 기간이 경과한 후 데이터를 새로 고칩니다.

<%
' error handing not shown...
Const UPDATE_INTERVAL = 300 ' Refresh interval, in seconds

' Function to return the employment status list
Function GetEmploymentStatusList
UpdateEmploymentStatus
GetEmploymentStatusList = Application(?EmploymentStatusList?)
End Function

' Periodically update the cached data
Sub UpdateEmploymentStatusList
Dim d, sTRLastUpdate
sTRLastUpdate = Application(?LastUpdate?)
If (sTRLastUpdate = ??)Or _
(UPDATE_INTERVAL < DateDiff(?s?, sTRLastUpdate, Now)) Then

' Note: two or more calls might get in here.This is okay and will simply
' result in a few unnecessary fetches (there is a workaround for this)

' FetchEmploymentStatusList function (not shown)
' fetches data from DB, returns an Array
d = FetchEmploymentStatusList()

' Update the Application object.Use Application.Lock()
' to ensure consistent data
Application.Lock
Application(?EmploymentStatusList?) = Events
Application(?LastUpdate?) = CSTR(Now)
Application.Unlock
End If
End Sub

다른 예를 보려면 World's Fastest ListBox with Application Data를 참조하십시오.

세션 또는 응용 프로그램 개체에 큰 배열을 캐싱하는 것은 좋지 않습니다. 스크립트 언어의 기능(Semantics)을 사용하려면 배열 요소에 액세스하기 전에 전체 배열을 임시로 복사해야 합니다. 예를 들어, 100,000개의 요소를 가지고 있으며 미국 우편 번호를 지방 기상청으로 매핑하는 문자열 배열을 응용 프로그램 개체에 캐시하는 경우, ASP는 그 중 하나의 문자열을 추출하기 전에 먼저 100,000개의 모든 기상청을 임시 배열에 복사합니다. 이 경우, 사용자 정의 메서드를 통해 사용자 정의 구성 요소를 작성하여 기상청을 저장하는 것이 보다 나은 방법입니다. 그렇지 않으면 딕셔너리 구성 요소들 중 하나를 사용하십시오.

주의를 상기시키는 의미에서 한 가지 더 언급하자면, 배열은 메모리 내에서 서로 인접해 있는 키 데이터 쌍에 대한 빠른 조회 및 저장 성능을 제공한다는 점을 고려해야 합니다. 딕셔너리 인덱싱 속도는 배열 인덱싱 속도보다 느립니다. 자신의 환경에 맞게 최적의 성능을 제공하는 데이터 구조를 선택해야 합니다.


3. 데이터 및 HTML은 웹 서버 디스크에 캐시하십시오.
간혹 데이터가 너무 많아서 메모리에 캐시할 수 없는 경우가 생길 수도 있습니다. "데이터가 너무 많다"는 의미는 상황에 따라, 즉 사용할 메모리의 양과 캐시할 항목의 수 및 그 검색 빈도에 따라 다를 수 있습니다. 메모리에 캐시할 데이터가 너무 많은 경우에는 데이터를 텍스트 또는 XML 파일 형식으로 웹 서버의 하드 디스크에 캐시하는 방법을 고려해 보십시오. 디스크 캐시 및 메모리 캐시를 결합하여 사이트에 맞는 최적의 데이터 캐싱 전략을 세울 수 있습니다.

단일 ASP 페이지의 성능을 평가할 때, 디스크에 있는 데이터를 검색하는 속도가 항상 데이터베이스에 있는 데이터를 검색하는 속도보다 빠른 것은 아니라는 점에 주의하십시오. 하지만 캐싱을 수행하면 데이터베이스와 네트워크에 걸리는 로드가 줄어듭니다. 로드가 큰 경우, 캐싱을 수행하면 전체 처리량을 크게 개선할 수 있습니다. 다중 테이블 조인 또는 복잡한 저장 프로시저 등과 같이 부담이 큰 쿼리의 결과를 캐시하거나 대규모 결과 집합을 캐시하는 경우에는 캐싱이 매우 효과적입니다. 여느 때와 마찬가지로 여러 가지 가능성을 테스트해 보십시오.

ASP 및 COM은 디스크 기반 캐싱 구성표를 작성하는 다양한 도구를 제공합니다. ADO 레코드 집합인 Save() 및 Open() 함수는 레코드 집합을 디스크에 저장하고 디스크에 있는 레코드 집합을 로드합니다. 이러한 메서드를 사용하면 앞부분의 응용 프로그램 데이터 캐싱 팁에 있는 코드 예제를 다시 작성함으로써 Save()를 응용 프로그램 개체로 기록하는 코드용 파일로 대체할 수 있습니다.

다음은 파일에 사용되는 몇 가지 다른 구성 요소들입니다.

• Scripting.FileSystemObject를 사용하면 파일을 작성하거나 읽거나 기록할 수 있습니다.
• Internet Explorer와 함께 제공되는 Microsoft® XML 파서인 MSXML은 XML 문서의 저장 및 로딩을 지원합니다.
• MSN에서 사용되는 샘플인 LookupTable 개체는 디스크로부터 간단한 목록을 로드하는데 유용합니다.

끝으로, 데이터 자체가 아니라 디스크 상의 데이터에 대한 표현을 캐시하는 것도 고려해 보십시오. 미리 렌더링된 HTML은 .htm 또는 .asp 파일 형식으로 디스크에 저장될 수 있으며 하이퍼링크를 통해 해당 파일들을 직접 가리킬 수 있습니다. Xbuilder 또는 Microsoft® SQL Server™ 인터넷 게시 기능 등과 같은 상용 도구를 사용하여 HTML 생성 프로세스를 자동화할 수 있으며, 그 대신 HTML 내용 일부를 .asp 파일에 포함시킬 수도 있습니다. 또한 FileSystemObject를 사용하여 디스크에 있는 HTML 파일을 읽거나 초기 렌더링 과정에서 XML을 사용하는 것 역시 가능합니다.


4. 비 Agile 구성 요소는 응용 프로그램이나 세션 개체에 캐시하지 마십시오.
데이터를 응용 프로그램 또는 세션 개체에 캐시하는 것은 좋은 방법이지만, COM 개체를 응용 프로그램 또는 세션 개체에 캐시하면 곤란한 문제들이 유발될 수 있습니다. 간혹 자주 사용되는 COM 개체를 응용 프로그램 또는 세션 개체에 캐시해야 하는 경우가 발생합니다. 불행하게도, Visual Basic 6.0 이하에서 작성된 개체를 포함한 많은 수의 COM 개체들의 경우 응용 프로그램 또는 세션 개체에 저장하려고 하면 심각한 병목 현상이 생길 수 있습니다.

특히, 비 agile 구성 요소인 경우에는 세션 또는 응용 프로그램 개체에 캐시할 때 성능 병목 현상이 발생하게 됩니다. agile 구성 요소는 FTM(Free-Threaded Marshaler)을 집계하는 ThreadingModel=Both로 표시된 구성 요소이거나 ThreadingModel=NeuTRal로 표시된 구성 요소입니다. NeuTRal 모델은 Windows® 2000 및 COM+의 새로운 모델입니다. 다음은 비 agile 구성 요소입니다.

• FTM을 집계하지 않는 빈 스레드 구성 요소
• 공동(Apartment) 스레드 구성 요소
• 단일 스레드 구성 요소

중립 스레드가 아닌 한, Microsoft TRansaction Server(MTS)/COM+ 라이브러리 및 서버 패키지/응용 프로그램 등과 같은 구성된 구성 요소들은 비 agile입니다. 공동(Apartment) 스레드 구성 요소와 기타 비 agile 구성 요소들은 페이지 범위에서 가장 잘 작동합니다. 즉, 단일 ASP 페이지에서 만들어지고 제거됩니다.

IIS 4.0의 경우 ThreadingModel=Both로 표시된 구성 요소는 agile로 간주되지만, IIS 5.0에서는 그렇지 않습니다. 이러한 구성 요소들은 Both로 표시되어야 하며 FTM도 집계해야 합니다. agility 기사에서는 Active Template Library로 작성된 C++ 구성 요소들이 FTM을 집계하는 방법에 대해 설명합니다. 구성 요소가 인터페이스 포인터를 캐시하는 경우에는 이러한 포인터는 그 자체가 agile이어야 하거나 COM GIT(Global Interface Table)에 저장되어야 합니다. FTM을 집계하도록 Both 스레드 구성 요소를 다시 컴파일할 수 없는 경우에는 그 구성 요소를 ThreadingModel=NeuTRal로 표시할 수 있습니다. 또한 IIS가 agility 검사를 수행하지 않기를 원해서 비 agile 구성 요소를 응용 프로그램이나 세션 범위에 저장하려고 할 경우에는 메타베이스에서 AspTRackThreadingModel을 TRue로 설정할 수 있습니다. AspTRackThreadingModel을 변경하면 안됩니다.

IIS 5.0에서는 Server.CreateObject를 사용해서 만든 비 agile 구성 요소를 응용 프로그램 개체에 저장하려고 하면 오류 메시지가 나타납니다. Global.asa에서 <object runat=server scope=application ...>을 사용하면 이러한 문제를 해결할 수 있지만, 이 방법은 아래에 설명된 바와 같이 마샬링 및 순차화를 유발하므로 사용하지 않는 것이 좋습니다.

비 agile 구성 요소를 캐시하면 어떻게 될까요? 세션 개체에 캐시된 비 agile 구성 요소는 ASP 작업자 스레드에 대한 세션을 "잠급니다". ASP는 요청을 처리하는 작업자 스레드의 풀을 유지 관리합니다. 일반적으로 새 요청은 최초 사용 가능한 작업자 스레드에 의해 처리됩니다. 스레드에 대한 세션이 잠기는 경우, 해당 요청은 자신이 연결된 스레드를 사용할 수 있을 때까지 기다려야 합니다. 다음은 이를 이해하는데 도움이 될만한 유사한 사례입니다. 즉, 슈퍼마켓에 가서 몇 가지 식료품을 고른 후 3번 계산대에서 그 대금을 지불합니다. 그런 다음부터는 그 슈퍼마켓에서 산 식료품의 대금은 항상 3번 계산대에서 지불해야 합니다. 다른 계산대에서 기다리는 손님이 적거나 심지어 없는 경우에도 마찬가지입니다.

비 agile 구성 요소들을 응용 프로그램 범위에 저장하면 성능에 최악의 영향을 미치게 됩니다. ASP는 별도의 스레드를 만들어서 비 agile 응용 프로그램 범위 구성 요소들을 실행해야 합니다. 결과적으로, 모든 호출이 이 스레드에 대해 마셜링되어야 하거나 모든 호출이 순차화되어야 합니다. 마셜링은 매개 변수들이 메모리 공유 영역에 저장되어야 함을 의미합니다. 즉, 부담이 큰 컨텍스트 스위치가 별도의 스레드에 대해 만들어지고 구성 요소의 메서드가 실행되며, 그 결과가 공유 영역으로 마셜링되고 다른 부담이 큰 컨텍스트 스위치는 제어 권한을 원래의 스레드로 되돌려야 합니다. 순차화는 모드 메서드가 한 번에 하나씩 실행되어야 함을 의미합니다. 따라서 서로 다른 두 개의 ASP 작업자 스레드가 공유 구성 요소에서 메서드를 동시에 실행할 수 없으므로 동시성이 사라지게 되는데, 특히 다중 프로세서 컴퓨터에서 이러한 현상이 더 두드러집니다. 더군다나, 모든 비 agile 응용 프로그램으로 범위가 한정된 구성 요소들이 한 개의 스레드("Host STA")를 공유하므로 순차화의 영향이 더욱 커지게 됩니다.

이해가 잘 안되면 아래의 몇 가지 일반 규칙들을 살펴보십시오. Visual Basic 6.0 이전 버전을 사용해서 개체를 작성하고 있는 경우에는 그 개체를 응용 프로그램 또는 세션 개체에 캐시하면 안됩니다. 개체의 스레드 모델을 모른다면 그 개체를 캐시하면 안됩니다. 비 agile 개체는 캐시하지 말고 각각의 페이지에서 만든 후 릴리스하십시오. 개체는 마셜링 또는 순차화가 발생하지 않도록 ASP 작업자 스레드에서 직접 실행해야 합니다. IIS 상자에서 COM 개체를 실행하고 있는 경우와 그 COM 개체를 시작하거나 종료하는데 많은 시간이 걸리지 않는 경우에는 적절한 성능을 얻을 수 있습니다. 단, 단일 스레드 개체는 이와 동일한 방식으로 사용되지 않아야 한다는 점에 주의하십시오. VB는 단일 스레드 개체를 만들 수 있으므로 조심하십시오! Microsoft Excel 스프레드시트 등과 같은 단일 스레드 개체를 이와 동일한 방식으로 사용해야 하는 경우에는 많은 처리량을 기대할 수 없습니다.

ADO 레코드 집합은 ADO가 빈 스레드로 표시되어 있을 때 안전하게 캐시할 수 있습니다. ADO를 빈 스레드로 표시하려면 보통 \\Program Files\Common\System\ADO에 있는 Makfre15.bat 파일을 사용하면 됩니다.

경고 Microsoft Access를 데이터베이스로 사용하고 있는 경우에는 ADO를 빈 스레드로 표시하지 마십시오. 또한 ADO 레코드 집합에 대한 연결이 끊어져 있어야 합니다. 일반적으로, 자기 자신만의 고유한 구성을 관리하는 고객들에게 웹 응용 프로그램을 판매하는 독립 소프트웨어 공급업체[ISV]처럼 사이트에서 ADO 구성을 제어할 수 없는 경우에는 레코드 집합을 캐시하지 않는 것이 좋습니다.

또한 딕셔너리 구성 요소는 agile 개체입니다. LookupTable은 데이터 파일로부터 데이터를 로드하며 구성 정보 뿐만 아니라 콤보 상자 데이터에서도 유용하게 사용됩니다. Duwamish Books에 있는 PageCache 개체는 Caprock Dictionary와 마찬가지로 딕셔너리 기능(semantics)을 제공합니다. 이러한 개체들과 그 파생물들은 효과적인 캐싱 전략의 토대로 사용될 수 있습니다. Scripting.Dictionary 개체는 비 agile이므로 응용 프로그램이나 세션 범위에 저장될 수 없다는 점에 주의하십시오.


5. 데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마십시오.
보통 ADO 연결은 캐시하지 않는 것이 좋습니다. 하나의 연결 개체를 응용 프로그램 개체에 저장하여 모든 페이지에서 이를 사용하는 경우에는 모든 페이지가 이 연결을 사용하기 위해 경쟁하게 됩니다. 연결 개체가 ASP 세션 개체에 저장되어 있으면 모든 사용자들에 대해 데이터베이스 연결이 설정됩니다. 따라서 연결 풀링을 통해 얻을 수 있는 장점들이 줄어들며 웹 서버와 데이터베이스 모두에서 불필요하게 많은 로드가 발생하게 됩니다.

데이터베이스 연결을 캐시하지 말고 ADO를 사용하는 모든 ASP 페이지에서 ADO 개체를 만들거나 제거하십시오. 이렇게 하면 IIS가 자체적으로 데이터베이스 연결 풀링을 보유하게 되므로 효과적입니다. 더 정확히 말해서, IIS가 OLEDB 및 ODBC 연결 풀링을 자동으로 사용하게 되므로 각 페이지에서 연결을 효과적으로 만들거나 제거할 수 있게 됩니다.

연결된 레코드 집합은 데이터베이스 연결에 대한 참조를 저장하므로, 연결된 레코드 집합을 응용 프로그램 또는 세션 개체에 저장하면 안됩니다. 단, 연결이 끊긴 레코드 집합은 데이터 연결에 대한 참조를 저장하지 않으므로 안전하게 캐시할 수 있습니다. 레코드 집합의 연결을 끊으려면 다음과 같은 두 단계를 수행하십시오.

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' step 1

' Populate the recordset with data
rs.Open sTRQuery, sTRProv

' Now disconnect the recordset from the data provider and data source
rs.ActiveConnection = Nothing ' step 2

연결 풀링에 대한 자세한 내용은 ADO 및 SQL Server 설명서에 나와 있습니다.


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를 사용하면 변수를 선언하도록 강제 지정하므로, 모든 변수가 선언되어 빠른 액세스를 가능하게 합니다.

<% Option Explicit %>

11. 로컬 변수를 하위 루틴 및 함수에 사용하십시오.
로컬 변수는 하위 루틴 및 함수 내에서 선언된 변수입니다. 함수 또는 하위 루틴 내에서 선언된 로컬 변수는 글로벌 변수보다 빠르게 액세스됩니다. 또한 로컬 변수를 사용하면 코드가 보다 명확해지므로, 가능하면 항상 로컬 변수를 사용하십시오.


12. 자주 사용되는 데이터를 스크립트 변수에 복사하십시오.
ASP에 있는 COM 개체에 액세스할 때는 자주 사용되는 데이터를 스크립트 변수에 복사해야 합니다. 이렇게 복사하면 스크립트 변수에 액세스하는 것에 비해 상대적으로 부담이 큰 COM 메서드 호출의 수가 줄어듭니다. 컬렉션 및 딕셔너리 개체에 액세스할 때에도 이 기술을 사용하면 부담이 큰 조회의 수를 줄일 수 있습니다.

일반적으로 두 번 이상 개체 데이터에 액세스할 경우에는 해당 데이터를 스크립트 변수에 복사하십시오. 이러한 최적화의 주요 대상은 Request 변수(Form 및 QuerySTRing 변수)입니다. 예를 들어, QuerySTRing 변수로 호출되는 UserID가 반복적으로 분배되는 사이트에서 이 UserID가 특정 페이지에 12회 참조된다고 가정해 보십시오. Request(?UserID?)를 12회 호출하지 말고 ASP 페이지의 맨 위에 있는 변수에 UserID를 할당하십시오. 그러면 페이지 전체에 걸쳐 그 변수가 사용됩니다. 따라서 11회의 COM 메서드 호출이 줄어듭니다.

실제로 COM 속성 또는 메서드에 대한 액세스는 매우 부담이 큰 작업입니다. 다음은 자주 사용되는 구문 코드를 보여주는 예입니다.

Foo.bar.blah.baz = Foo.bar.blah.qaz(1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...

이 코드는 다음과 같이 실행됩니다.

1. Foo 변수가 글로벌 개체로 확인됩니다.
2. bar 변수가 Foo의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 발생합니다.
3. blah 변수가 Foo.bar의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 다시 발생합니다.
4. qaz 변수가 foo.bar.blah의 구성원으로 확인됩니다. 결과적으로 COM 메서드 호출이 다시 발생합니다.
5. Foo.bar.blah.quaz(1)를 불러옵니다. COM 메서드 호출이 다시 발생합니다. 여기까지 이해가 되었습니까?
6. 1-3 단계를 다시 수행하여 baz를 확인합니다. 시스템은 qaz 호출이 개체 모델을 변경했는지 여부를 알지 못하므로, 1-3 단계를 다시 수행하여 baz를 확인해야 합니다.
7. baz를 Foo.bar.blah의 구성원으로 확인합니다. 속성을 설정합니다.
8. 1-3 단계를 다시 수행하여 zaq를 확인합니다.
9. 1-3 단계를 다시 수행하여 abc를 확인합니다.

이처럼, 이 코드는 매우 비효율적이며 작성에 많은 시간이 걸립니다. VBScript에서 이 코드를 가장 빠르게 작성하는 방법은 다음과 같습니다.

Set myobj = Foo.bar.blah ' do the resolution of blah ONCE
Myobj.baz = myobj.qaz(1)
If Myobj.zaq = Myobj.abc Then '...

VBScript 5.0 이상을 사용하고 있는 경우에는 With 명령문을 사용하여 이 코드를 작성할 수 있습니다.

With Foo.bar.blah
.baz = .qaz(1)
If .zaq = .abc Then '...
...
End With

이 팁은 VB 프로그래밍에도 적용된다는 점을 기억하십시오.


13. 배열 크기 재정의를 피하십시오.
배열의 크기 재정의(Redim)는 가능한 한 피하십시오. 실제 메모리 크기에 의해 성능이 제한되는 컴퓨터의 경우에는 최악의 경우에 대비하여 초기 배열 크기를 설정하거나, 그 크기를 최적으로 설정하고 필요할 때마다 배열 크기를 재정의하십시오. 단, 필요하지 않은 경우에도 수 MB나 되는 메모리를 할당해야 한다는 것은 아닙니다.

다음 코드는 Dim 및 Redim 사용 예입니다.

<% 
Dim MyArray()
Redim MyArray(2)
MyArray(0) = ?hello?
MyArray(1) = ?good-bye?
MyArray(2) = ?farewell?
...
' some other code where you end up needing more space happens, then ...
Redim Preserve MyArray(5)
MyArray(3) = ?more stuff?
MyArray(4) = ?even more stuff?
MyArray(5) = ?yet more stuff?
%>

배열의 크기 재정의(Redim)를 수행하여 그 크기를 늘리는 것보다는 초기에 올바른 크기까지 배열의 크기 정의(Dim)를 수행(위 코드의 경우 5)하는 것이 좋습니다. 모든 요소들을 끝까지 사용하지 않으면 약간의 메모리 낭비가 있게 되지만 속도가 빨라지는 이점이 있습니다.


14. 응답 버퍼링을 사용하십시오.
"응답 버퍼링" 기능을 설정함으로써 전체 출력 페이지 만큼을 버퍼링할 수 있습니다. 이렇게 하면 브라우저에 기록되는 양이 최소화되어 전체 성능이 향상됩니다. 기록할 때마다 IIS 및 회선을 통해 보내지는 데이터 크기로 인한 오버헤드가 아주 크기 때문에, 기록 횟수가 줄어들수록 성능이 향상됩니다. TCP/IP는 느리게 시작되며 Nagling 알고리즘을 통해 네트워크 혼잡을 최소화하므로, 작은 블록을 여러 개 보낼 때보다 큰 데이터 블록을 한 개 보낼 때 더욱 효율적으로 작동합니다.

응답 버퍼링 기능을 설정하는 방법은 두 가지가 있습니다. 첫번째 방법은 인터넷 서비스 관리자를 사용하여 전체 응용 프로그램의 응답 버퍼링 기능을 설정하는 것입니다. 이는 권장되는 방법이며 기본적으로 IIS 4.0 및 IIS 5.0에서 새로 사용되는 ASP 응용 프로그램의 응답 버퍼링 기능을 설정합니다. 두번째 방법은 다음과 같은 코드 행을 ASP 페이지의 맨 위쪽에 넣음으로써 응답 버퍼링 기능을 페이지 단위로 설정하는 것입니다.

<% Response.Buffer = TRue %>

이 코드 행은 응답 데이터가 브라우저에 기록되기 이전에 미리 실행되어야 합니다. 즉, HTML이 ASP 스크립트에 나타나기 이전과 Response.Cookies 컬렉션을 사용하여 쿠키가 설정되기 이전에 미리 실행되어야 합니다. 일반적으로 전체 응용 프로그램에 대해 응답 버퍼링 기능을 설정하는 것이 좋습니다. 이렇게 하면 각 페이지마다 이 코드 행을 사용하지 않아도 됩니다.

Response.Flush

응답 버퍼링에 관한 일반적인 불만 사항들 중 하나는 전체 페이지가 생성된 후에야 비로소 그 내용을 볼 수 있기 때문에 전체 응답 시간이 향상되었음에도 불구하고 사용자들이 ASP 페이지의 응답이 다소 느리다고 느낀다는 점입니다. 페이지를 장시간 실행하는 경우에는 Response.Buffer = False를 설정함으로써 응답 버퍼링 기능을 해제할 수 있습니다. 그러나 Response.Flush 메서드를 활용하는 것이 더 낫습니다. 이 메서드를 사용하면 ASP가 브라우저에 표시한 모든 HTML이 플러시됩니다. 예를 들어, 1,000개의 행으로 구성된 테이블에서 100개의 행을 표시한 후 ASP는 Response.Flush를 호출하여 표시된 결과를 브라우저에 강제 지정할 수 있습니다. 이렇게 하면 나머지 행이 표시되기 전에 사용자는 처음 표시된 100개의 행을 볼 수 있습니다. 이 기술을 사용하면 데이터를 브라우저에 점차적으로 표시함과 동시에 응답 버퍼링 기능도 사용할 수 있는 최상의 환경을 만들 수 있습니다.

1,000개의 행으로 구성된 테이블을 사용하는 위의 예에서 종료 </table> 태그가 나타날 때까지는 대부분의 브라우저에서 테이블 표시를 시작할 수 없다는 점에 주의하십시오. 대상 브라우저가 지원되는지 확인하십시오. 이 문제를 해결하려면 행 수가 적은 여러 개의 테이블로 나누고 각각의 작은 테이블 다음에서 Response.Flush를 호출하십시오. 최신 버전의 Internet Explorer에서는 전체 내용을 다운로드하기 전에 테이블을 표시하며, 테이블 열 너비가 지정되어 있으면 Internet Explorer가 모든 셀 내용의 너비를 측정함으로써 열 너비를 계산하지 않기 때문에 훨씬 빠르게 표시됩니다.

응답 버퍼링에 관한 또 다른 일반적인 불만 사항은 큰 페이지를 생성할 때 매우 많은 서버 메모리가 사용될 수 있다는 점입니다. 큰 페이지 생성을 조정하는 것이 아니라, Response.Flush를 적절히 사용하면 이 문제 역시 해결할 수 있습니다.


15. 인라인 스크립트 및 Response.Write 명령문을 일괄 처리하십시오.
VBScript 구문 <% = 표현식 %>을 사용하면 "표현식" 값이 ASP 출력 스트림에 기록됩니다. 응답 버퍼링 기능이 해제되어 있는 경우, 이러한 각각의 명령문을 사용하면 데이터가 네트워크를 통해 여러 개의 작은 패킷 형태로 브라우저에 기록됩니다. 이 기록은 아주 느리게 진행됩니다. 또한 작은 양의 스크립트와 HTML을 보내면 스크립트 엔진과 HTML간 전환이 발생하여 결과적으로 성능이 저하됩니다. 이 경우에는 여러 개의 인접한 인라인 표현식들을 한 번의 Response.Write 호출로 바꾸십시오. 예를 들어, 아래의 예에서는 응답 스트림 쓰기 동작이 각각의 행에 있는 각 필드에 대해 한 번 발생하며 VBScript와 HTML간 전환이 각각의 행에 대해 여러 번 발생합니다.

<table>
<% For Each fld in rs.Fields %>
<th><% = fld.Name %></th>
<%
Next 
While Not rs.EOF
%>
<TR>
<% For Each fld in rs.Fields %>
<TD><% = fld.Value %></TD>
<% Next 
</TR>
<% rs.MoveNext 
Wend %>
</table>

보다 효율적인 아래의 코드에서는 응답 스트림 쓰기 동작이 각각의 행에 대해 한 번 발생합니다. 모든 코드는 한 개의 VBScript 블록 안에 포함됩니다.

<table>
<%
For each fld in rs.Fields
Response.Write (?<th>?& fld.Name & ?</th>?& vbCrLf)
Next
While Not rs.EOF
Response.Write (?<TR>?)
For Each fld in rs.Fields %>
Response.Write(?<TD>?& fld.Value & ?</TD>?& vbCrLf)
Next
Response.Write ?</TR>?
Wend
%>
</table>

이 팁은 응답 버퍼링 기능이 해제되어 있을 때 더욱 효율적입니다. 응답 버퍼링 기능을 설정한 후 Response.Write를 일괄 처리하여 성능이 향상되는지를 확인해 보는 것이 가장 좋습니다.

위의 예에서 테이블 본문을 구성하는 중첩된 루프(While Not rs.EOF...)는 제대로 구성된 GetSTRing 호출로 바꿀 수 있습니다.


16. 실행 시간이 긴 페이지를 만들 때 Response.IsClientConnected를 사용하십시오.
참을성이 없는 사용자라면 자신의 요청을 실행하기도 전에 미리 ASP 페이지를 포기해 버릴 수도 있습니다. 이러한 사용자들이 새로 고침을 누르거나 서버의 다른 페이지로 이동하면 새 요청이 ASP 요청 대기열의 맨 끝부분에 넣어지고 연결이 끊긴 요청이 대기열의 중간 부분에 넣어집니다. 이러한 상황은 서버에 과도한 로드가 걸려 있을 때 간혹 발생하는데, 이 경우 요청 대기열이 길어져서 더 많은 응답 시간이 소요되므로 문제가 더욱 악화됩니다. 사용자의 연결이 끊어지면 ASP 페이지를 실행할 지점이 없어집니다. 특히, 속도가 느리고 그 내용이 많은 ASP 페이지인 경우에는 더욱 그렇습니다. Response.IsClientConnected 속성을 사용하면 이러한 상황이 발생했는지를 검사할 수 있습니다. False가 반환되면 Response.End를 호출하여 나머지 페이지를 포기해야 합니다. 실제로 IIS 5.0에서는 이러한 절차를 코드화했습니다. 즉, 새 요청을 실행하려고 할 때마다 ASP는 해당 요청이 대기열에 있었던 기간을 검사합니다. 그 기간이 3초를 초과하는 경우, ASP는 클라이언트가 아직도 연결되어 있는지를 검사하여 클라이언트 연결이 끊어져 있으면 그 즉시 해당 요청을 종료합니다. 메타베이스에 있는 AspQueueConnectionTestTime 설정을 사용하면 이러한 시간 초과 값(3초)을 변경할 수 있습니다.

매우 긴 실행 시간을 필요로 하는 페이지가 있는 경우에는 간혹 Response.IsClientConnected를 검사해야 합니다. 응답 버퍼링 기능이 설정되어 있는 경우에는 가끔 Response.Flush를 실행하여 무슨 일이 진행되고 있는지를 사용자에게 알리는 것이 좋습니다.

참고 IIS 4.0에서는 Response.Write를 먼저 실행하지 않으면 Response.IsClientConnected가 제대로 작동하지 않습니다. 또한 버퍼링 기능이 설정되어 있으면 Response.Flush도 실행해야 합니다. IIS 5.0에서는 이들을 실행하지 않더라도 Response.IsClientConnected가 제대로 작동합니다. Response.IsClientConnected를 실행하는데 어느 정도의 대가가 따를 수도 있으므로, Response.IsClientConnected는 500밀리초 이상이 소요되는 작업을 수행하기 전에만 사용해야 합니다. 1초에 수 십개의 페이지를 계속 처리해야 한다는 점에서 보면 500밀리초는 매우 긴 시간입니다. 일반적으로 20개 또는 50개의 테이블 행에 도달할 때마다 테이블 행을 표시하는 경우처럼, 간격이 짧은 루프가 반복될 때 이 속성을 호출하면 안됩니다.


17. <OBJECT> 태그를 사용하여 개체를 초기화하십시오.
모든 코드 경로, 특히 서버 또는 응용 프로그램 범위 개체에 사용되지 않는 개체를 참조해야 할 경우에는 Server.CreateObject 메서드를 사용하지 말고 Global.asa에서 <object runat=server id=objname> 태그를 사용하여 선언하십시오. Server.CreateObject는 즉시 개체를 만들기 때문에, 나중에 그 개체를 사용하지 않을 경우에는 리소스를 낭비하는 결과를 초래합니다. <object id=objname> 태그는 개체 이름(objname)을 선언하지만, 그 개체 이름은 해당 메서드나 속성들 중 하나가 처음으로 사용된 후 비로소 만들어집니다.

이것은 지연 평가(Lazy Evaluation)의 다른 예입니다.


18. TypeLib 선언을 ADO 및 그 밖의 다른 구성 요소에 사용하십시오.
ADO를 사용할 때, 개발자가 ADO의 다양한 상수들에 액세스할 목적으로 adovbs.txt를 포함시키는 경우가 간혹 있습니다. 이 파일은 상수가 사용될 모든 페이지에 포함되어야 합니다. 이 상수 파일의 크기는 매우 크기 때문에, 모든 ASP 페이지의 컴파일 시간 및 스크립트 크기에 엄청난 오버헤드가 추가됩니다.

IIS 5.0에는 구성 요소의 유형 라이브러리에 대한 바인드 기능이 새로 추가되었습니다. 이 기능을 사용하면 일단 유형 라이브러리를 참조한 이후에 모든 ASP 페이지에서 이를 다시 사용할 수 있습니다. 페이지마다 상수 파일을 컴파일할 필요는 없으므로, 구성 요소 개발자는 ASP에서 사용할 VBScript #include 파일을 만들 필요가 없습니다.

ADO TypeLib에 액세스하려면 다음 명령문들 중 하나를 Global.asa에 넣으십시오.

<!-- METADATA NAME=?Microsoft ActiveX Data Objects 2.5 Library? 
TYPE=?TypeLib?UUID=?{00000205-0000-0010-8000-00AA006D2EA4}? -->

또는

<!-- METADATA TYPE=?TypeLib? 
FILE=?C:\Program Files\Common Files\system\ado\msado15.dll? -->

19. 브라우저의 유효성 검사 기능을 활용하십시오.
최근에 개발되는 브라우저에서는 XML, DHTML, Java 애플릿 및 원격 데이터 서비스 등과 같은 기능들에 대한 고급 지원 기능을 제공합니다. 가능하면 항상 이러한 기능들을 사용하십시오. 이러한 모든 기술들은 데이터 캐싱 뿐만 아니라 클라이언트측 유효성 검사를 수행하므로 웹 서버에 대한 왕복 이동 시간을 줄여줍니다. 스마트 브라우저를 실행하고 있는 경우, 그 브라우저에서는 약간의 유효성 검사를 수행할 수 있습니다. 예를 들어, POST를 실행하기 전에 신용 카드에 유효한 검사값이 들어 있는지를 검사합니다. 다시 말해서, 가능하면 항상 이러한 기능들을 사용하십시오. 클라이언트 대 서버간 왕복 이동 시간이 줄어들면 서버가 액세스하는 백엔드 리소스 뿐만 아니라 웹 서버에 걸리는 스트레스와 네트워크 트래픽도 줄어듭니다. 단, 브라우저에서 수신하는 초기 페이지의 크기는 더 커집니다. 또한 사용자가 새 페이지를 그다지 자주 페치할 필요가 없으므로 성능이 훨씬 나아집니다. 그렇지만 서버측 유효성 검사를 수행하지 않아도 되는 것은 아닙니다. 서버측 유효성 검사는 항상 수행해야 합니다. 서버측 유효성 검사를 수행하면 브라우저가 클라이언트측 유효성 검사 루틴을 실행하지 않더라도 클라이언트로부터 해킹과 같은 나쁜 데이터가 들어오는 것이 방지됩니다.

"모든 브라우저에서 실행되는" HTML을 작성할 때 보통 이러한 기능이 사용됩니다. 이는 간혹 성능상의 장점을 제공하는 자주 사용되는 브라우저 기능을