성능 및 스타일 향상을 위한 25 ASP 팁

Microsoft 컨설팅 서비스, 수석 컨설턴트, Len Cardinal
Microsoft IIS Performance 지도자, George V. Reilly

Microsoft Corporation
개발자 기술 엔지니어
Nancy Cluts의 기사 에서 발췌

최종 수정일: 2000년 4월

요약: 이 기사는 ASP 응용 프로그램 및 VBScript를 최적화하기 위한 팁을 소개합니다.

목차

소개
팁 1: 웹 서버에서 자주 사용되는 데이터 캐시
팁 2: 응용 프로그램 및 세션 개체에서 자주 사용되는 데이터 캐시
팁 3: 웹 서버의 디스크 상에서 데이터 및 HTML 캐시
팁 4: 응용 프로그램 또는 세션 개체에서 활발하지 않은 구성 요소 캐싱 방지
팁 5: 응용 프로그램 또는 세션 개체에서 데이터베이스 연결 캐시 금지
팁 6: 세션 개체의 현명한 사용
팁 7: COM 개체에서 코드 간략화
팁 8: 늦은 리소스 획득, 이른 해제
팁 9: 안정성과 성능을 교환하는 종속 프로세스 실행
팁 10: Option Explicit 사용
팁 11: 서브루틴 및 함수에서 지역 변수 사용
팁 12: 자주 사용되는 데이터를 스크립트 변수로 복사
팁 13: 배열 재정의 방지
팁 14: 응답 버퍼링 사용
팁 15: 일괄 처리 인라인 스크립트 및 Response.Write 문
팁 16: 긴 이동을 시작하기 전에 Response.IsClientConnected 사용
팁 17: 태그를 사용한 개체 인스턴스화
팁 18: ADO 및 다른 구성 요소를 위한 TypeLib 바인딩 사용
팁 19: 사용자 브라우저의 유효성 검사 기능 이용
팁 20: 루프에서 문자열 연결 방지
팁 21: 브라우저 및 프록시 캐싱 사용 
팁 22: 가능한 한 Response.Redirect대신 Server.Transfer 사용
팁 23: 디렉터리 URL에서 후행 슬래시 사용
팁 24: 서버 변수 사용 방지
팁 25: 최신 및 최고급으로 업그레이드
팁 26: 웹 서버 조정
팁 27: 성능 테스트
팁 28: 리소스 연결 읽기

소개

성능은 하나의 기능입니다. 성능을 향상시킬 수 있도록 디자인하거나 나중에 응용 프로그램을 다시 작성해야 합니다. 그러면 ASP(Active Server Pages) 응용 프로그램의 성능을 최대로 발휘할 수 있는 훌륭한 전략에는 어떤 것이 있을까요?

이 기사는 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 주제를 모두 다룹니다. 우리가 선호하는 링크가 있으니 잘 살펴 보십시오.

팁 1: 웹 서버에서 자주 사용되는 데이터 캐시

전형적인 ASP 페이지는 백 엔드 데이터 공간에서 데이터를 검색하고 그 결과를 HTML(Hypertext Markup Language)로 복사합니다. 데이터베이스의 속도와 관계없이 메모리에서 데이터를 검색하는 것은 백 엔드 데이터 공간에서 데이터를 검색하는 것보다 매우 빠릅니다. 로컬 하드 디스크에서 데이터를 읽는 것도 데이터베이스에서 데이터를 검색하는 것보다 더 빠릅니다. 따라서 웹 서버에 있는 데이터를 메모리 또는 디스크에 캐싱하면 성능을 향상시킬 수 있습니다.

캐싱은 시간과 공간을 교환하는 전통적인 방법입니다. 캐시를 올바로 사용하면 성능이 매우 향상된 것을 알 수 있습니다. 캐시를 사용하는 것이 효과적이려면 자주 다시 사용되는 데이터가 있어야 하고 이 데이터를 다시 계산하는 비용이 (적당히) 높아야 합니다. 부실한 데이터를 모두 캐시하는 것은 메모리 낭비입니다.

자주 변경되지 않는 데이터는 데이터베이스 시간 초과와 동시성을 갖을 염려가 없기 때문에 캐싱하기에 적합합니다. 콤보 상자 목록, 참조표, DHTML 스크랩, XML(eXtensible Markup Language) 문자열, 메뉴 항목 및 (데이터 소스 이름(DSN), 인터넷 프로토콜(IP) 어드레스 및 웹 경로를 포함하는)사이트 구성 변수가 캐싱하기에 적합한 것입니다. 데이터 자체보다는 데이터의 프리젠테이션을 캐시할 수 있다는 것을 참조하십시오. ASP 페이지가 자주 변경되고 캐시 비용이 비싸다면(예: 전체 제품 카탈로그) 매번 다시 패인팅하기 보다는 HTML을 미리 생성하도록 하십시오.

데이터를 캐시해야 할 곳은 어디이며 어떤 캐싱 정책이 있습니까? 종종 웹 서버의 메모리 또는 웹 서버의 디스크에서 데이터를 캐시합니다. 다음 두 팁은 이 옵션을 다룹니다.

팁 2: 응용 프로그램 및 세션 개체에서 자주 사용되는 데이터 캐시

ASP 응용 프로그램 및 세션 개체는 메모리 안에 캐싱을 편리하게 해주는 컨테이너를 제공합니다. 응용 프로그램 및 세션 개체에 모두 데이터를 지정할 수 있고 이 데이터는 HTTP 호출 사이에 메모리에 남아 있을 것입니다. 세션 데이터는 각 사용자별로 저장되는 반면 응용 프로그램 데이터는 모든 사용자가 공유합니다.

어느 지점에서 데이터를 응용 프로그램 또는 세션에 로드할까요? 일반적으로 데이터는 응용 프로그램 또는 세션이 시작할 때 로드됩니다. 응용 프로그램 또는 세션이 시작할 때 데이터를 로드하려면 Application_OnStart() 또는 Session_OnStart()에 각각 적당한 코드를 추가합니다. 이러한 함수는 Global.asa에 있어야 하며 없을 때는 이 함수를 추가할 수 있습니다. 가장 필요할 때 데이터를 로드할 수도 있습니다. 이렇게 하려면 데이터가 있는지 확인하고 없을 경우 데이터를 로드하도록 ASP 페이지에 몇 가지 코드를 추가하십시오.(또는 재사용할 수 있는 스크립트 함수 작성) 이것은 필요하다는 것을 알 때 까지 계산을 하지 않는 지연 평가라는 전형적인 성능 기술의 예입니다. 예를 들면 다음과 같습니다.

<%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 = dEnd Function%>

데이터가 필요한 각 청크를 위해 유사한 함수를 작성할 수 있습니다.

어떤 형식으로 데이터를 저장해야 합니까? 모든 스크립트 변수가 가변형이기 때문에 모든 가변 형식을 저장할 수 있습니다. 예를 들어, 문자열, 정수형 또는 배열을 저장할 수 있습니다. 일반적으로 ADO 레코드 집합의 내용을 이러한 변수 형식 중 하나로 저장할 수 있습니다. ADO 레코드 집합에서 데이터를 얻기 위해 한번에 한 필드에서 수동으로 데이터를 VBScript 변수에 복사할 수 있습니다. ADO 레코드 집합 영구 함수인 GetRows(), GetString()  또는 Save()  (ADO 2.5) 중 하나를 사용하면 더 빠르고 쉽습니다. 이 기사에서는 전체를 자세히 설명하지는 않지만 레코드 집합 데이터의 배열을 반환하기 위해 GetRows()를 사용하는 한가지 함수의 예를 들면 다음과 같습니다.

' Get Recordset, return as an ArrayFunction 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 = NothingEnd Function

위의 예제를 더 구체화하면 배열이 아닌 목록을 위한 HTML을 캐시할 수도 있습니다. 단순한 예를 들면 다음과 같습니다.

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

올바른 조건에서는 응용 프로그램 또는 세션 범위에서 ADO 레코드 집합 그 자체를 캐시할 수 있습니다. 다음과 같은 두 가지 주의 사항이 있습니다.

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

이러한 두 가지 요구 사항을 충족시킬 수 없다면 ADO 레코드 집합을 캐시하지 마십시오. 아래 있는 Non-Agile Components 및 Don't Cache Connections 팁에서는 응용 프로그램 및 세션 범위에서 COM 개체를 저장하는 것이 위험하다는 것을 설명합니다.

응용 프로그램 또는 세션 범위에서 데이터를 저장하면 이 데이터는 체계적으로 데이터를 변경하거나, 세션이 만료되거나, 웹 응용 프로그램이 다시 시작할 때까지 저장된 곳에 남아 있게 됩니다. 데이터를 업데이트하려면 어떻게 해야 할까요? 응용 프로그램 데이터를 수동으로 업데이트하려면 데이터를 업데이트하는 관리자 전용 ASP 페이지로 이 데이터를 호출할 수 있습니다. 그렇지 않으면 함수를 통해 주기적으로 데이터를 자동으로 새로 고칠 수 있습니다. 다음 예제에서는 캐시한 데이터를 타임 스탬프와 함께 저장하고 일정 기간이 지난 후 데이터를 새로 고칩니다.

