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

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

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에서을 사용하면 이러한 문제를 해결할 수 있지만, 이 방법은 아래에 설명된 바와 같이 마샬링 및 순차화를 유발하므로 사용하지 않는 것이 좋습니다. 

비 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 설명서에 나와 있습니다.