<%' error handing not shown...Const UPDATE_INTERVAL = 300 ' Refresh interval, in seconds' Function to return the employment status listFunction GetEmploymentStatusList UpdateEmploymentStatus GetEmploymentStatusList = Application("EmploymentStatusList")End Function' Periodically update the cached dataSub 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") = d Application("LastUpdate") = CStr(Now) Application.Unlock End IfEnd Sub

또 다른 예는 응용 프로그램 데이터가 있는 World's Fastest ListBox  를 참조하십시오.

세션 또는 응용 프로그램 개체에서 큰 배열을 캐싱하는 것은 바람직하지 않습니다. 배열의 어떤 요소에 액세스하기 전에 스크립팅 언어의 기능이 전체 배열을 임시로 복사할 것을 요구합니다. 예를 들어, 미국 우편 번호와 지역 기상대를 연결하는 10만개의 요소가 있는 문자열 배열을 캐시할 경우 ASP는 우선 10만개 기상대를 모두 임시 배열에 복사한 후에야 하나의 문자열을 추출할 수 있습니다. 이 경우에는 기상대를 저장하거나 사전 구성 요소 중 하나를 사용하기 위한 사용자 정의 메서드가 있는 사용자 정의 구성 요소를 작성하는 것이 좋습니다.

중요한 것을 놓치지 않기 위해 한 마디 덧붙이자면 배열은 메모리에 인접한 키 데이터 쌍을 빨리 조회하고 저장할 수 있도록 합니다. 사전을 인덱싱하는 것은 배열을 인덱싱하는 것 보다 느립니다. 자신의 상황에서 최상의 성능을 제공하는 데이터 구조를 선택해야 합니다.

팁 3: 웹 서버의 디스크 상에서 데이터 및 HTML 캐시

때때로 데이터가 너무 많아서 메모리에서 캐시할 수 없는 경우가 있습니다. "너무 많다"는 것은 판단력에 근거한 것으로 캐시할 항목의 수와 이 항목을 검색하는 빈도뿐 아니라 소비할 메모리의 양과도 관계가 있습니다. 어떤 경우든 메모리에서 캐시하기에 데이터가 너무 많을 때는 웹 서버의 하드 디스크 상에서 텍스트 또는 XML 파일로 데이터를 캐시할 수도 있습니다. 상황에 가장 적합한 캐싱 정책을 세우기 위해 데이터를 캐싱하는 데 메모리와 디스크를 같이 사용할 수 있습니다.

단일 ASP 페이지의 성능을 측정할 때는 디스크에서 데이터를 검색하는 것이 데이터베이스에서 데이터를 검색하는 것보다 느릴 수도 있다는 것을 참조하십시오. 그러나 캐싱은 데이터베이스 및 네트워크에서 로드를 줄여줍니다. 로드가 높을 때 캐싱은 전체적인 성능을 향상시킵니다. 다중 테이블 조인 또는 복잡한 저장 프로시저와 같은 부담이 큰 쿼리의 결과를 캐싱하거나 큰 결과 집합을 캐싱하는 경우 캐싱은 매우 효과적입니다. 언제나 처럼 경쟁하는 여러 가지 계획을 테스트하십시오.

ASP 및 COM은 디스크 캐싱 계획을 세우기 위한 몇 가지 도구를 제공합니다. ADO 레코드 집합 Save() 및 Open() 함수는 디스크에서 레코드 집합을 저장 및 로드합니다. 앞서 언급한 응용 프로그램 데이터 캐싱 팁으로부터 예제 코드를 다시 작성하기 위해 이러한 메서드를 사용할 수 있습니다. 위의 팁에서는 파일로의 Save() 함수가 응용 프로그램 개체에 작성하는 코드를 대신합니다.

파일로 작업하는 다른 몇 가지 구성 요소가 있습니다.

• FileSystemObject를 스크립트  하면 파일을 생성, 읽기 및 작성할 수 있습니다.
• Internet Explorer와 함께 제공되는 Microsoft?? XML 파서인 MSXML은 XML 문서를 저장 및 로드할 수 있도록 합니다.
• The LookupTable 개체(예제, MSN에서 사용)는 디스크에서 단순한 목록을 로드하는 데 가장 적합합니다.

마지막으로 디스크에 데이터 자체보다는 데이터의 프리젠테이션을 캐싱하도록 하십시오. 미리 렌더링된 HTML은 디스크에 .htm 또는 .asp 파일로 저장되고 하이퍼링크로 이 파일을 직접 가리킬 수 있습니다. XBuilder  , 또는 Microsoft?? SQL Server™ Internet publishing features와 같은 상업용 도구를 사용하여 HTML 생성 과정을 자동화할 수 있습니다. 그 대신 .asp 파일에 HTML 조각을 포함할 수도 있습니다. FileSystemObject를 사용하여 디스크에서 HTML 파일을 읽거나 빠른 렌더링을 위해 XML을 사용  할 수도 있습니다.

팁 4: 응용 프로그램 또는 세션 개체에서 활발하지 않은 구성 요소 캐싱 방지

응용 프로그램 또는 세션 개체에 있는 데이터를 캐싱하는 것은 바람직하지만 COM 개체를 캐싱하는 것은 심각한 위험이 될 수 있습니다. 자주 사용하는 COM 개체를 응용 프로그램 또는 세션 개체에 넣고 싶어지는 경우가 있습니다. 그러나 불행히도 Visual Basic 6.0과 그 이전 버전으로 작성된 모든 COM 개체를 포함하여 많은 COM 개체들이 응용 프로그램 또는 세션 개체에 저장되면 심각한 병목현상을 일으킬 수 있습니다.

특히 구성 요소가 활발하지 않다면 세션 또는 응용 프로그램 개체에서 캐시할 때 성능에 병목 현상이 발생합니다. 활발한 구성 요소는 FTM(Free-threaded marchaler)이 모인 ThreadingModel=Both로 표시된 구성 요소 또는 ThreadingModel=Neutral로 표시된 구성 요소입니다.(Neutral 모델은 Windows?? 2000 and COM+에 새로 도입된 것입니다.) 다음과 같은 구성 요소는 활발하지 않습니다.

• 빈 스레드 구성 요소(FTM을 모으지 않는 경우)
• 아파트 스레드 구성 요소
• 단일 스레드 구성 요소

구성된 구성 요소(Microsoft Transaction Server (MTS)/COM+ 라이브러리 및 서버 패키지/응용 프로그램)는 중립 스레드를 제외하면 활발하지 않습니다. 아파트 스레드 구성 요소 및 다른 활발하지 않은 구성 요소는 페이지 범위에서 가장 잘 실행됩니다.(즉, 단일 ASP 페이지에서 만들고 없앱니다.)

IIS 4.0에서는 ThreadingModel=Both가 표시된 구성 요소가 활발한 것이었습니다. 그러나 IIS 5.0에서는 이것이 더 이상 충분하지 않고 Both가 표시될 뿐 아니라 FTM을 모아야 합니다. 활발함에 대한 기사  는 Active Template Library로 작성된 C++ 구성 요소가 FTM을 모으는 방법을 설명합니다. 구성 요소가 인터페이스 포인터를 캐시할 때 이 포인터는 활발하거나 COM GIT(Global Interface Table)에 저장되어야 한다는 것을 주의하십시오. FTM을 모으기 위해 양쪽 스레드 구성 요소를 컴파일할 수 없다면 그 구성 요소를 ThreadingModel=Neutral로 표시할 수 있습니다. 대신 IIS가 활발함 검사를 수행하지 않게 하려면(따라서 활발하지 않은 구성 요소를 응용 프로그램 또는 세션 범위에 저장하려면) 메타베이스에 AspTrackThreadingModel을 True로 설정할 수 있습니다. AspTrackThreadingModel을 변경하는 것은 바람직 하지 않습니다.

응용 프로그램 개체에서 Server.CreateObject로 작성된 활발하지 않은 구성 요소를 저장하려고 하면 IIS 5.0은 오류를 표시합니다. 이때 Global.asa에서 를 사용하여 이 오류를 피해갈 수 있지만 이렇게 하면 아래에 설명하는 마샬링 및 직렬화가 될 수 있기 때문에 바람직 하지 않습니다.

활발하지 않은 구성 요소를 캐시하면 어떤 문제가 발생합니까? 활발하지 않은 구성 요소를 세션 개체에서 캐시하면 ASP 작업자 스레드로의 세션을 "잠금"으로 만듭니다. ASP는 서비스가 요청하는 작업자 스레드를 유지합니다. 일반적으로 새로운 요청은 처음 사용할 수 있는 작업자 스레드가 처리합니다. 스레드에 대한 세션이 잠기면 요청은 관련 스레드를 사용할 수 있을 때까지 대기해야 합니다. 이해를 돕기 위해 비유를 하자면 다음과 같습니다. 수퍼 마켓에 가서 야채를 사고 3번 계산대에서 계산을 했다면 그 이후에는 수퍼 마켓에서 야채 값을 지불 할 때마다 다른 계산대가 더 한가하거나 비어있어도 3번 계산대에서만 지불할 수 있습니다.

응용 프로그램에 활발하지 않은 구성 요소를 저장하면 성능에 더욱 나쁜 영향을 줍니다. ASP는 활발하지 않은 응용 프로그램 범위 구성 요소를 실행하기 위해 특별한 스레드를 작성해야 합니다. 이것은 두 가지 결과를 초래합니다. 모든 호출이 이 스레드로 마샬링되어야 하고 모든 호출이 직렬화됩니다. 마샬링이 되면 매개 변수는 메모리 공유 영역에 저장되어야 하고, 특별한 스레드에는 비용이 많이 드는 컨텍스트 전환이 이루어지고, 구성 요소의 메서드를 실행하고, 결과가 공유 영역으로 마샬링되며, 비용이 많이 드는 다른 컨텍스트 전환이 컨트롤을 원래 스레드로 돌려주게 됩니다. 직렬화되면 모든 메서드가 한번에 하나씩 실행됩니다. 두 개의 다른 ASP 작업자 스레드가 공유된 구성 요소에서 동시에 실행 메서드가 될 수는 없습니다. 이렇게 하면 특히 다중 프로세서 컴퓨터에서 일관성이 없어집니다. 더욱 나쁜 것은 모든 활발하지 않은 응용 프로그램 범위 구성 요소가 하나의 스레드("Host STA")를 공유하기 때문에 직렬화의 영향이 더욱 뚜렷해지는 것입니다.

너무 복잡합니까? 여기에 몇 가지 일반적 규칙이 있습니다. Visual Basic (6.0) 및 이전 버전에서 개체를 작성할 때는 이 개체를 응용 프로그램 또는 세션 개체에서 캐시하지 마십시오. 개체의 스레딩 모델을 모르는 경우에는 캐시하지 마십시오. 활발하지 않은 개체는 캐싱하지 말고 각 페이지에서 그 개체를 작성하고 릴리스해야 합니다. 이 개체는 ASP 작업자 스레드에서 직접 실행하기 때문에 마샬링 및 직렬화가 일어나지 않습니다. COM 개체가 IIS 상자에서 실행하고 개체를 초기화하고 없애는 데 시간이 오래 걸리지 않는다면 적합한 성능입니다. 단일 스레드 개체는 이런 방법으로 사용하지 마십시오. VB이 단일 스레드 개체를 만들 수 있으므로  주의하십시오! 단일 스레드 개체를 이 방식으로 사용해야 한다면(Microsoft Excel 스프레드시트처럼) 높은 처리 속도를 기대하지는 마십시오.

ADO 레코드 집합이 빈 스레드로 표시되면 ADO 레코드 집합을 안전하게 캐시할 수 있습니다. ADO를 빈 스레드로 표시하려면 일반적으로 Program FilesCommonSystemADO 디렉터리에 있는 Makfre15.bat 파일을 사용합니다.

주의: Microsoft Access를 데이터베이스로 사용하는 경우에는 ADO를 빈 스레드로 표시하지 마십시오. ADO 레코드 집합의 연결도 끊어야 합니다. 일반적으로 사용자 사이트에서 ADO 구성을 제어할 수 없다면(예를 들어, 고유한 구성을 관리하는 고객에게 웹 응용 프로그램을 판매한 독립적 소프트웨어 공급업체(ISV: independent software vendor)의 경우) 레코드 집합을 캐싱하지 않는 것이 더 좋을 것입니다.

사전 구성 요소도 활발한 개체입니다. LookupTable은 데이터 파일에서 데이터를 로드하며 구성 정보뿐 아니라 콤보 상자 데이터에 유용합니다. Duwamish Books  의 PageCache 개체는 Caprock 사전과 같은 사전 기능을 제공합니다. 이러한 개체 또는 그 파생물은 효과적인 캐싱 정책의 기초를 형성할 수 있습니다. 스크립팅 사전 개체는 활발한 개체가 아니며 응용 프로그램 또는 세션 범위에 저장해서는 안된다는 것을 주의하십시오.

팁 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 서버 참조에 있습니다.

팁 6: 세션 개체의 현명한 사용

지금 까지 응용 프로그램 및 세션에서 캐싱의 장점을 지지해왔으므로 이제는 세션 개체를 방지하도록 제한하려고 합니다. 앞으로 논의하겠지만 세션을 분주한 사이트에서 사용하면 몇 가지 위험이 있습니다. 분주하다는 것은 일반적으로 초당 수백 페이지가 요청되거나 수천명의 동시 사용자가 있는 사이트를 의미합니다. 이 팁은 전반적으로 측정해야 하는 사이트 즉, 로드를 받아들이거나 내결함성을 구현하기 위한 다중 서버를 사용하는 사이트에 특히 유용합니다. 인트라넷 사이트와 같은 소규모 사이트에서 세션의 편리함은 오버헤드 만큼의 가치가 있습니다.

간단히 말해서 ASP는 자동으로 웹 서버에 접근하는 모든 사용자를 위한 세션을 작성합니다. 각 세션은 약 10 KB의 메모리 오버헤드(세션에 저장된 모든 데이터의 상단에 있는)를 갖고 있어서 모든 요청을 약간 늦춥니다. 세션은 구성할 수 있는 시간 제한 기간동안 유효하며 이 제한 시간은 일반적으로 20분입니다.

세션에 관한 가장 큰 문제는 성능이 아닌 확장성입니다. 세션은 여러 웹 서버들을 걸치지 않기 때문에 일단 하나의 서버에 세션이 만들어지면 그 데이터는 그 서버에 있습니다. 이것은 웹 그룹에서 세션을 사용하면 각 사용자의 요청이 사용자의 세션이 있는 서버로 향하도록 정책을 만들어야 한다는 것을 의미합니다. 이런 것을 사용자를 웹 서버에 "고정"시킨다고 합니다. "고정 세션"이라는 용어는 여기서 유래한 것입니다. 세션이 디스크에 계속 남아있지 않기 때문에 "고정된" 사용자는 웹 서버가 작동을 중지하면 세션 상태를 잃어버리게 됩니다.

고정 세션을 구현하기 위한 정책은 하드웨어 및 소프트웨어 솔루션을 포함합니다. Windows 2000 Advanced Server에 있는 Network Load Balancing  및 Cisco의 Local Director와 같은 솔루션은 약간의 확장성을 희생하여 고정 세션을 구현할 수 있습니다. 이러한 솔루션은 완전하지 않습니다. 이러한 상황에서 자신의 소프트웨어 솔루션을 실행하는 것은 바람직하지 않습니다(우리는 ISAPI 필터 및 URL 맹글링(mangling)과 같은 것을 사용해 왔습니다).

응용 프로그램 개체도 서버를 걸치지 않기 때문에 웹 그룹들 사이에 응용 프로그램 데이터를 공유하거나 업데이트해야 할 경우에는 백 엔드 데이터베이스를 사용해야 합니다. 그러나 읽기 전용 응용 프로그램 데이터를 웹 그룹에서 여전히 사용할 수 있습니다.

작동 시간(장애 조치 및 서버 유지 관리)이 증가는 것 외에 다른 이유가 없다면 대부분 업무용 사이트는 적어도 두 개의 웹 서버에 배포하기를 원합니다. 따라서 업무용 응용 프로그램을 만들 때는 개별적 웹 서버에 사용자 상태를 저장하는 상태 관리 기술뿐 아니라 "고정 세션"을 구현하거나 단순히 세션을 방지해야 합니다.

세션을 사용하지 않는다면 세션을 반드시 꺼야 합니다. Internet Services Manager를 통해 사용자 응용 프로그램의 세션을 끌 수 있습니다.(ISM 설명서 참조) 세션을 사용하려면 몇 가지 방법으로 성능에 영향을 최소화해야 합니다.

세션이 필요하지 않은 컨텐츠(도움말 화면, 방문자 영역 등)를 세션이 꺼진 별도의 ASP 응용 프로그램으로 옮길 수 있습니다. 각 페이지를 기초로 해당 페이지에 세션 개체가 필요 없다는 것을 알리기 위해 다음과 같은 지시어를 ASP 페이지 상단에 놓을 수 있습니다.

<% .EnableSessionState=False %>

이 지시어를 사용하게 되는 이유 중 하나는 세션이 프레임셋과 관심있는 문제를 만드는 것입니다. ASP는 언제나 한번에 한 세션에서 하나의 요청만이 실행되도록 보장합니다. 따라서 브라우저가 한 사용자를 위해 여러 페이지를 요청하면 한번에 단지 하나의 ASP 요청만이 세션에 전달되기 때문에 세션 개체에 액세스할 때 멀티스레딩 문제를 방지합니다. 그러나 불행하게도 프레임셋에 있는 모든 페이지는 동시에 페인트되지 않고 차례로 순차적 방법으로 페인트됩니다. 모든 프레임을 페인트하려면 오래 기다려야 합니다. 이야기의 교훈은 다음과 같습니다. 어떤 프레임셋 페이지가 세션에 의지하지 않는 다면 ASP가 @EnableSessionState=False 지시어를 사용하도록 하십시오.

세션 개체를 사용하지 않고 세션 상태를 관리할 많은 옵션이 있습니다. 상태가 작은 양일 때(4 KB 미만)는 nulls, 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 2000/Windows NT?? 4.0상의 IIS 5.0/IIS 4.0에서 스크립트와 ADO 성능을 상당히 향상시켰다는 것을 참조하십시오. IIS 5.0이 등장하면서 ASP 코드 위에 컴파일된 코드를 사용하여 얻을 수 있었던 성능 향상의 이익이 줄어들었습니다.

ASP에서 COM 개체를 사용하여 얻을 수 있는 이익과 손해에 대한 자세한 논의는 ASP 구성 요소 지침  및 COM과 Microsoft Visual Basic 6.0으로 작성된 분산형 응용 프로그램 프로그래밍  을 참조하십시오. COM 구성 요소를 배포하려면 구성 요소들의 스트레스를 테스트  하는 것이 특히 중요합니다. 사실 모든 ASP 응용 프로그램은 어떤 경우에도 스트레스를 테스트해야 합니다.

팁 8: 늦은 리소스 획득, 이른 해제

이 팁은 간단합니다. 일반적으로 리소스를 늦게 획득해서 일찍 해제하는 것이 가장 바람직합니다. 파일 핸들 및 다른 리소스뿐 아니라 COM 개체에도 해당됩니다.

ADO 연결 및 레코드 집합은 이 최적화에 가장 적합합니다. 레코드 집합을 다 사용한 후 즉, 이 데이터로 테이블을 페인팅했다면 페이지 끝까지 대기하지 말고 즉시 이 데이터를 해제하십시오. VBScript 변수를 Nothing으로 설정하는 것이 가장 좋습니다. 레코드 집합이 단순히 범위를 벗어나게 하지는 마십시오. 관련된 명령 및 연결 개체를 모두 해제하십시오.(레코드 집합에서 Close()를 호출하거나 레코드 집합을 Nothing으로 설정하기 전의 연결을 호출하는 것을 잊지 마십시오) 이렇게 하면 데이터베이스가 리소스를 다루는 시간을 줄여주며 가능한 빨리 데이터베이스 연결을 연결 풀로 해제합니다.

팁 9: 안정성과 성능을 교환하는 종속 프로세스 실행

ASP와 MTS/COM+에는 모두 안정성과 성능을 교환할 수 있는 구성 옵션이 있습니다. 응용 프로그램을 만들거나 배포할 때는 이러한 교환을 이해해야 합니다.

ASP 옵션

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

• 낮은 격리. 이것은 모든 IIS 버전에서 지원되며 가장 빠릅니다. 이것은 주요 IIS 프로세스인 Inetinfo.exe에서 ASP를 실행합니다. ASP 응용 프로그램이 작동을 중지하면 IIS도 작동을 중지합니다.(IIS 4.0에서 IIS를 다시 시작하기 위해 웹 마스터는 InetMon과 같은 도구를 사용하여 사이트를 모니터하고 실패한 서버를 다시 시작하기 위해 배치 파일을 실행시킵니다. IIS 5.0에는 안정적인 재시작  이 도입되어 실패한 서버를 자동으로 다시 시작합니다.)
• 보통 격리. ASP가 IIS 프로세스 밖에서 실행하기 때문에 독립 프로세스라고 하는 새로운 수준을 IIS 5.0에 도입했습니다. 보통 격리에서는 보통으로 실행하도록 구성된 모든 ASP 응용 프로그램이 단 하나의 프로세스 공간을 공유합니다. 이렇게 하면 하나의 상자에서 여러 개의 독립 프로세스 ASP 응용 프로그램을 실행하는 데 필요한 프로세스의 수를 줄일 수 있습니다. 보통은 IIS 5.0에서 기본 격리 수준입니다.
• 높은 격리. IIS 4.0과 IIS 5.0에서 지원되는 높은 격리도 독립 프로세스입니다. ASP이 작동을 중지해도 웹 서버는 계속 작동합니다. ASP 응용 프로그램은 자동으로 다음 ASP 요청을 다시 시작합니다. 높은 격리를 사용하면 High로 실행하도록 구성된 각 ASP 응용 프로그램은 각자 고유한 공간에서 실행합니다. 이렇게 하면 ASP 응용 프로그램을 다른 ASP 응용 프로그램으로부터 보호합니다. 이 것의 단점은 각 ASP 응용 프로그램에 대해 개별적인 프로세스를 해야 한다는 것입니다. 하나의 상자에 십여 개의 응용 프로그램을 호스트해야 할 때 오버헤드가 많이 추가될 수 있습니다.

어떤 옵션이 가장 최선일까요? IIS 4.0에서는 독립 프로세스를 실행하면 성능이 급격히 떨어졌습니다. IIS 5.0에서는 독립 프로세스 ASP 응용 프로그램을 실행하는 비용을 최소화하기 위해 많은 작업을 해야 했습니다. 사실 대부분 테스트에서 IIS 5.0에서의 독립 프로세스 ASP 응용 프로그램이 IIS 4.0에서의 종속 프로세스 응용 프로그램보다 빨리 실행했습니다. 하지만 여전히 두 플랫폼 모두에서 종속 프로세스(낮은 격리 수준)가 최고의 성능을 발휘하고 있습니다. 그러나 상대적으로 적중률이 낮거나 최대 처리량이 낮은 경우 낮은 격리 수준을 사용하는 것은 별로 유리하지 않습니다. 따라서 각 웹 서버에 초당 수백 또는 수천 페이지가 필요하지 않다면 낮은 격리 수준을 사용하고 싶지 않을 것입니다. 언제나 처럼 여러 구성으로 테스트를 한 다음 어떤 교환을 할지를 정하십시오.

참고: 독립 프로세스(보통 또는 높은 격리) ASP 응용 프로그램을 실행할 때 이 응용 프로그램은 NT4에 있는 MTS 및 Windows 2000에 있는 COM+에서 실행됩니다. 즉, NT4에서는 Mtx.exe에서 실행되고 Windows 2000에서는 DllHost.exe에서 실행됩니다. 이러한 프로세스가 작업 관리자에서 실행되는 것을 알 수 있습니다. 또한 독립 프로세스 ASP 응용 프로그램을 위해 IIS가 MTS 패키지 또는 COM+ 응용 프로그램을 구성하는 방법도 알 수 있습니다.

COM 옵션

비록 ASP 옵션과 완전히 일치하지는 않지만 COM 구성 요소도 세 개의 구성 옵션을 갖고 있습니다. COM 구성 요소는 구성되지 않거나, 라이브러리 응용 프로그램으로 구성되거나, 서버 응용 프로그램으로 구성될 수 있습니다. 구성되지 않는다는 것은 구성 요소가 COM+과 함께 등록되지 않는다는 의미입니다. 구성 요소는 호출자의 프로세스 공간에서 실행될 것입니다. 즉, 종속 프로세스입니다. 라이브러리 응용 프로그램도 종속 프로세스지만 보안, 트랜잭션 및 컨텍스트 지원과 같은 COM+의 혜택을 받습니다. 서버 응용 프로그램은 그들만의 프로세스 공간에서 실행하도록 구성됩니다.

라이브러리 응용 프로그램보다 구성되지 않은 구성 요소가 약간 유리하다는 것을 알 수 있을 것입니다. 또한 서버 응용 프로그램보다 라이브러리 응용 프로그램은 매우 큰 성능의 이익이 있다는 것을 알 수 있을 것입니다. 이것은 라이브러리 응용 프로그램은 ASP와 같은 프로세스에서 실행하지만 서버 응용 프로그램은 그들 고유의 프로세스에서 실행하기 때문입니다. 프로세스간 호출은 종속 프로세스보다 비용이 많이 듭니다. 또한 프로세스간에 레코드 집합과 같은 데이터를 전달할 때 모든 데이터를 두 프로세서 사이에서 복사해야 합니다.

위험! COM 서버 응용 프로그램을 사용할 때 ASP와 COM간에 개체를 전달하려면 개체가 "marshal-by-value" 즉 MBV를 구현하는지 확인해야 합니다. MBV를 구현하는 개체는 한 프로세스에서 다른 프로세스로 자신을 복사합니다. 이것은 개체가 작성자의 프로세스에 남아있고 다른 프로세스가 이 개체를 사용하기 위해 반복적으로 작성하는 프로세스를 호출하는 다른 방법보다 효율적입니다. 연결이 끊어진 ADO 레코드 집합은 marshal-by-value를 구현하지만 연결된 레코드 집합은 그렇지 않습니다. Scripting.Dictionary는 MBV를 구현하지 않으면 프로세스간에 전달되면 안됩니다. 마지막으로 VB 프로그래머에게 보내는 메시지입니다. 매개 변수 ByVal을 전달하여 MBV를 구현할 수 없습니다. MBV는 원래 구성 요소 작성자만이 구현할 수 있습니다.

무엇을 해야 합니까?

성능과 안정성을 합리적으로 교환하는 구성을 추천한다면 다음과 같습니다.

• IIS 4.0에서, ASP의 낮은 격리 수준과 MTS 서버 패키지를 사용하십시오.
• IIS 5.0에서, ASP의 보통 격리 수준과 COM+ 라이브러리 응용 프로그램을 사용하십시오.

이것은 매우 일반적인 지침입니다. 호스팅 회사는 일반적으로 보통 또는 높은 격리 수준에서 ASP를 실행하지만 단일 목적 웹 서버는 낮은 격리 수준에서 실행할 수 있습니다. 교환을 측정하고 어떤 구성이 가장 적합한지 스스로 결정하십시오.

팁 10: Option Explicit 사용

.asp 파일에서 Option Explicit을 사용하십시오. .asp 파일의 상단에 위치하는 이 지시어는 개발자가 사용할 모든 변수를 선언하도록 합니다. 이렇게 하면 변수를 잘 못 입력하거나 불필요한 새 변수를 만드는 것을 방지할 수 있기 때문에(예를 들어, MyXMLStirng=대신MyXLMString=…) 많은 프로그래머가 응용 프로그램을 디버깅할 때 유용하다고 생각합니다.

아마 선언된 변수가 선언되지 않은 변수보다 빠르다는 것을 알아낸 것이 더 중요할 수도 있습니다. 보이지 않는 상태에서 스크립팅 실행 시간은 선언되지않은 변수를 사용할 때 마다 이 변수를 이름으로 참조합니다. 반면 선언된 변수는 컴파일 시간 또는 실행 시간에 서수로 지정됩니다. 그 다음 선언된 변수는 이 서수에 의해 참조됩니다. Option Explicit은 반드시 변수 선언을 하도록 하기 때문에 모든 변수가 선언되고 빨리 액세스할 수 있습니다.

팁 11: 서브루틴 및 함수에서 지역 변수 사용

지역 변수는 서브루틴 및 함수에서 선언된 변수입니다. 함수 또는 서브루틴안에서 지역 변수 액세스는 전역 변수 액세스보다 빠릅니다. 또한 지역 변수를 사용하면 코드가 더 깔끔하기 때문에 가능하면 지역 변수를 사용하는 것이 좋습니다.

팁 12: 자주 사용되는 데이터를 스크립트 변수로 복사

ASP에서 COM 개체에 액세스할 때는 자주 사용되는 개체 데이터를 스크립트 변수에 복사해야 합니다. 이렇게 하면 스크립트 변수에 액세스하는 것과 비교했을 때 상대적으로 비용이 많이 드는 COM 메서드 호출을 줄여줍니다. Collection 및 Dictionary 개체에 액세스할 때도 이 기술이 비용이 많이 드는 조회를 줄여줍니다.

일반적으로 한번 이상 개체 데이터에 액세스하려면 이 데이터를 스크립트 변수에 복사합니다. 이렇게 해서 가장 최적화되는 것은 요청 변수입니다.(Form 및 QueryString 변수) 예를 들어, 사용자의 사이트가 UserID로 불리는 QueryString 변수를 전달할 때 이 UserID가 특정 페이지에서 12번 참조된다고 가정해 보십시오. 요청("UserID")을 12번 호출하는 대신 UserID를 ASP 페이지 상단에서 변수로 지정하고 이 페이지에서 이 변수를 사용하면 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. baz를 확인하기 위해 1-3 단계를 다시 합니다. 이 시스템은 qaz 호출이 개체 모델을 변경한 것을 모르기 때문에 baz를 확인하려면 1-3 단계를 다시 해야 합니다.
7. baz를 Foo.bar.blah의 구성원으로 확인합니다. 속성을 입력합니다.
8. . 1-3 단계를 다시 실행하고 zaq를 확인합니다.
9. 1-3 단계를 다시 실행하고 abc를 확인합니다.

여기서 알 수 있듯이 이것은 매우 비효율적입니다. VBScript에서 이 코드를 작성하는 더 빠른 방법은 다음과 같습니다.

Set myobj = Foo.bar.blah ' do the resolution of blah ONCEMyobj.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: 배열 재정의 방지

배열을 재정의하지 않도록 하십시오. 물리적인 메모리 크기에 제약이 있는 컴퓨터를 사용하는 경우 성능에 관한한 최악의 경우에 배열의 초기 정의를 설정하는 것이 가장 좋습니다. 그렇지 않으면 정의를 가장 적합하게 설정하고 필요한 경우에는 재정의합니다. 이것은 불필요한 몇 MB의 메모리를 직접 할당해야 한다는 것을 의미하지는 않습니다.

다름 코드는 정의 및 재정의의 불필요한 사용을 보여줍니다.

<% 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"%>

배열을 확장하기 위해 재정의하는 것보다는 처음에 정확한 사이즈(이 경우에는 5)로 배열을 정의하는 것이 훨씬 바람직합니다. 약간의 메모리가 낭비될 수 있지만(모든 요소의 사용을 중단하지 않으면) 속도가 빨라집니다.

팁 14: 응답 버퍼링 사용

"응답 버퍼링"을 켜면 전체 한 페이지 정도의 출력을 버퍼할 수 있습니다. 이렇게 하면 브라우저에 쓰는 양을 최소화하여 전체적으로 성능이 향상됩니다. 각 쓰기에는 많은 오버헤드(회선으로 가는 데이터의 양 및 IIS에)가 있기 때문에 쓰기가 적을수록 바람직합니다. TCP/IP는시작이 느리고 Nagling  알고리즘(네트워크 정체를 최소화하는 데 사용)을 사용하기 때문에 작은 블록을 여러 개 전송하는 것 보다는 데이터의 큰 블록을 몇 개 전송하는 것이 더 효율적입니다.

응답 버퍼링을 켜는 방법은 두 가지가 있습니다. 첫째, Internet Services Manager를 사용하여 전체 응용 프로그램에 응답 버퍼링을 켤 수 있습니다. 이것은 바람직한 접근법이며 IIS 4.0 및 IIS 5.0에 있는 새로운 ASP 응용 프로그램을 위해 초기값으로 응답 버퍼링이 켜집니다. 두번째는 페이지 단위를 기초로 한 것으로서 ASP 페이지의 상단에 다음과 같은 코드 줄을 넣어 응답 버퍼링을 사용할 수 있습니다.

<% Response.Buffer = True %>

이 코드 줄은 브라우저에 응답 데이터를 쓰기 전에 실행해야 합니다.(즉, ASP 스크립트에 HTML이 나타나기 전 및 Response nulls 컬렉션을 사용하여 nulls가 설정되기 전에) 일반적으로 전체 응용 프로그램에 응답 버퍼링을 켜놓는 것이 가장 좋습니다. 이렇게 하면 모든 페이지에 위의 코드 줄을 넣지 않아도 됩니다.

Response.Flush

응답 버퍼링에 대한 한가지 공통적인 불만은 전체 페이지가 생성될 때까지 기다려야 무언가를 볼 수 있기 때문에 사용자는 ASP 페이지의 응답 시간이 느리다고 느끼는 것입니다.(전체 응답 시간이 향상되었음에도 불구하고) 오래 걸리는 페이지에서는 Response.Buffer = False를 설정하여 응답 버퍼링을 끌 수 있습니다. 하지만 이것 보다는 Response.Flush 메서드를 사용하는 것이 더 훌륭한 전략입니다. 이 메서드는 ASP가 브라우저로 페인트한 모든 HTML을 플러시합니다. 예를 들어, 천 개의 행(row)이 있는 테이블 중 백 개 행을 페인트한 다음 ASP는 페인트한 결과를 브라우저로 보내기 위해 Response.Flush를 호출할 수 있습니다. 이렇게 하면 나머지 행이 준비되기 전에 사용자는 우선 백 개 행을 볼 수 있습니다. 이러한 기술은 데이터를 브라우저로 점차적으로 프리젠테이션하는 것과 결합된 응답 버퍼링을 제공합니다.

(위의 행이 천 개인 테이블의 예에서 많은 브라우저는 닫는 태그가 나타나야만 테이블을 페인팅한다는 것을 참조하십시오. 대상 브라우저가 이것을 지원하는지 확인하십시오. 이렇게 하려면 테이블을 행을 적게 갖는 여러 개의 테이블로 나눈 다음 각 테이블 다음에Response.Flush를 호출해 보십시오. 새로운 Internet Exploer 버전은 테이블을 완전히 다운로드하기 전에 테이블을 페인트하며 테이블의 열(column)의 폭을 지정하면 특히 빨리 페인트합니다. 이렇게 하면 Internet Explorer가 모든 셀의 컨텐츠 폭을 측정하여 열의 폭을 계산하지 않도록 도와줍니다.)

응답 버퍼링에 대한 또 하나의 불만은 큰 페이지를 생성할 때 서버 메모리를 많이 사용한다는 것입니다. 큰 페이지를 생성하는 지혜는 제외하고 이 문제는 Response.Flush를 신중히 사용하여 해결할 수 있습니다.

팁 15: 일괄 처리 인라인 스크립트 및 Response.Write 문

VBScript 구문 <% = expression %>은 "expression"의 값을 ASP 출력 스트림에 씁니다. 응답 버퍼링을 켜지 않으면 이 문(statement)이 여러 작은 패킷으로 네트워크를 통해 브라우저로 데이터를 쓰게 됩니다. 이 과정은 매우 느립니다. 작은 양의 스크립트 및 HTML을 여기 저기 배치하면 스크립트 엔진과 HTML간의 전환이 일어나서 성능이 떨어집니다. 그러므로 다음과 같은 팁을 사용하십시오. 가깝게 모여있는 인라인 식(expression)을 Response.Write를 한 번 호출하는 것으로 교체합니다. 예를 들어 다음의 예제처럼 행의 필드마다 응답 스트림에 쓰기가 하나 있고 행마다 VBScript 및 HTML 사이에 많은 스위치가 있습니다.

<% For Each fld in rs.Fields %> <%Next While Not rs.EOF%> <% For Each fld in rs.Fields %> <% Next <% rs.MoveNext Wend %>

<% = fld.Name %>
<% = fld.Value %>

아래에 있는 더 효율적인 코드는 행마다 응답 스트림에 쓰기가 하나 있습니다. 모든 코드는 하나의 VBScript 블록에 포함됩니다.

<% For each fld in rs.Fields Response.Write ("" & vbCrLf) Next While Not rs.EOF Response.Write ("") For Each fld in rs.Fields %>Response.Write("" & vbCrLf) Next Response.Write "" Wend%>

" & fld.Name & "
" & fld.Value & "

이 팁은 응답 버퍼링을 사용할 수 없을 때 더 큰 효과가 있습니다. 응답 버퍼링을 사용하는 것이 가장 바람직 하며 그런 다음Response.Write를 일괄 처리하면 성능이 향상되는지 살펴 봅니다.

(이 특정 예제에서 테이블의 본문을 작성하는 중첩 루프(While Not rs.EOF)는 GetString  를 신중하게 호출하여 교체할 수 있습니다.)

팁 16: 긴 이동을 시작하기 전에 Response.IsClientConnected 사용

인내심이 부족한 사용자는 요청을 실행하기도 전에 ASP 페이지를 중단할 수 있습니다. 사용자가 Refresh를 누르거나 서버에 있는 다른 페이지로 이동하면 ASP 요청 대기열의 끝에 새로운 요청이 놓이고 연결이 끊어진 요청은 대기열의 가운데 놓입니다. 서버에 로드가 높을 때(요청 대기열이 길고 따라서 응답 시간도 길어집니다.) 이런 상황이 발생하며 이것은 상황을 더욱 악화시킵니다. 사용자가 더 이상 연결되어있지 않으면 ASP 페이지를 실행할 수 없습니다.(특히 느리고 큰 ASP 페이지) Response.IsClientConnected 속성을 사용하여 이러한 상태를 확인할 수 있습니다. 이것이 False를 반환하면 Response.End를 호출하고 나머지 페이지를 중지해야 합니다. 사실 IIS 5.0은 이러한 것을 모두 집대성합니다. ASP가 새로운 요청을 실행하려고 할 때마다 그 요청이 대기열에서 얼마나 오래 있었는지를 알기 위해 확인합니다. 이 요청이 대기열에 3초 이상 있었다면 ASP는 클라이언트가 여전히 연결되어 있는지 확인한 다음 연결되어 있지 않을 때는 즉시 요청을 종료합니다. 이 3초 제한 시간을 조정하려면 메타베이스에서 AspQueueConnectionTestTime 설정을 사용할 수 있습니다.

실행 시간이 매우 긴 페이지가 있다면 중간에 Response.IsClientConnected를 확인하고 싶을 수도 있습니다. 응답 버퍼링을 사용하고 있다면 사용자에게 무언가가 진행중이라는 것을 알리기 위해 중간에 Response.Flush를 사용하는 것도 좋습니다.

참고 IIS 4.0에서는 우선 Response.Write를 실행하지 않으면 Response.IsClientConnected가 정확하게 실행되지 않습니다. 버퍼링을 사용하고 있다면 Response.Flush를 사용해야 합니다. IIS 5.0에서는 이렇게 하지 않아도 Response.IsClientConnected가 잘 작동합니다. 어떤 경우에나 Response.IsClientConnected는 약간의 비용이 들기 때문에 적어도 500 밀리초(초당 12 페이지의 처리량을 유지하려면 이것도 긴 시간입니다.)가 소요되는 작업 앞에만 사용해야 합니다. 일반적인 경험에 따라 테이블의 행(row)을 페인팅할 때와 같이 복잡한 루프의 모든 반복에 호출하지 마십시오. 대신 테이블의 20번째 또는 50번째 행에서 호출하십시오.

팁 17: 태그를 사용한 개체 인스턴스화

모든 코드 경로에서 사용되지 않는 개체를 참조해야 한다면(특히 서버 혹은 응용 프로그램 범위 개체) Server.CreateObject 메서드를 사용하기 보다는 Global.asa에서 태그를 사용하여 개체를 선언하십시오. Server.CreateObject는 즉시 개체를 만듭니다. 이 개체를 나중에 사용하지 않는다면 결국 리소스를 낭비하는 것입니다. 태그는 objname을 선언하지만 이 개체의 메서드 또는 속성 중 하나가 처음 사용될 때까지 objname은 실제로 만들어지지 않습니다.

이것은 지연 평가의 또 다른 예입니다.

팁 18: ADO 및 다른 구성 요소를 위한 TypeLib 선언 사용

ADO를 사용할 때 개발자는 ADO의 다양한 상수에 액세스하기 위한 adovbs.txt를 포함합니다. 이 파일은 상수를 사용할 모든 페이지에 포함되어야 합니다. 이 상수 파일은 매우 커서 모든 ASP 페이지의 컴파일 시간 및 스크립트 크기에 상당한 오버헤드를 추가합니다.

IIS 5.0은 구성 요소의 형식 라이브러리에 바인딩하는 기능을 도입했습니다. 이 기능을 사용하면 형식 라이브러리를 한번 참조하여 이것을 모든 ASP 페이지에 사용할 수 있습니다. 각 페이지는 상수 파일을 컴파일할 필요가 없기 때문에 구성 요소 개발자는 ASP에서 사용할 VBScript #include 파일을 작성하지 않아도 됩니다.

ADO TypeLib를 액세스하려면 다음 문(statement) 중 하나를 Global.asa에 포함해야 합니다.

또는

팁 19: 사용자 브라우저의 유효성 검사 기능 이용

최신 브라우저는 XML, DHTML, Java  애플릿 및 원격 데이터 서비스  (Remote Data Service)와 같은 기능을 지원을 개발해왔습니다. 이러한 기능을 최대한 이용하십시오. 이러한 기술을 사용하면 데이터 캐싱뿐 아니라 클라이언트 쪽 유효성 검사를 실행하여 웹 서버로의 왕복 이동을 줄일 수 있습니다. 스마트 브라우저를 사용하면 브라우저가 사용자를 위해 약간의 유효성 검사를 할 수 있습니다.(예를 들어, POST를 실행하기 전에 신용 카드가 해당 금액을 사용할 수 있는지  확인할 수 있습니다.) 다시 강조하지만 이 기능을 가능한 많이 이용하십시오. 클라이언트 쪽 왕복 이동을 줄이기 때문에 서버가 액세스하는 백 엔드 리소스뿐 아니라 네트워크 소통량(비록 브라우저로 보내지는 초기 페이지가 더 크더라도)과 웹 서버의 스트레스를 줄일 수 있습니다. 게다가 사용자는 새로운 페이지를 자주 반입할 필요가 없기 때문에 경험이 향상됩니다. 하지만 이것은 서버 쪽 유효성 검사까지 해주지 않기 때문에 서버쪽 유효성 검사하는 것을 잊지 마십시오. 이것은 브라우저가 클라이언트쪽 유효성 검사 루틴을 실행하지 않거나 해킹과 같은 이유로 잘못된 데이터가 클라이언트에서 오는 것을 방지합니다.

대부분은 "브라우저 독립적" HTML을 작성하여 만들어졌습니다. 이것은 성능을 향상시키는 기능이 있는 일반적인 브라우저를 개발자가 이용할 수 없도록 합니다. 매우 성능이 높은 사이트는 반드시 브라우저 "범위"를 언급해야 하며 일반적인 브라우저를 위해 페이지를 최적화하는 것이 바람직합니다. 브라우저 기능 구성 요소(Browser Capabilities Component)를 사용하여 ASP에서 브라우저 기능을 쉽게 검색할 수 있습니다. Microsoft FrontPage와 같은 도구는 사용자가 대상으로 선택한 브라우저 및 HTML 버전에서 실행되는 코드를 설계할 수 있도록 도와줍니다. 자세한 내용은 When is Better Worse? Weighing the Technology Trade-Offs  를 참조하십시오.

팁 20: 루프에서 문자열 연결 방지

많은 사람들이 다음과 같이 루프 안에 문자열을 작성합니다.

s = " " & vbCrLfFor Each fld in rs.Fields s = s & " "NextWhile Not rs.EOF s = s & vbCrLf & " " For Each fld in rs.Fields s = s & " " Next s = s & " " rs.MoveNextWends = s & vbCrLf & "

" & fld.Name & "
" & fld.Value & "

" & vbCrLfResponse.Write s

이러한 접근에는 몇 가지 문제가 있습니다. 우선 반복적으로 문자열을 연결하면 시간이 제곱으로 걸립니다. 다시 말해 루프를 실행하는 데 걸리는 시간은 레코드 수와 필드 수를 곱한 값의 제곱에 비례합니다. 간단한 예제가 이것을 더욱 명확하게 합니다.

s = ""For i = Asc("A") to Asc("Z") s = s & Chr(i)Next

첫번째 반복에서 하나의 문자로된 문자열 "A"을 얻습니다. 두번째 반복에서 VBScript는 문자열을 재할당하고 두 문자("AB")를 s로 복사해야 합니다. 세번째 반복에서 VBScript는 s를 다시 재할당하고 3개 문자를 s로 복사합니다. N번째(26번째) 반복에서 s를 재할당하고 N개 문자를 s로 복사합니다. 이것이 N*(N+1)/2 복사본이 있는 1+2+3+…+N의 합계입니다.

위의 레코드 집합 예제에서 100개 레코드와 5개 필드가 있다면 내부 루프는 100*5 = 500번 실행되고 모든 복사와 재할당을 하는 데 걸린 시간은 500*500 = 250,000에 비례할 것입니다. 이것이 적절한 크기의 레코드 집합을 위한 복사입니다.

이 예제에서 문자열 연결을 Response.Write() 또는 인라인 스크립트(<% = fld.Value %>)와 교체하여 코드를 향상시킬 수 있습니다. 응답 버퍼링이 켜있다면(켜있어야 함) Response.Write는 응답 버퍼의 끝에 데이터를 추가할 뿐이기 때문에 교체하는 것이 빠릅니다. 재할당이 포함되지않기 때문에 매우 효과적입니다.

ADO 레코드 집합을 HTML 테이블로 변환하는 특별한 경우에는 GetRows 또는 GetString  을 사용하도록 하십시오.

JScript에서 문자열을 연결하는 경우 += 연산자를 사용하는 것이 바람직합니다. 예를 들어 s = s + "some string"이 아닌 s += "some string"을 사용하십시오.

팁 21: 브라우저 및 프록시 캐싱 사용

ASP는 브라우저와 프록시에서 기본으로 캐싱을 사용하지 않습니다. 잠재적으로 시간에 민감한 정보를 가지고있는 ASP 페이지는 본질적으로 동적이기 때문에 이해할 수 있는 부분입니다. 모든 뷰에서 새로 고침이 필요 없는 페이지의 경우 브라우저와 프록시 캐싱을 사용해야 합니다. 이를 통해 브라우저와 프록시는 일정 길이의 시간동안 페이지의 "캐시된" 복사본을 사용할 수 있으며 사용자가 이를 제어할 수 있습니다. 캐싱은 서버의 부하를 크게 줄일 수 있으며 사용자의 이용도를 향상시킬 수 있습니다.

어떤 종류의 동적 페이지에 캐싱을 사용할까요? 밑에 몇 가지 예를 나타내었습니다.

• 날씨가 매 5분 마다 업데이트되는 일기예보 페이지.
• 하루에 두 번 업데이트되는 뉴스 또는 출판물을 게시하는 홈 페이지.
• 근간이 되는 통계를 몇 시간마다 업데이트하는 뮤츄얼 펀드 성과 목록.

브라우저와 프록시의 캐싱을 사용하면 웹 페이지에 기록되는 방문자수가 줄어들게 됩니다. 모든 페이지 뷰를 정확하게 측정하거나 광고를 게시하려는 경우에는 브라우저와 프록시의 캐싱이 실망스러울 것입니다.

브라우저 캐싱은 웹 서버에서 브라우저로 보내는 HTTP "Expires" 헤더로 제어합니다. ASP는 두 가지 간단한 메커니즘을 제공하여 이 헤더를 보냅니다. 몇 분 후에 페이지가 만료되도록 설정하려면 Response.Expires 속성을 설정하십시오. 다음 예는 브라우저가 컨텐츠를 10분 후에 만료하도록 지시합니다.

<% Response.Expires = 10 %>

Response.Expires를 음수 또는 0으로 설정하면 캐싱을 사용할 수 없게 됩니다. -1000(하루가 약간 넘음)과 같이 큰 음수를 사용하여 서버와 브라우저 클럭 사이의 불일치를 해결하십시오. 두 번째 속성인 Response.ExpiresAbsolute를 사용하면 컨텐츠가 만료되는 특정 시간을 설정할 수 있습니다.

<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>

만료 설정을 위해 Response 개체를 사용하는 것 외에 일반적으로 HTML 파일의 섹션 내에 태그를 작성할 수도 있습니다. 프록시는 아닐지라도 일부 브라우저는 이 지시에 따라 작동합니다.

마지막으로, Response.CacheControl 속성을 사용하여 HTTP 프록시가 캐시하기에 컨텐츠가 유효한지의 여부를 나타낼 수 있습니다. 이 속성을 "Public"으로 설정하면 프록시가 컨텐츠를 캐시할 수 있게 됩니다.

<% Response.CacheControl = "Public" %>

이 속성은 "Private"이 기본으로 설정되어 있습니다. 어떤 사용자에 특정한 데이터를 보여주는 페이지에 대해서는 프록시 캐싱을 사용하지 않아야 합니다. 캐싱을 설정하면 프록시는 어떤 사용자 소유의 페이지를 다른 사용자에게 제공하기 때문입니다.

팁 22: 가능한 한 Response.Redirect 대신 Server.Transfer 사

Response.Redirect는 브라우저가 다른 페이지를 요청하도록 지시합니다. 이 기능을 종종 사용하여 사용자를 로그온 또는 오류 페이지로 다시 연결시킵니다. 다시 연결되면 새 페이지 요청이 강제되기 때문에 결과적으로 브라우저는 웹 서버에 두 번 왕복해야 하며 웹 서버는 추가 요청을 처리해야 합니다. IIS 5.0은 동일 서버상에서 다른 ASP 페이지로 실행을 전달하는Server.Transfer라는 새 기능을 도입합니다. 이 기능으로 브라우저와 웹 서버 간의 불필요한 왕복을 피할 수 있기 때문에 결과적으로 전체 시스템이 향상될 뿐만 아니라 사용자에게는 빠른 반응 시간을 제공하게 됩니다. Server.Transfer 및 Server.Execute에 관한 내용이 있는 New Direction in Redirection  을 살펴보십시오.

IIS 5.0 및 ASP 3.0의 새 기능을 전부 수록한 IIS 5.0에서 ASP 이용  도 참조하십시오.

팁 23: 디렉터리 URL에서 후행 슬래시 사용

관련 팁은 디렉터리를 가리키는 URL에서 후행 슬래시(/)를 사용하는 것입니다. 후행 슬래시를 생략하면 브라우저는 서버에 요청하여 디렉터리를 요구하고 있다는 응답을 받습니다. 그러면 브라우저는 URL에 슬래시를 첨가하여 두번째 요청을 하며 이때서야 서버가 그 디렉터리(또는 기본 문서가 없거나 디렉터리 브라우징을 사용할 수 없는 경우 디렉터리 목록)에 대한 기본 문서로 응답합니다. 슬래시의 첨가는 처음의 쓸데없는 왕복을 제거합니다. 편리한 사용을 위해서는 표시 이름에 후행 슬래시를 생략하고 싶을 것입니다.

예를 들어, 다음을 작성하십시오.

http://msdn.microsoft.com/workshop

이것은 웹 사이트에서 홈페이지를 가리키는 URL에도 적용됩니다. 이 아니라 을 사용하십시오.

팁 24: 서버 변수의 사용을 피함

서버 변수에 액세스하면 웹 사이트가 서버에 특별한 요청을 하게 되어 요청한 것만이 아니라 모든 서버 변수를 수집하게 됩니다. 곰팡이 쓴 다락방에 있는 폴더의 특정 물건을 가져와야 하는 것과 같습니다. 그 하나의 물건을 원하는 경우, 그 물건에 액세스하기 전에 우선 다락방에 가서 폴더를 찾아야 합니다. 서버 변수를 요청할 때도 마찬가지입니다. -performance hit은 서버 변수를 처음 요청할 때 발생합니다. 다른 서버 변수에 대한 계속된 요청은 performance hit을 유발하지 않습니다.

비한정 Request 개체(예, Request("Data"))에 절대 액세스하지 마십시오. Request.nulls, Request.Form, Request.QueryString 또는Request.ClientCertificate에 있지 않은 항목의 경우, Request.ServerVariables에 대한 암시적 호출이 있습니다.Request.ServerVariables 집합은 다른 집합보다 훨씬 느립니다.

팁 25: 최신 및 최고급으로 업그레이드.

시스템 구성 요소는 일정하며 최신 및 최고급으로 업그레이드하는 것이 좋습니다. Windows 2000  (및 그에 따른 IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1및 JScript 5.1)으로 업그레이드하는 것이 가장 바람직합니다. IIS 5.0 및 ADO 2.5은 다중 프로세서 컴퓨터에서 극적인 성능 향상을 수행합니다. Windows 2000에서 ASP 는 4개 이상의 프로세서로 훌륭하게 확장하며 반면 IIS 4.0에서는 ASP가 두 프로세서 이상으로 잘 확장되지 않습니다. Windows 2000으로 업그레이드한 후 응용 프로그램에서 스크립트 코드와 ADO를 많이 사용하면 할 수록 더욱 큰 성능 향상을 보게 될 것입니다.

Windows 2000으로 업그레이드할 수 없는 경우에는 최신 버전의 SQL Server  , ADO  , VBScript 및 JScript  , MSXML, Internet Explorer  그리고 NT4 Service Pack으로 업그레이드할 수 있습니다. 이 모두가 성능을 향상시킬 뿐 아니라 신뢰도도 높입니다.

팁 26: 웹 서버 조정.

사이트 성능을 향상시킬 수 있는 몇 가지 IIS 튜닝 매개 변수가 있습니다. 예를 들면, IIS 4.0의 경우 ASP ProcessorThreadMax 매개 변수(IIS 문서 참조)를 증가시켜서 상당한 이득을 얻는 경우가 종종 있습니다. 데이터베이스 또는 화면 스크레퍼와 같은 다른 미들웨어 제품과 같은 백 엔드 리소스를 기다리는 경향이 있는 사이트에서는 특히 큰 이득을 얻습니다. IIS 5.0의 경우 ASP Thread Gating을 사용하는 것이AspProcessorThreadMax에 대한 최적 설정을 찾는 것보다 더 효과적입니다..

아래 Tuning IIS 튜닝을 참조하십시오

최적 구성 설정은 (기타 인자들 중)사용하는 응용 프로그램 코드, 이를 실행하는 하드웨어 그리고 클라이언트 작업 부하로 결정합니다. 최적 설정을 찾는 유일한 방법은 성능 테스트를 실시하는 것이며 다음 팁에서 설명합니다.

팁 27: 성능 테스트

앞서 언급했듯이, 성능은 하나의 기능입니다. 사이트의 성능을 향상시키려면, 성능 목표를 설정한 다음 목표에 도달할 때까지 조금씩 향상시키십시오. 프로젝트의 끝 부분을 위해 모든 성능 테스트를 아껴두지 마십시오. 종종, 프로젝트의 끝에서는 필요한 구조 변경을 하기에 너무 늦으며 따라서 고객을 실망시키게 됩니다. 성능 테스트를 일상 테스트의 부분으로 만드십시오. 성능 테스트는 ASP 페이지나 COM 개체와 같은 개별 구성 요소 또는 사이트 전체에 대해 수행할 수 있습니다.

많은 사람들이 하나의 브라우저를 사용하여 페이지를 요청함으로써 웹 사이트 성능을 테스트합니다. 이렇게 하면 사이트의 반응성에 대해 좋은 느낌을 받을 수 있지만 부하가 있는 상태에서 사이트의 성능을 평가하는 데 아무 도움이 못됩니다.

일반적으로 성능을 정확하게 측정하기 위해서는 전용 테스트 환경이 필요합니다. 이러한 환경에는 프로세서 속도, 프로세서 수, 메모리, 디스크, 네트워크 구성 등의 관점에서 프로덕션 하드웨어와 닮은 하드웨어가 있어야 합니다. 다음으로 동시 사용자의 수, 클라이언트의 요청 빈도, 그들이 열어보는 페이지의 형태 등 클라이언트의 작업 부하를 정의해야 합니다. 여러분의 사이트에서 실제적인 사용 데이터에 액세스가 없는 경우, 추정할 필요가 있습니다. 마지막으로, 예상한 클라이언트 작업 부하를 시뮬레이션할 수 있는 도구가 필요합니다. 이러한 도구를 구비하면 "N 명의 동시 사용자가 있는 경우 필요한 서버는 몇 대인가?"와 같은 질문에 답할 수 있습니다. 또한 병목현상을 무시하고 최적화를 위해 이를 공격 목표로 삼을 수 있습니다

 

 

28. 관련 리소스 링크를 읽어보십시오.

다음은 몇 가지 아주 유용한 성능 관련 리소스 링크들입니다. Developing Scalable Web Applications은 반드시 읽어보는 것이 좋습니다.

리소스

ASP 스크립트 최적화	IIS 조정	ADO 및 SQL Server
ASP 구성 요소 및 스레딩 모델	딕셔너리 구성 요소	세션 상태
성능 및 확장성	도구	문서
ASP 웹 사이트	ASP 스타일	XML

ASP 스크립트 최적화

Developing Scalable Web Applications

Got Any Cache? 저자: Nancy Winnick Cluts

Maximizing the Performance of Your Active Server Pages 저자: Nancy Winnick Cluts

15 Seconds: Performance Section

Enhancing Performance in ASP - Part I 저자: Wayne Plourde

When is Better Worse? Weighing the Technology Trade-Offs 저자: Nancy Winnick Cluts

Speed and Optimization Resources 저자: Charles Carroll

IIS 조정

The Art and Science of Web Server Tuning with Internet Information Services 5.0

Leveraging ASP in IIS 5.0 저자: J.D. Meier

Tuning IIS 4.0 for High Volume Sites 저자: Michael Stephenson

Tuning Internet Information Server Performance 저자: Mike Moore

Navigating the Maze of Settings for Web Server Performance Optimization 저자: Todd Wanke

Managing Internet Information Server 4.0 for Performance 저자: Hans Hugli

ADO 및 SQL Server

Top Ten Tips: Accessing SQL Through ADO and ASP 저자: J.D. Meier

Improve the Performance of your MDAC Application 저자: Suresh Kannan

Pooling in the Microsoft Data Access Components 저자: Leland Ahlbeck 및 Don Willits

SQL Server: Performance Benchmarks and Guides

Improving the Performance of Data Access Components with IIS 4.0 저자: Leland Ahlbeck

Microsoft Data Access Components (MDAC) and ActiveX Data Objects (ADO) Performance Tips 저자: Leland Ahlbeck

Microsoft SQL Server 7.0 Practical Performance Tuning and Optimization - The Server Perspective 저자: Damien Lindauer

Microsoft SQL Server 7.0 Practical Performance Tuning and Optimization - The Application Perspective 저자: Damien Lindauer

Accessing Recordsets over the Internet 저자: Dino Esposito

ASP 구성 요소 및 스레딩 모델

ASP Component Guidelines 저자: J.D. Meier

Q243548: INFO: Design Guidelines for VB Components under ASP

Threading Models Explained 저자: Nancy Winnick Cluts

So Happy Together? Using ActiveX components with Active Server Pages 저자: Nancy Winnick Cluts

Developing Active Server Components with ATL 저자: George Reilly

Agility in Server Components 저자: Neil Allain

Building High-Performance Middle-Tier Components with C++ 저자: Jon Flanders

Active Server Pages and COM Apartments 저자: Don Box

House of COM: Active Server Pages 저자: Don Box

House of COM: Contexts 저자: Don Box

House of COM: Performance Trade-offs of the Windows 2000 Component Execution Environment 저자: Don Box

Building COM Components That Take Full Advantage of Visual Basic and Scripting 저자: Ivo Salmre

Component Design Principles for MTS

딕셔너리 구성 요소

Creating a Page Cache Object 저자: Robert Coleridge

Abridging the Dictionary Object: The ASP Team Creates a Lookup-Table Object 저자: Robert Carter

Caprock Dictionary

Site Server Commerce Edition에는 딕셔너리 구성 요소가 들어 있습니다.

세션 상태

Q175167: HOWTO: Persisting Values Without Sessions

Q157906: HOWTO: How To Maintain State Across Pages with VBScript

XML-based Persistence Behaviors Fix Web Farm Headaches 저자: Aaron Skonnard

House of COM: Stateless Programming 저자: Don Box

성능 및 확장성

Blueprint for Building Web Sites Using the Microsoft Windows DNA Platform

Server Performance and Scalability Killers 저자: George Reilly

Microsoft Visual Studio Scalability Center

Fitch & Mather Stocks 2000

Tuning the FMStocks Application

High-Performance Visual Basic Apps 저자: Ken Spencer

Duwamish Books, Phase 4

Top Windows DNA Performance Mistakes and How to Prevent Them 저자: Gary Geiger 및 Jon Pulsipher

Building from Static HTML to High-Performance Web-Farms 저자: Shawn Bice

도구

Microsoft Web Application Stress Tool

I Can't Stress It Enough -- Load Test Your ASP Application 저자: J.D. Meier

Windows DNA Performance Kit

Monitoring Events in Distributed Applications Using Visual Studio Analyzer 저자: Mai-lan Tomsen

문서

Professional Active Server Pages 3.0, Wrox Press. (특히, Chapter 26:Optimizing ASP Performance, 저자: George Reilly 및 Matthew Gibbs 참조)

Microsoft Internet Information Services 5.0 Resource Guide(Windows 2000 Server Resource Kit와 함께 제공됨), Microsoft Press.

Microsoft Internet Information Server Resource Kit (for IIS 4.0), Microsoft Press.

Programming Distributed Applications with COM and Microsoft Visual Basic 6.0 저자: Ted Pattison, Microsoft Press.

Effective COM 저자: Don Box, Keith Brown, Tim Ewald, Chris Sells 및 Addison-Wesley.

Developing Web Usability: The Practice of Simplicity 저자: Jakob Nielsen, New Riders.

ASP 웹 사이트

Microsoft TechNet for IIS

LearnASP.com

4GuysFromRolla.com

15Seconds.com

AspToday.com

Asp101.com

AspLists.com. 여기에는 다음과 같은 특수 메일 목록이 들어 있습니다.

• Fast Code!
• ASP Advanced
• Not NewbieState Management
• Scalability
• Visual Basic Components
• XML
• C++/ATL Component Building

UseIt.com: Web Usability

ASP 스타일

ASP Best Practices 저자: George Reilly

ASP Quick Lessons 저자: Charles Carroll

Planning for ASP 저자: John Meade

ASP Guidelines 저자: J.D. Meier

XML

Inside XML Performance 저자: Chris Lovett

Inside MSXML3 Performance 저자: Chris Lovett

[출처] [본문스크랩] 성능 및 스타일 향상을 위한 25+ ASP 팁|작성자 수유산장

.