Microsoft가 권장하는 ASP 성능 최적화를 위한 28가지 규칙

성능이 특징입니다. 성능을 미리 설계해야 합니다. 그렇지 않으면 나중에 애플리케이션을 다시 작성해야 합니다. 즉, ASP(Active Server Pages) 응용 프로그램 성능을 최대화하기 위한 좋은 전략은 무엇입니까?

이 문서에서는 ASP 응용 프로그램과 VBScript(Visual Basic® Scripting Edition)를 최적화하는 기술을 설명합니다. 이 기사에서는 여러 가지 함정에 대해 설명합니다. 이 문서에 나열된 제안 사항은 http://www.microsoft.com 및 기타 사이트에서 테스트되었으며 그 결과는 매우 중요했습니다. 이 문서에서는 사용자가 VBScript 및/또는 JScript, ASP 응용 프로그램, ASP 세션 및 기타 ASP 고유 개체(요청, 응답 및 서버)를 포함한 ASP 개발에 대해 이미 기본적으로 이해하고 있다고 가정합니다.

일반적으로 ASP 성능은 주로 ASP 코드 자체 이외의 여러 요소에 따라 달라집니다. 하나의 기사에 모든 정보를 나열하는 대신 기사 마지막 부분에 성능 관련 리소스를 나열합니다. 이러한 링크는 ADO(ActiveX® Data Objects), COM(구성 요소 개체 모델), 데이터베이스 및 IIS(Internet Information Server) 구성을 포함하여 ASP 및 비ASP 항목을 다룹니다. 다음은 우리가 가장 좋아하는 링크 중 일부입니다. 꼭 확인해 보세요.

팁 1: 자주 사용하는 데이터를 웹 서버에 캐시하세요.

일반적인 ASP 페이지는 백엔드 데이터 저장소에서 데이터를 검색한 다음 그 결과를 HTML(Hypertext Markup Language)로 변환합니다. 데이터베이스 속도에 관계없이 메모리에서 데이터를 검색하는 것은 백엔드 데이터 저장소에서 데이터를 검색하는 것보다 항상 훨씬 빠릅니다. 로컬 하드 드라이브에서 데이터를 읽는 것이 일반적으로 데이터베이스에서 데이터를 검색하는 것보다 빠릅니다. 따라서 웹 서버(메모리나 디스크에 저장됨)에 데이터를 캐시하면 성능이 향상되는 경우가 많습니다.

캐싱은 공간을 시간과 거래하는 전통적인 방법입니다. 올바른 콘텐츠를 캐시하면 성능이 크게 향상되는 것을 확인할 수 있습니다. 캐싱이 효과적이려면 자주 재사용되는 데이터를 저장해야 하며, 이 데이터를 다시 계산하려면 (적당히) 큰 오버헤드가 필요합니다. 캐시가 모두 오래된 데이터인 경우 메모리 낭비가 발생합니다.

자주 변경되지 않는 데이터는 시간이 지남에 따라 해당 데이터를 데이터베이스와 동기화하는 것에 대해 걱정할 필요가 없으므로 캐싱에 적합한 대상입니다. 콤보 상자 목록, 참조 테이블, DHTML 조각, XML(Extensible Markup Language) 문자열, 메뉴 항목 및 사이트 구성 변수(DSN(데이터 원본 이름), IP(인터넷 프로토콜) 주소 및 웹 경로 포함)은 모두 좋은 캐시입니다. 콘텐츠. 데이터 자체를 캐시하지 않고도 데이터의 "표현"을 캐시할 수 있습니다. ASP 페이지가 거의 변경되지 않고 캐시하는 데 비용이 많이 드는 경우(예: 전체 제품 카탈로그) 각 요청에 대한 응답으로 HTML을 다시 표시하는 대신 미리 HTML을 생성하는 것을 고려해야 합니다.

데이터는 어디에 캐시되어야 하며 어떤 캐싱 전략이 있습니까? 일반적으로 데이터는 웹 서버의 메모리나 디스크에 캐시됩니다. 다음 두 팁에서는 두 가지 방법을 모두 다룹니다.

팁 2: 자주 사용되는 데이터를 애플리케이션 또는 세션 개체에 캐시하세요.

ASP 애플리케이션 및 세션 개체는 메모리에 데이터를 캐싱하기 위한 편리한 컨테이너를 제공합니다. Application 및 Session 개체에 데이터를 할당할 수 있으며 데이터는 HTTP 호출 사이에 메모리에 유지됩니다. 세션 데이터는 각 사용자별로 별도로 저장되는 반면, 애플리케이션 데이터는 모든 사용자가 공유합니다.

데이터는 언제 애플리케이션이나 세션에 로드되어야 합니까? 일반적으로 데이터는 애플리케이션이나 세션이 시작될 때 로드됩니다. 애플리케이션 또는 세션 시작 중에 데이터를 로드하려면 각각 Application_OnStart() 또는 Session_OnStart()에 적절한 코드를 추가하십시오. 이러한 기능은 Global.asa에 있어야 하며 그렇지 않은 경우 추가할 수 있습니다. 이 데이터는 처음 필요할 때 로드할 수도 있습니다. 이렇게 하려면 ASP 페이지에 일부 코드를 추가하거나 재사용 가능한 스크립트 함수를 작성하여 데이터가 있는지 확인하고, 없으면 데이터를 로드합니다. 이는 "지연 평가"라고 불리는 전통적인 성능 기술입니다. 즉, 필요하다는 것을 알기 전까지는 값을 계산하지 않습니다. 예:

<%
함수 GetEmploymentStatusList
희미한 d
d = 지원서(?EmploymentStatusList?)
만약 d = ??그러면
' FetchEmploymentStatusList 함수(표시되지 않음)
' DB에서 데이터를 가져오고 배열을 반환합니다.
d = FetchEmploymentStatusList()
지원서(?EmploymentStatusList?) = d
종료 조건
GetEmploymentStatusList = d
기능 종료
%>
필요한 각 데이터 블록에 대해 유사한 기능을 작성할 수 있습니다.

데이터는 어떤 형식으로 저장되어야 합니까? 모든 스크립트 변수는 변형 유형이므로 모든 변형 유형을 저장할 수 있습니다. 예를 들어 문자열, 정수 또는 배열을 저장할 수 있습니다. 일반적으로 이러한 변수 유형 중 하나에 ADO 레코드 세트의 내용을 저장합니다. ADO 레코드 집합에서 데이터를 가져오려면 데이터를 한 번에 한 필드씩 VBScript 변수에 수동으로 복사하면 됩니다. ADO 레코드 집합 지속성 함수 GetRows(), GetString() 또는 Save()(ADO 2.5) 중 하나를 사용하는 것이 더 빠르고 쉽습니다. 자세한 내용은 이 기사의 범위를 벗어나지만 다음은 GetRows()를 사용하여 레코드 세트 데이터 배열을 반환하는 함수의 예입니다.

' 레코드 세트 가져오기, 배열로 반환
함수 FetchEmploymentStatusList
딤머
rs = CreateObject(?ADODB.Recordset?) 설정
rs.Open ? EmployeeStatus에서 StatusName, StatusID를 선택합니까?, _
?dsn=직원;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() ? 데이터를 배열로 반환합니다.
RS.닫기
설정자=아무것도 없음
End Function은

HTML을 배열 대신 목록으로 캐시하여 위의 예를 더욱 향상시킵니다. 다음은 간단한 예입니다.

' 레코드세트 가져오기, HTML 옵션 목록으로 반환
함수 FetchEmploymentStatusList
Dim rs, fldName, s
rs = CreateObject(?ADODB.Recordset?) 설정
rs.Open ? EmployeeStatus에서 StatusName, StatusID를 선택합니까?, _
?dsn=직원;uid=sa;pwd=;?
s = ?<이름 선택=??EmploymentStatus??>?
Set fldName = rs.Fields(?StatusName?) ' ADO 필드 바인딩
rs.EOF까지 수행
' 다음 줄은 문자열 연결 금지를 위반합니다.
'하지만 캐시를 구축 중이므로 괜찮습니다.
s = s & ? <옵션>? & fldName & ?</옵션>?
rs.이동다음
고리
s = s & ?</select>? & vbCrLf
RS.닫기
Set rs = Nothing ' 조기 릴리스 참조
FetchEmploymentStatusList = s ' 데이터를 문자열로 반환
기능 종료
적절한 조건에서 ADO 레코드 집합 자체는 응용 프로그램 또는 세션 범위에 캐시될 수 있습니다. 두 가지 주의 사항이 있습니다.

ADO는 자유 스레드로 표시되어야 하며 연결이 끊긴 레코드 집합을 사용해야 합니다.
이러한 두 가지 요구 사항이 보장되지 않으면 ADO 레코드 집합을 캐시하지 마십시오. 다음 "비민첩한 구성 요소" 및 "연결 캐시 안 함" 팁에서는 COM 개체를 응용 프로그램 또는 세션 범위에 저장할 때의 위험성에 대해 논의합니다.

애플리케이션 또는 세션 범위에 데이터를 저장하면 데이터는 프로그래밍 방식으로 변경하거나 세션이 만료되거나 웹 애플리케이션이 다시 시작될 때까지 해당 위치에 유지됩니다. 데이터를 업데이트해야 하면 어떻게 되나요? 응용 프로그램 데이터를 수동으로 강제로 업데이트하려면 관리자 전용 ASP 페이지에 액세스하여 데이터를 업데이트하면 됩니다. 또는 함수를 통해 정기적으로 데이터를 자동으로 새로 고칠 수도 있습니다. 다음 예에서는 캐시된 데이터가 포함된 타임스탬프를 저장하고 일정 기간이 지나면 데이터를 새로 고칩니다.

<%
' 오류 처리가 표시되지 않습니다...
Const UPDATE_INTERVAL = 300 ' 새로 고침 간격(초)

' 고용 상태 목록을 반환하는 함수
함수 GetEmploymentStatusList
업데이트고용상태
GetEmploymentStatusList = 애플리케이션(?EmploymentStatusList?)
End Function

' 캐시된 데이터를 주기적으로 업데이트
하위 업데이트EmploymentStatusList
희미한 d, strLastUpdate
strLastUpdate = 애플리케이션(?LastUpdate?)
(strLastUpdate = ??) 또는 _인 경우
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) Then

' 참고: 두 개 이상의 호출이 여기에 들어올 수 있습니다. 이는 괜찮으며 간단합니다.
' 몇 가지 불필요한 가져오기가 발생합니다(이에 대한 해결 방법이 있음)

' FetchEmploymentStatusList 함수(표시되지 않음)
' DB에서 데이터를 가져오고 배열을 반환합니다.
d = FetchEmploymentStatusList()

' Application 객체를 업데이트합니다. Application.Lock()
' 일관된 데이터를 보장하기 위해
응용프로그램.잠금
Application(?EmploymentStatusList?) = 이벤트
애플리케이션(?LastUpdate?) = CStr(현재)
응용 프로그램.잠금 해제
종료 조건
서브 끝
예제가 포함된 World's Fastest ListBox with Application Data를 참조하세요.

Session 또는 Application 객체에 큰 배열을 캐싱하는 것은 좋은 습관이 아닙니다. 스크립팅 언어의 구문에서는 배열의 요소에 액세스하기 전에 전체 배열을 임시로 복사해야 합니다. 예를 들어, 미국 우편번호를 Application 개체의 지역 기상 관측소에 매핑하는 100,000개 요소로 구성된 문자열 배열을 캐시하는 경우 ASP는 먼저 100,000개 기상 관측소를 모두 임시 배열에 복사해야 합니다. 그런 다음에만 문자열을 추출할 수 있습니다. 이 경우 기상 관측소를 저장하는 사용자 정의 방법으로 사용자 정의 구성 요소를 구축하거나 사전 구성 요소를 사용하는 것이 더 좋습니다.

또 다른 경고는 아기를 목욕물과 함께 버리지 마십시오. 배열은 빠르게 검색되어 인접한 키 데이터 쌍으로 메모리에 저장될 수 있습니다. 사전 인덱싱은 배열 인덱싱보다 훨씬 느립니다. 상황에 따라 최상의 성능을 제공하는 데이터 구조를 선택해야 합니다.

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

때때로 메모리에 캐시하기에는 데이터가 너무 많을 수 있습니다. "너무 많다"는 것은 소비하려는 메모리 양, 캐시해야 하는 항목 수, 해당 항목을 검색하려는 빈도에 따라 다르다는 의미일 뿐입니다. 어떤 경우든 데이터가 메모리에 캐시하기에는 너무 많으면 웹 서버의 하드 드라이브에 데이터를 텍스트 또는 XML 파일로 캐시하는 것이 좋습니다. 데이터를 디스크와 메모리에 동시에 캐시하여 사이트에 가장 적합한 캐싱 전략을 설정할 수 있습니다.

단일 ASP 페이지의 성능을 측정할 때 디스크에서 데이터를 검색하는 것이 데이터베이스에서 데이터를 검색하는 것보다 반드시 빠르지는 않을 수 있습니다. 그러나 캐싱은 데이터베이스와 네트워크의 부하를 줄여줍니다. 부하가 심한 경우 전체 처리량을 크게 향상시킬 수 있습니다. 이는 비용이 많이 드는 쿼리(예: 다중 테이블 조인 또는 복합 저장 프로시저) 또는 대규모 결과 집합의 결과를 캐싱할 때 매우 효과적입니다. 언제나 그렇듯이 여러 옵션의 장단점을 테스트해 보세요.

ASP와 COM은 디스크 기반 캐싱 솔루션을 설정하기 위한 도구를 제공합니다. ADO 레코드 집합 Save() 및 Open() 함수는 디스크에서 레코드 집합을 저장하고 로드합니다. 이러한 메서드를 사용하면 Application 개체에 코드를 작성하는 대신 파일의 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 개체를 응용 프로그램이나 세션 개체에 캐시하는 경향이 있습니다. 안타깝게도 많은 COM 개체(Visual Basic 6.0 이하로 작성된 모든 개체 포함)는 Application 또는 Session 개체에 저장할 때 심각한 병목 현상을 일으킵니다.

특히, Agile이 아닌 구성 요소가 Session 또는 Application 개체에 캐시되면 성능 병목 현상이 발생합니다. 민첩한 구성 요소는 FTM(자유 스레드 마샬러)을 집계하는 ThreadingModel=Both로 표시된 구성 요소 또는 ThreadingModel=Neutral로 표시된 구성 요소입니다. (중립 모델은 Windows® 2000 및 COM+에 새로 추가되었습니다.) 다음 구성 요소는 Agile이 아닙니다.

자유 스레드 구성 요소(FTM을 집계하지 않는 경우).
아파트 스레드 구성 요소.
단일 스레드 구성 요소.
구성된 구성 요소(MTS(Microsoft Transaction Server)/COM+ 라이브러리 및 서버 패키지/응용 프로그램)는 중립 스레드가 아니면 민첩하지 않습니다. 아파트 스레드 구성 요소 및 기타 비 Agile 구성 요소는 페이지 범위에 가장 적합합니다. 즉, 단일 ASP 페이지에서 생성 및 삭제됩니다.

IIS 4.0에서는 ThreadingModel=Both로 표시된 구성 요소가 민첩한 것으로 간주됩니다. IIS 5.0에서는 이것만으로는 충분하지 않습니다. 구성 요소는 모두로 표시되어야 할 뿐만 아니라 집계된 FTM이어야 합니다. 민첩성에 관한 기사에서는 액티브 템플릿 라이브러리에 작성된 C++ 구성 요소로 FTM을 집계하는 방법을 설명합니다. 구성 요소가 인터페이스 포인터를 캐시하는 경우 해당 포인터 자체는 Agile이거나 COM GIT(공용 인터페이스 테이블)에 저장되어야 합니다. FTM을 집계하기 위해 Both 스레드 구성 요소를 다시 컴파일할 수 없는 경우 해당 구성 요소를 ThreadingModel=Neutral로 표시할 수 있습니다. 또는 IIS에서 민첩성 검사를 수행하지 않도록 하려면(따라서 비민첩 구성 요소가 응용 프로그램 또는 세션 범위에 저장되도록 허용할 수 있음) 메타베이스에서 AspTrackThreadingModel을 True로 설정할 수 있습니다. AspTrackThreadingModel을 변경하는 것은 권장되지 않습니다.

Server.CreateObject를 사용하여 생성된 비 Agile 구성 요소를 Application 개체에 저장하려는 경우 IIS 5.0에서는 오류가 발생합니다. Global.asa에서 <object runat=server range=application ...>을 사용하면 이 오류를 방지할 수 있지만 아래 설명된 대로 풀링 및 직렬화로 이어질 수 있으므로 권장되지 않습니다.

Agile이 아닌 구성 요소를 캐시하면 어떻게 되나요? 세션 개체에 캐시된 비 Agile 구성 요소는 세션을 ASP 작업자 스레드에 잠급니다. ASP는 요청을 처리하기 위해 작업자 스레드 풀을 유지 관리합니다. 일반적으로 새 요청은 항상 사용 가능한 첫 번째 작업자 스레드에 의해 처리됩니다. 세션이 스레드에 잠겨 있으면 요청은 연결된 스레드를 사용할 수 있을 때까지 기다려야 합니다. 다음은 도움이 될 수 있는 비유입니다. 슈퍼마켓에 가서 몇 가지 품목을 골라 계산대 #_3에서 결제합니다. 그 이후에는 해당 슈퍼마켓에서 품목 비용을 지불할 때마다 다른 계산대에 대기열이 적거나 없더라도 항상 계산대 #_3에서 지불해야 합니다.

비민첩한 구성 요소를 애플리케이션 범위에 저장하면 성능에 훨씬 더 나쁜 영향을 미칩니다. ASP는 응용 프로그램 범위에 저장된 비 Agile 구성 요소를 실행하기 위해 특수 스레드를 만들어야 합니다. 이로 인해 두 가지 결과가 발생합니다. 모든 통화는 이 스레드로 유입되어야 하며 모든 통화는 대기열에 추가됩니다. "풀링"은 매개 변수가 메모리의 공유 영역에 저장되어야 함을 의미합니다. 특수 스레드에 대한 비용이 많이 드는 컨텍스트 전환을 수행하고 결과를 공유 영역으로 풀링합니다. 원본 스레드에. "직렬화"는 한 번에 하나의 메서드만 실행됨을 의미합니다. 두 개의 서로 다른 ASP 작업자 스레드는 공유 구성 요소에서 여러 메서드를 동시에 실행할 수 없습니다. 이는 특히 다중 프로세서 컴퓨터에서 동시성을 제거합니다. 설상가상으로 Agile 애플리케이션 범위가 아닌 모든 구성 요소는 단일 스레드(호스트 STA)를 공유하므로 직렬화의 영향이 훨씬 더 중요합니다.

어떻게 해야 하나요? 다음은 몇 가지 일반적인 규칙입니다. Visual Basic(6.0) 이전 버전을 사용하여 개체를 작성하는 경우 해당 개체를 Application 또는 Session 개체에 캐시하지 마십시오. 개체의 스레딩 모델을 모른다면 캐시하지 마세요. Agile이 아닌 개체를 캐시하지 말고 대신 각 페이지에서 만들고 릴리스하세요. 개체는 ASP 작업자 스레드에서 직접 실행되므로 풀링이나 직렬화가 없습니다. COM 개체가 IIS 서버에서 실행 중인 경우 초기화 및 삭제에 오랜 시간이 걸리지 않으면 성능이 허용됩니다. 단일 스레드 개체는 이런 방식으로 사용하면 안 됩니다. 주의하세요. VB는 단일 스레드 개체를 만들 수 있습니다! 이와 같이 단일 스레드 개체(예: Microsoft Excel 스프레드시트)를 사용해야 하는 경우 높은 처리량을 기대하지 마십시오.

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

경고 Microsoft Access를 데이터베이스로 사용하는 경우 ADO를 자유 스레드로 표시하면 안 됩니다. ADO 레코드 집합의 연결도 끊어야 합니다. 일반적으로 사이트에서 ADO 구성을 제어하지 않는 경우(예를 들어 자체 구성을 관리하는 고객에게 웹 응용 프로그램을 판매하는 독립 소프트웨어 공급업체[ISV]인 경우) 레코드 세트를 캐시하지 않는 것이 가장 좋습니다.

사전 구성 요소도 Agile 개체입니다. LookupTable은 데이터 파일에서 데이터를 로드하며 콤보 상자 데이터 및 구성 정보에 사용될 수 있습니다. Duwamish Books의 PageCache 개체는 Caprock Dictionary와 마찬가지로 사전 구문을 제공합니다. 이러한 개체 또는 해당 개체에서 파생된 개체는 효과적인 캐싱 전략의 기초를 형성할 수 있습니다. Scripting.Dictionary 개체는 Agile이 아니므로 애플리케이션 또는 세션 범위에 저장하면 안 됩니다.

팁 5:

ADO 연결을 캐싱하는 것은 일반적으로 좋지 않은 전략입니다. Connection 개체가 Application 개체에 저장되고 모든 페이지에서 사용되는 경우 모든 페이지가 이 연결을 위해 경쟁합니다. 연결 개체가 ASP 세션 개체에 저장되면 각 사용자에 대해 데이터베이스 연결이 생성됩니다. 이렇게 하면 연결 풀링의 이점이 무효화되고 웹 서버와 데이터베이스에 불필요한 부담이 가해집니다.

데이터베이스 연결을 캐싱하는 대신 ADO를 사용하는 각 ASP 페이지에서 ADO 개체를 만들고 삭제할 수 있습니다. IIS에는 데이터베이스 연결 풀링이 내장되어 있으므로 이는 효율적입니다. 보다 정확하게 말하면 IIS는 자동으로 OLEDB 및 ODBC 연결 풀링을 활성화합니다. 이렇게 하면 모든 페이지에서 생성 및 삭제된 연결이 유효해집니다.

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

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

' 데이터로 레코드세트 채우기
rs.Open strQuery, strProv

' 이제 데이터 공급자 및 데이터 소스에서 레코드 세트의 연결을 끊습니다.
rs.ActiveConnection = 아무것도 ' 2단계
연결 풀링에 대한 자세한 내용은 ADO 및 SQL Server 참조 자료에서 확인할 수 있습니다.

팁 6: 세션 개체를 적절하게 사용하십시오.

이제 응용 프로그램과 세션에서 캐싱의 이점을 논의했으므로 세션 개체 사용을 피하는 방법에 대해 논의해 보겠습니다. 아래에서 설명하는 것처럼 Session은 사용량이 많은 사이트에서 사용할 때 몇 가지 단점이 있습니다. "바쁨"은 일반적으로 초당 수백 페이지 또는 수천 명의 동시 사용자가 필요한 사이트를 의미합니다. 이 팁은 수평적으로 확장해야 하는 사이트, 즉 로드를 처리하거나 내결함성을 달성하기 위해 여러 서버를 활용하는 사이트에 더욱 중요합니다. 인트라넷 사이트와 같은 소규모 사이트의 경우 세션이 제공하는 이점을 실현하려면 시스템 오버헤드가 필연적으로 증가합니다.

즉, ASP는 웹 서버에 액세스하는 각 사용자에 대해 자동으로 세션을 만듭니다. 각 세션에는 약 10KB의 메모리 오버헤드가 필요하므로(가장 중요한 것은 데이터가 세션에 저장된다는 점입니다) 이로 인해 모든 요청이 느려집니다. 세션은 구성된 제한 시간(일반적으로 20분)이 경과할 때까지 유효한 상태로 유지됩니다.

Session의 가장 큰 문제는 성능이 아니라 확장성입니다. 세션은 여러 웹 서버에 걸쳐 있을 수 없습니다. 한 서버에서 세션이 생성되면 해당 데이터는 그대로 유지됩니다. 즉, 웹 서버 팜에서 세션을 사용하는 경우 항상 각 사용자 요청을 사용자의 세션이 있는 서버로 보내는 정책을 설계해야 합니다. 이를 웹 서버에 사용자를 "접속"한다고 합니다. "고정 세션"이라는 용어는 여기서 파생되었습니다. 웹 서버가 충돌하는 경우 세션이 디스크에 고정되어 있지 않기 때문에 "고정된" 사용자는 세션 상태를 잃게 됩니다.

고정 세션을 달성하기 위한 전략에는 하드웨어 및 소프트웨어 솔루션이 포함됩니다. Windows 2000 Advanced Server의 네트워크 로드 균형 조정 및 Cisco Local Director와 같은 솔루션은 어느 정도의 확장성을 희생하더라도 고정 세션을 구현할 수 있습니다. 이러한 솔루션은 불완전합니다. 현재 자체 소프트웨어 솔루션을 배포하는 것은 권장되지 않습니다(우리는 ISAPI 필터 및 URL 변환 등을 사용했습니다).

또한 응용 프로그램 개체는 여러 서버에 걸쳐 있지 않습니다. 웹 서버 팜 전체에서 응용 프로그램 데이터를 공유하고 업데이트해야 하는 경우 백엔드 데이터베이스를 사용해야 합니다. 그러나 읽기 전용 응용 프로그램 데이터는 웹 서버 팜에서 여전히 유용합니다.

대부분의 업무상 중요한 사이트에는 가동 시간을 늘리기 위해(장애 조치 및 서버 유지 관리를 처리하기 위해) 최소한 두 대 이상의 웹 서버가 필요합니다. 따라서 업무상 중요한 응용 프로그램을 설계할 때는 "고정 세션"을 구현하거나 단일 웹 서버에 사용자 상태를 저장하는 세션 및 기타 상태 관리 기술을 사용하지 않아야 합니다.

세션을 사용하지 않는 경우 세션을 닫으십시오. 인터넷 서비스 관리자를 통해 응용 프로그램에 대해 이 작업을 수행할 수 있습니다(ISM 설명서 참조). 세션을 사용하기로 결정한 경우 성능에 미치는 영향을 완화할 수 있는 방법이 있습니다.

세션이 필요하지 않은 콘텐츠(예: 도움말 화면, 방문자 영역 등)를 세션이 닫힌 다른 ASP 응용 프로그램으로 이동할 수 있습니다. ASP 페이지 상단에 있는 다음 지시문을 사용하여 해당 페이지에 더 이상 Session 개체가 필요하지 않다는 것을 페이지 단위로 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&reg; 4.0/IIS 4.0에 비해 Windows 2000/IIS 5.0의 스크립팅 및 ADO 성능이 크게 향상되었습니다. 따라서 IIS 5.0이 도입되면서 ASP 코드에 비해 컴파일된 코드의 성능 이점이 감소했습니다.

ASP에서 COM을 사용할 때의 장점과 단점에 대한 자세한 설명은 ASP 구성 요소 지침 및 Microsoft Visual Basic 6.0을 사용한 분산 응용 프로그램 프로그래밍을 참조하세요. COM 구성 요소를 배포하는 경우 부하가 걸린 상태에서 테스트하는 것이 특히 중요합니다. 실제로 모든 ASP 응용 프로그램은 당연히 로드 테스트를 거쳐야 합니다.

팁 8: 나중에 리소스를 확보하고 더 일찍 릴리스하십시오.

참고할 수 있는 작은 팁이 있습니다. 일반적으로 말하면 리소스는 나중에 확보하고 일찍 공개하는 것이 좋습니다. 이는 COM 개체는 물론 파일 핸들 및 기타 리소스에도 적용됩니다.

이 최적화 방법은 주로 ADO 연결 및 레코드 집합에 사용됩니다. 예를 들어 테이블과 해당 데이터를 표시한 후 레코드세트 작업을 마치면 페이지가 끝날 때까지 기다리지 말고 즉시 해제해야 합니다. VBScript 변수를 Nothing으로 설정하는 것이 가장 좋습니다. 레코드세트가 범위를 벗어나지 않도록 하세요. 또한 관련 Command 또는 Connection 개체를 모두 해제합니다(레코드 세트 또는 연결을 = Nothing으로 설정하기 전에 Close()를 호출하는 것을 잊지 마십시오). 이렇게 하면 데이터베이스가 리소스를 준비하는 데 필요한 시간이 단축되고 가능한 한 빨리 데이터베이스 연결을 연결 풀에 해제합니다.

팁 9: Out-of-Process 실행은 안정성을 위해 성능을 절충합니다.

ASP와 MTS/COM+에는 모두 안정성과 성능을 절충할 수 있는 구성 옵션이 있습니다. 애플리케이션을 구축하고 배포할 때 두 가지 모두의 성능 균형을 맞추는 방법을 알아야 합니다.

ASP 옵션은 세 가지 방법 중 하나로 실행되도록 ASP 응용 프로그램을 구성합니다. IIS 5.0에서는 이러한 옵션을 설명하기 위해 "격리 수준"이라는 용어가 도입되었습니다. 세 가지 격리 수준은 낮은 수준, 중간 수준, 높은 수준(

낮은 수준 격리)입니다. 이는 모든 버전의 IIS에서 지원되며 가장 빠릅니다. 기본 IIS 프로세스인 Inetinfo.exe에서 ASP를 실행합니다. ASP 응용 프로그램이 충돌하면 IIS도 충돌합니다. (IIS 4.0에서 IIS를 다시 시작하려면 웹 사이트 관리자는 InetMon과 같은 도구를 사용하여 사이트를 모니터링하고 서버에 오류가 발생할 경우 서버를 다시 시작할 수 있는 배치 파일을 활성화해야 합니다. IIS 5.0에는 실패한 서버를 자동으로 다시 시작하는 안정적인 다시 시작 방법이 도입되었습니다. ).
중간 격리. IIS 5.0에는 ASP가 IIS 프로세스 외부에서 실행되기 때문에 Out-of-Process 수준이라고 하는 이 새로운 수준이 도입되었습니다. 중간 격리에서는 중간 격리로 실행되도록 구성된 모든 ASP 응용 프로그램이 프로세스 공간을 공유합니다. 이렇게 하면 단일 서버에서 여러 Out-of-Process ASP 응용 프로그램을 실행하는 데 필요한 프로세스 수가 줄어듭니다. 중간 격리는 IIS 5.0의 기본 격리 수준입니다.
고급 격리. 이 수준은 IIS 4.0 및 IIS 5.0에서 지원되며 고급 격리도 out-of-process입니다. ASP가 충돌하더라도 웹 서버는 충돌하지 않습니다. ASP 응용 프로그램은 다음에 ASP 요청이 이루어지면 자동으로 다시 시작됩니다. 고급 격리에서는 고급 격리로 실행되도록 구성된 각 ASP 응용 프로그램이 자체 프로세스 공간에서 실행됩니다. 이렇게 하면 ASP 응용 프로그램이 서로 간섭하지 않도록 보호할 수 있습니다. 단점은 각 ASP 응용 프로그램마다 별도의 프로세스가 필요하다는 것입니다. 단일 서버에서 많은 애플리케이션을 실행해야 하는 경우 시스템 오버헤드가 크게 증가합니다.
어떤 옵션이 가장 좋나요? IIS 4.0에서는 프로세스 부족으로 인해 성능이 크게 저하됩니다. IIS 5.0에서는 ASP 응용 프로그램을 프로세스 외부에서 실행함으로써 발생하는 오버헤드를 최소화하기 위해 많은 개선이 이루어졌습니다. 실제로 대부분의 테스트에서 IIS 5.0의 ASP out-of-process 응용 프로그램은 IIS 4.0의 in-process 응용 프로그램보다 더 빠르게 실행되었습니다. 그럼에도 불구하고 두 플랫폼 모두에서 in-process(낮은 격리 수준)가 가장 잘 수행됩니다. 그러나 액세스 속도가 상대적으로 낮거나 최대 처리량이 낮은 경우 낮은 격리 수준의 이점은 덜 분명합니다. 따라서 낮은 격리 수준 설정은 웹 서버당 초당 수백 또는 수천 페이지가 필요한 경우에만 필요할 수 있습니다. 항상 그렇듯이 여러 구성을 테스트하여 어떤 절충안을 만들고 싶은지 결정하십시오.

ASP Out-of-Process 응용 프로그램(중간 또는 높은 격리)을 실행하면 NT4의 MTS와 Windows 2000의 COM+에서 실행됩니다. 즉, NT4에서는 Mtx.exe에서 실행되고 Windows 2000에서는 DllHost.exe에서 실행됩니다. 작업 관리자에서 실행 중인 이러한 프로세스를 볼 수 있습니다. 또한 IIS가 Out-of-Process ASP 응용 프로그램에 대해 MTS 패키지 또는 COM+ 응용 프로그램을 구성하는 방법도 확인할 수 있습니다.

COM 옵션 COM 구성 요소에는 ASP 옵션과 완전히 유사하지는 않지만 세 가지 구성 옵션도 있습니다. COM 구성 요소는 "구성 해제"되거나, 라이브러리 응용 프로그램으로 구성되거나, 서버 응용 프로그램으로 구성될 수 있습니다. "구성되지 않음"은 구성 요소가 COM+에 등록되지 않았음을 의미합니다. 구성 요소는 호출 프로그램의 프로세스 공간에서 실행됩니다. 즉, "진행 중"입니다. 라이브러리 응용 프로그램도 진행 중이지만 보안, 트랜잭션 및 컨텍스트 지원을 포함한 COM+ 서비스를 사용합니다. 서버 애플리케이션은 자체 프로세스 공간 내에서 실행되도록 구성됩니다.

구성되지 않은 구성 요소는 라이브러리 응용 프로그램에 비해 약간의 이점이 있음을 알 수 있습니다. 라이브러리 응용 프로그램은 서버 응용 프로그램보다 성능상의 이점이 더 큽니다. 이는 라이브러리 응용 프로그램이 ASP와 동일한 프로세스에서 실행되는 반면 서버 응용 프로그램은 자체 프로세스에서 실행되기 때문입니다. 프로세스 간 호출은 프로세스 내 호출보다 비용이 더 많이 듭니다. 또한 프로세스 간에 레코드세트와 같은 데이터를 전달할 때 모든 데이터는 두 프로세스 간에 복사되어야 합니다.

덫! COM 서버 응용 프로그램을 사용할 때 ASP와 COM 간에 개체를 전달하는 경우 개체가 "값별 번들" 또는 MBV를 수행하는지 확인하세요. MBV를 수행하는 개체는 한 프로세스에서 다른 프로세스로 자신을 복사합니다. 이는 개체가 여전히 작성자의 프로세스에 있고 다른 프로세스에서 개체를 사용하기 위해 생성 프로세스를 반복적으로 호출하는 접근 방식보다 낫습니다. 연결이 끊긴 ADO 레코드 집합은 "값에 따라 클러스터링"되지만 연결된 레코드 집합은 그렇지 않습니다. Scripting.Dictionary는 MBV를 수행하지 않으며 프로세스 간에 전달되지 않습니다. 마지막으로 VB 프로그래머를 위한 참고 사항: MBV는 ByVal 매개 변수를 전달하여 얻을 수 없습니다. MBV는 원래 구성 요소 작성자가 수행합니다.

무엇을 해야 할까요?
성능과 안정성의 균형을 유지하는 합리적인 구성을 제안해 달라는 요청을 받으면 다음과 같을 것입니다.

IIS 4.0에서는 ASP 낮은 격리 수준을 사용하고 MTS 서버 패키지를 사용합니다.
IIS 5.0에서는 ASP의 중간 격리 수준을 사용하고 COM+ 라이브러리 응용 프로그램을 사용하십시오.
이는 매우 일반적인 원칙입니다. 호스팅 회사는 일반적으로 중간 또는 높은 격리 수준에서 ASP를 실행하는 반면 단일 목적 웹 서버는 낮은 격리 수준에서 실행될 수 있습니다. 장단점을 비교하고 귀하의 요구 사항에 더 적합한 구성을 스스로 결정하십시오.

팁 10 : 명시 적 옵션

옵션 사용 옵션은 .ASP 파일에 사용해야합니다. 이 지침은 .asp 파일의 상단에 배치되어 개발자가 모든 변수를 사용할 수 있도록 선언하도록 강요합니다. 많은 프로그래머는이 메소드가 변수 이름을 착각하고 실수로 새로운 변수를 생성 할 가능성을 피하고 myxlmstring = ....

아마도 더 중요한 것은 선언 된 변수가 선언되지 않은 변수보다 빠릅니다. 이런 식으로, 스크립트가 런타임에 선언되지 않은 변수를 사용할 때마다 이름별로 참조됩니다. 반면, 변수는 컴파일 타임 또는 실행 시간에 순서대로 선언됩니다. 이제부터 선언 된 변수는이 순서로 참조됩니다. 옵션 명시 적 힘 변수 선언이 있으므로 모든 변수가 선언되도록하므로 액세스가 빠릅니다.

팁 11 : 서브 루틴 및 기능에서 로컬 변수를 사용하십시오.

로컬 변수는 서브 루틴 및 기능 내에서 선언 된 변수입니다. 함수 또는 서브 루틴 내에서 로컬 가변 액세스는 전역 가변 액세스보다 빠릅니다. 로컬 변수를 사용하면 코드가 더 명확 해지므로 가능한 한 로컬 변수를 사용해야합니다.

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

ASP에서 COM 객체에 액세스 할 때 자주 사용되는 객체 데이터를 스크립트 변수로 복사해야합니다. 이렇게하면 COM 메소드 호출이 줄어 듭니다. 이는 스크립트 변수에 액세스하는 것과 비교하여 비교적 비쌉니다. 이 기술은 또한 컬렉션 및 사전 개체에 액세스 할 때 고가의 조회를 줄입니다.

일반적으로 객체 데이터에 두 번 이상 액세스 할 계획이라면 데이터를 스크립트 변수에 넣어야합니다. 이 최적화의 주요 대상은 요청 변수 (양식 및 쿼리 스트링 변수)입니다. 예를 들어, 귀하의 사이트는 userId라는 쿼리 스트링 변수를 전달할 수 있습니다. 이 userID가 특정 페이지에서 12 번 참조되었다고 가정 해 봅시다. 호출 요청 (? userId?) 12 회 대신 ASP 페이지 상단의 변수에 userID를 할당 할 수 있습니다. 그런 다음 페이지 전체에 해당 변수를 사용하십시오. 11 COM 메소드 호출을 저장합니다.

실제로 COM 속성이나 방법에 액세스하는 것은 비용이 많이 들지 않습니다. 다음은 상당히 일반적인 코드의 예입니다 (구문 적으로 말하면) :

foo.bar.blah.baz = foo.bar.bar.qaz (1)
if foo.bar.blah.zaq = foo.bar.blah.abc that '...
이 코드가 실행되면 다음은 다음과 같습니다.

변수 foo는 전역 객체로 해결됩니다.
변수 막대는 FOO의 멤버로 분해됩니다. 이것은 실제로 COM 메소드 호출입니다.
변수 blah는 foo.bar의 구성원으로 해결됩니다. 이것은 또 다른 COM 메소드 호출입니다.
변수 qaz는 foo.bar.blah의 회원으로 해결됩니다. 맞습니다. 이것은 여전히 ​​COM 메소드 호출입니다.
foo.bar.blah.quaz (1)에게 전화하십시오. 다른 com 메소드 호출. 알았어요?
1 ~ 3 단계를 다시 수행하여 BAZ를 구문 분석하십시오. 시스템은 QAZ 호출이 객체 모델을 변경하는지 여부를 알지 못하므로 BAZ를 해결하기 위해 1 ~ 3 단계를 다시 수행해야합니다.
foo.bar.blah의 회원으로서 BAZ를 해결하십시오. 속성을 할당하십시오.
Zaq를 구문 분석하기 위해 1 단계에서 3 단계를 다시 수행하십시오.
ABC를 구문 분석하려면 1 단계에서 3 단계를 다시 수행하십시오.
보시다시피, 효율성은 상당히 나쁘다. 이 코드를 vbscript로 작성하는 빠른 방법은

다음과

myobj.baz = myobj.qaz (1)
myobj.zaq = myobj.abc라면 '...
vbscript 5.0 이상을 사용하는 경우 with 명령문을 사용 하여이 코드를 작성할 수 있습니다.

with foo.bar.blah
.baz = .qaz (1)
.zaq = .abc라면 '...
...

이 기술은 VB 프로그래밍에도 적용됩니다

.

팁 13 : 재분산 배열을 피하십시오.

가능한 경우 REDIM 어레이를 피해야합니다. 성능 측면에서, 컴퓨터의 물리적 메모리 크기가 제한된 경우 배열의 초기 차원을 최악의 시나리오로 설정하거나 치수를 최상의 시나리오로 설정 한 다음 다시 차단하는 것이 좋습니다. 필요에 따라. 그렇다고해서 필요하지 않다는 것을 알고있을 때 메가 바이트의 메가 바이트를 할당하는 것은 아닙니다.

다음 코드는 Dim과 Redim의 부적절한 사용을 보여줍니다.

<%
DimmyArray ()
redimmyarray (2)
MyArray (0) =? 안녕하세요?
MyArray (1) =? 작별 인사?
MyArray (2) =? 작별 인사?
...
'더 많은 공간이 필요한 다른 코드가 발생합니다. 그러면 ...
redim 보존 MyArray (5)
MyArray (3) =? 더 많은 것?
MyArray (4) =? 더 많은 것?
MyArray (5) =? 아직 더 많은 것?
%>

배열의 초기 크기를 처음부터 (이 경우 5) 배열을 더 크게 만들기 위해 배열의 초기 크기를 올바르게 어둡게하는 것이 훨씬 좋습니다. 메모리를 낭비 할 수 있지만 (모든 요소를 ​​사용하지 않는 경우) 이점은 더 빨라진다는 것입니다.

팁 14 : 응답 버퍼링 사용

"응답 버퍼링"을 활성화하여 출력의 전체 페이지를 버퍼링 할 수 있습니다. 이로 인해 브라우저에 대한 쓰기 양이 최소화되어 전반적인 성능이 향상됩니다. 각각의 쓰기 작업은 상당한 오버 헤드가 발생하므로 (IIS 및 네트워크를 통해 전송 된 데이터 양의 측면에서), 더 적은 글을 쓰면 더 좋습니다. 스타트 업이 느려지고 잔소리 알고리즘 (네트워크 혼잡 완화에 사용됨)의 사용으로 인해 TCP/IP는 많은 작은 덩어리를 보내야 할 때보 다 몇 개의 큰 데이터 덩어리를 보낼 때 훨씬 더 효율적입니다.

응답 버퍼링을 가능하게하는 두 가지 방법이 있습니다. 먼저 인터넷 서비스 관리자를 사용하여 전체 응용 프로그램에 대한 응답 버퍼링을 가능하게 할 수 있습니다. 이 접근법을 권장하여 IIS 4.0 및 IIS 5.0의 새로운 ASP 응용 프로그램에 대한 기본적으로 응답 버퍼링을 가능하게합니다. 둘째, 각 ASP 페이지의 상단 근처에 다음 코드 줄을 추가하여 응답 버퍼링을 활성화 할 수 있습니다.

< % response.buffer = true %>
이 코드 라인은 응답 데이터가 브라우저에 기록되기 전에 실행되어야합니다 (즉, ASP 스크립트에 HTML이 나타나기 전에 및 응답을 사용하여 쿠키를 설정하기 전에). 일반적으로 전체 응용 프로그램에 대한 응답 버퍼링을 가능하게하는 것이 가장 좋습니다. 이렇게하면 모든 페이지 상단에 위의 코드 줄을 쓸 필요가 없습니다.

응답.플러시
응답 버퍼링에 대한 일반적인 불만은 사용자가 ASP 페이지가 응답 속도가 느리다고 인식한다는 것입니다 (전체 응답 시간이 개선 되었음에도 불구하고) 전체 페이지가 생성 될 때까지 기다려야하므로 아무것도보기 전에 기다려야합니다. 장기간의 페이지의 경우 응답 버퍼링을 비활성화하려면 응답 = false를 설정할 수 있습니다. 그러나 더 나은 전략은 Response.Flush 메소드를 활용하는 것입니다. 이 메소드는 ASP로 변환 된 모든 HTML을 브라우저로 보냅니다. 예를 들어, 1,000 열 테이블의 첫 100 행을 변환 한 후 ASP는 응답을 호출 할 수 있습니다. 플러시를 통해 브라우저로 변환 결과를 강제하여 나머지 행이 준비되기 전에 사용자가 처음 100 행을 볼 수 있습니다. 이 기술은 응답 버퍼링과 브라우저가 점차적으로 데이터를 표시하는 것을 완벽하게 결합합니다.

(위의 1,000 줄 테이블 예제에서 많은 브라우저가 닫는 </table> 태그를 볼 때까지 테이블을 표시하지 않습니다. 대상 브라우저가 지원하는지 확인하십시오.이를 피하려면 테이블을 여러 테이블로 분할하십시오. 적은 행으로 응답이 적용됩니다. 각 테이블의 인터넷 익스플로러가 완전히 다운로드되기 전에 테이블을 표시하면 테이블 열 폭을 지정하면 인터넷 익스플로러가 측정하여 열 폭을 계산하는 경우 특히 빠릅니다. 각 셀의 내용 너비.)

응답 버퍼링에 대한 또 다른 일반적인 불만은 매우 큰 페이지가 생성 될 때 많은 서버 메모리를 차지한다는 것입니다. 큰 페이지를 생성하는 방법에 관계없이,이 문제는 reponse.flush의 영리한 사용을 통해 해결할 수 있습니다.

팁 15 : 배치 임베디드 스크립트 및 응답 문자 문자 명령문

vbscript 구문 < % = expression %> "expression"의 값을 ASP 출력 스트림에 씁니다. 응답 버퍼링이 활성화되지 않으면 실행 된 각 문은 네트워크를 통해 많은 작은 패킷의 브라우저에 데이터를 작성합니다. 이것은 매우 느립니다. 또한 소량의 스크립트와 HTML을 산재하면 스크립트 엔진과 HTML 사이의 전환이 발생하여 성능이 줄어 듭니다. 따라서 다음 트릭을 사용하십시오. 응답을 사용하십시오. 단단히 번들 된 인라인 표현식 대신 통화를 작성하십시오. 예를 들어, 다음 예제에는 행당 필드 당 응답 스트림에 하나의 쓸 것이며, 행당 VBScript와 html 사이에 많은 스위치가 있습니다.

<pable>
rs.fields %의 각 fld에 대해 < %
<th> < % = fld.name %> </th>
<%
다음
rs.eof는 아닙니다
%>
<tr>
rs.fields %의 각 fld에 대해 < %
<td> < % = fld.value %> </td>
<% 다음
</tr>
<% rs.movenext
웬드 %>
</table>
아래 코드는 더 효율적이며 한 줄 당 응답 스트림에 쓰기가 더 효율적입니다. 모든 코드는 vbscript 블록에 포함되어 있습니다 :

<pable>
<%
Rs.Fields의 각 FLD에 대해
response.write (? <th>? & fld.name &? </th>? & vbcrlf)
다음
rs.eof는 아닙니다
응답 (? <tr>?)
rs.fields %>의 각 fld에 대해
response.write (? <td>? & fld.value &? </td>? & vbcrlf)
다음
응답 .write? </tr>?
향하게 하다
%>
</table>
이 트릭은 응답 버퍼링이 비활성화 될 때 특히 잘 작동합니다. 응답 버퍼링을 활성화하고 배치 응답이 있는지 확인하는 것이 좋습니다 .Write가 성능 향상에 도움이됩니다.

(이 특별한 예에서, 테이블의 본문을 구축하는 중첩 루프 (rs.eof ...)는 신중하게 구성된 GetString 호출로 교체 할 수 있습니다.)

팁 16 : 페이지를 완료하는 데 오랜 시간이 걸리면, 응답을 사용하기 전에 사용자가 참을성이없는 경우

, ISClientConnected 요청을 실행하기 전에 ASP 페이지를 포기할 수 있습니다. 새로 고침을 클릭하거나 서버의 다른 페이지로 이동하면 ASP 요청 큐의 끝에서 대기중인 새로운 요청이 있으며 대기열 중간에 연결이 끊어졌습니다. 이것은 종종 서버의로드가 높을 때 발생합니다 (따라서 요청 대기열이 길고 응답 시간이 길어지면 상황이 악화됩니다. 사용자가 더 이상 연결되지 않은 경우 ASP 페이지 (특히 느리고 큰 ASP 페이지)를 실행할 필요가 없습니다. 응답을 사용하여이를 확인할 수 있습니다. 거짓을 반환하면 응답을 호출하고 페이지의 나머지 부분을 폐기해야합니다. 실제로, IIS 5.0은이 동작을 프로그램했습니다. ASP가 새 요청을 실행하려고 할 때마다 요청이 대기열에서 얼마나 오래 기다렸는지 확인합니다. 3 초 이상 기다리고 있다면 ASP는 클라이언트가 여전히 연결되어 있는지 확인하고 그렇지 않은 경우 즉시 요청을 종료합니다. 대사에서 AspqueeConnectionTestTime 설정을 사용하여 타임 아웃을 3 초에서 다른 값으로 조정할 수 있습니다.

페이지를 완료하는 데 시간이 오래 걸리면 때때로 응답을 확인할 수도 있습니다. 응답 버퍼링이 활성화되면 응답을 수행하는 것이 좋습니다. 때때로 사용자에게 무슨 일이 일어나고 있는지 알리십시오.

IIS 4.0에서는 응답이 먼저 실행되지 않으면 응답이 제대로 작동하지 않습니다. 버퍼링이 활성화되면 응답을 수행해야합니다. IIS 5.0에서는이 작업을 수행 할 필요가 없습니다. 어쨌든 response.isclientConnected에는 약간의 오버 헤드가 있으므로 작업에 최소한 500 밀리 초 (예 : 초당 수십 페이지의 처리량을 유지하려는 경우 오랜 시간)를 사용하는 경우에만 사용하십시오. 경험에 따르면 테이블의 많은 행을 표시 할 때와 같이 단단한 루프를 반복적으로 실행할 때마다 호출해서는 안된다는 것이 알 수 있습니다.

모든 코드 경로 (특히 서버 또는 애플리케이션- 스코프 링 된 객체)에서 사용되지 않는 객체를 참조하려면

인스턴스화 된 개체에 <botort> 태그를 사용하십시오

global.asa의 선언 서버를 사용하는 대신. Server.createObject는 즉시 개체를 만듭니다. 미래에 물체를 사용하지 않으면 자원을 낭비했습니다. <object id = objname> 태그는 objname을 선언하지만, 메소드 나 속성이 처음으로 사용될 때까지 objname이 생성되지 않습니다.

이것은 게으른 평가의 또 다른 예입니다.

팁 18 : ADO 및 기타 구성 요소에 TypLib 선언을 사용하여

ADO를 사용할 때 개발자는 종종 ADOVBS.txt를 추가하여 다양한 ADO 상수에 액세스합니다. 이 파일은 상수를 사용할 모든 페이지에 포함되어야합니다. 이 상수 파일은 상당히 크며 각 ASP 페이지의 컴파일 시간과 스크립트 크기에 많은 오버 헤드를 추가합니다.

IIS 5.0은 구성 요소 유형 라이브러리에 바인딩하는 기능을 도입했습니다. 이를 통해 유형 라이브러리를 한 번 참조하여 모든 ASP 페이지에서 사용할 수 있습니다. 각 페이지마다 상수 파일을 컴파일하는 오버 헤드는 없으며, 구성 요소 개발자는 ASP에서 사용하기 위해 vbscript#_include 파일을 만들 필요가 없습니다.

Ado typelib에 액세스하려면 다음 문을 Global.asa에 배치하십시오.

<!- ​​메타 데이터 이름 =? Microsoft ActiveX Data Objects 2.5 라이브러리?
type =? typelib?
또는

<!- 메타 데이터 유형 =? typelib?

file

=

?

서비스는 지원을 제공합니다. 가능할 때마다 이러한 기능을 사용하십시오. 이러한 모든 기술은 클라이언트 측 유효성 검사 및 데이터 캐싱을 수행하여 웹 서버로의 왕복이 필요하지 않습니다. 스마트 브라우저를 실행하는 경우 브라우저는 귀하를 위해 약간의 유효성 검사를 수행 할 수 있습니다 (예 : 게시물을 수행하기 전에 신용 카드 체크섬이 유효한지 확인). 가능할 때 마다이 기능을 사용하십시오. 클라이언트-서버 왕복 트립을 줄임으로써 웹 서버의로드를 줄이고 네트워크 트래픽을 줄입니다 (브라우저로 전송 된 첫 페이지는 더 클 수 있지만) 및 서버에서 액세스하는 백엔드 리소스. 또한 사용자는 평소처럼 새 페이지를 읽을 필요가 없으므로 사용자가 기분이 좋아집니다. 이렇게한다고해서 서버 측 유효성 검사를 건너 뛸 수있는 것은 아닙니다. 항상 서버 측 유효성 검사를 수행해야합니다. 이를 통해 클라이언트는 어떤 이유로 든 잘못된 데이터를 생성하지 못하게합니다 (예 : 해커 또는 클라이언트 측 유효성 검사 루틴을 실행하지 않는 브라우저).

"브라우저 독립적 인"HTML을 개발하는 데 많은 작업이 진행되었습니다. 이러한 문제로 인해 개발자는 성능을 향상시킬 수있는 인기있는 브라우저 기능을 사용하는 것을 꺼려합니다. 일부 고성능 사이트의 경우 브라우저 "액세스"문제에 대한 문제가 있어야하며, 좋은 전략은 페이지를 최적화하여 인기있는 브라우저에 적응하는 것입니다. 브라우저 기능 구성 요소를 사용하여 ASP에서 브라우저 기능을 쉽게 감지 할 수 있습니다. Microsoft FrontPage와 같은 도구는 브라우저 및 특정 버전의 HTML에 적합한 디자인 코드를 돕습니다. 언제 더 나은지 보십니까? 추가 토론을 위해 기술 트레이드 오프를 평가합니다.

팁 20 : 루프에서 문자열 연결을 사용하지 않으면

많은 사람들이 다음과 같은 루프에서 문자열을 만듭니다.

& vbcrlf?
Rs.Fields의 각 FLD에 대해
s = s &?
다음

은 rs.eof가 아닙니다
s = s & vbcrlf &?
Rs.Fields의 각 FLD에 대해
s = s &? <td>?
다음
s = s &? </tr>?
rs.이동다음
wend

s = s & vbcrlf &? </table>?
응답
이 접근법에서는 일부 문제가 발생합니다. 첫 번째 문제는 문자열을 반복적으로 연결하는 것이 더 일반적으로 2의 힘에 시간이 걸린다는 것입니다. 그러한 루프를 실행하는 데 걸리는 시간은 레코드 수의 제곱에 비례합니다. 더 간단한 예는이 문제를 더 명확하게 설명합니다.

s = ??
i = asc (? a?)에서 asc (? z?)
s = s & chr (i)
다음
첫 번째 반복에서, 당신은 하나의 문자열을 얻습니다? a?. 두 번째 반복에서 vbscript는 문자열을 재 할당하고 두 문자 (? ab?)를 s로 복사해야합니다. 세 번째 반복에서는 S를 다시 재 할당하고 세 문자를 s로 복사해야합니다. n (26 일) 반복에서는 n 문자를 s로 재 할당하고 복사해야합니다. 총은 1+2+3+...+n, 즉 N*(n+1)/2 사본입니다.

위의 레코드 세트 예제에서, 100 개의 레코드와 5 개의 필드가있는 경우, 내부 루프는 100*5 = 500 회 실행되며 모든 복사 및 재 할당에 소비 된 시간은 500*500 = 250,000에 비례합니다. 이것은 적당한 크기의 레코드 세트에 대한 복사 작업이 너무 많습니다.

이 경우 문자열 연결 대신 response.write () 또는 인라인 스크립팅 (< % = fld.value %>)을 사용하여 코드를 개선 할 수 있습니다. 응답 버퍼링이 활성화되면 응답이 더 빨라집니다. 응답 버퍼 끝에 데이터를 첨부합니다. 재 할당이 관련되어 있지 않으므로 매우 효율적입니다.

ADO 레코드 세트를 HTML 테이블로 변환하는 특정 경우 GetRows 또는 GetString 사용을 고려해야합니다.

JScript에서 문자열을 연결하는 경우 특히 += 연산자를 사용하는 것이 좋습니다. 즉, s +=?

팁 21 : 브라우저 및 프록시 캐싱 활성화

기본적으로 ASP는 브라우저 및 프록시의 캐싱을 비활성화합니다. ASP 페이지는 본질적으로 역동적이기 때문에 시간이 지남에 따라 변경되는 기본 정보가 있기 때문에 의미가 있습니다. 페이지가 모든 뷰에서 새로 고침이 필요하지 않으면 브라우저 및 프록시 캐싱을 활성화해야합니다. 이를 통해 브라우저와 프록시는 일정 시간 동안 페이지의 "캐시 된"사본을 사용할 수 있으며,이 길이는 제어 할 수 있습니다. 캐싱은 서버의 부하를 크게 줄이고 사용자의 대기 시간을 단축 할 수 있습니다.

캐시 할 페이지로 어떤 동적 페이지를 사용할 수 있습니까? 몇 가지 예는 다음과 같습니다.

일기 예보 페이지,이 페이지에서는 일기 예보가 5 분마다 업데이트됩니다.
홈페이지 목록 뉴스 항목 또는 릴리스, 하루에 두 번 업데이트되었습니다.
기본 통계가 몇 시간마다 업데이트되는 뮤추얼 펀드 성과 목록.
브라우저 또는 프록시 캐싱을 사용하면 웹 서버에 기록 된 방문 횟수가 줄어 듭니다. 모든 페이지보기 또는 게시물을 정확하게 측정하려면 브라우저 및 프록시 캐싱을 사용하지 않습니다.

브라우저 캐싱은 HTTP "만료"헤더에 의해 제어되며 웹 서버가 브라우저로 전송됩니다. ASP는이 헤더를 보내기위한 두 가지 간단한 메커니즘을 제공합니다. 페이지가 만료되는 분의 수를 설정하려면 응답을 설정하십시오 .expires 속성. 다음 예제는 브라우저에 콘텐츠가 10 분 안에 만료되는 것을 알려줍니다.

< % response.expires = 10 %>

응답 설정. 서버와 브라우저 시계 사이의 불일치를 피하기 위해 -1000 (하루보다 약간)과 같은 큰 음수를 사용하십시오.

response.expiresabsolute

는 내용이 만료되는 특정 시간을 설정할 수 있습니다.

응답 객체를 사용하여 만료 시간을 설정하는 대신 <meta> 태그를 HTML, 일반적으로 html 파일의 <head> 섹션에 쓸 수 있습니다. 일부 브라우저는이 지침을 존중하지만 프록시는 그렇지 않습니다.

<meta http-equiv =? value =? 31,2001 13:30:15?>
마지막으로 응답을 사용하여 CacheControl 속성을 사용하여 HTTP 프록시로 콘텐츠를 캐시 할 수 있는지 여부를 나타냅니다. 이 속성을 "공개"로 설정하면 프록시 가이 컨텐츠를 캐시 할 수 있습니다.

< % response.cachecontrol =? public?
기본적 으로이 속성은 "개인"으로 설정됩니다. 프록시는 다른 사용자의 사용자 페이지에 서비스를 제공 할 수 있으므로 사용자와 관련된 데이터를 표시하는 페이지에 프록시 캐싱이 활성화되어서는 안됩니다.

팁 22 : 응답 대신 Server.Transfer를 사용하면

RespondeRect를 사용하면 브라우저가 다른 페이지를 요청할 수 있습니다. 이 기능은 일반적으로 사용자를 로그인 또는 오류 페이지로 리디렉션하는 데 사용됩니다. 리디렉션은 새 페이지에 대한 요청을 강요하기 때문에 결과는 브라우저가 웹 서버로 두 번의 라운드 트립을해야하며 웹 서버는 하나 더 요청을 처리해야합니다. IIS 5.0은 새로운 기능 서버를 소개합니다. 이는 동일한 서버의 다른 ASP 페이지로 실행을 전송하는 새로운 기능 서버를 소개합니다. 이는 중복 브라우저 -WEB 서버 왕복 트립을 피하여 전반적인 시스템 성능 및 사용자 응답 시간을 향상시킵니다. "리디렉션"에서 "새로운 방향"을 확인하면 Server.Transfer 및 Server.Execute 여야합니다.

IIS 5.0 및 ASP 3.0의 새로운 기능의 전체 목록은 IIS 5.0의 ASP 활용도 참조하십시오.

팁 23 : 디렉토리 URL에서 백 슬래시 사용

관련 팁은 디렉토리를 가리키는 URL에서 백 슬래시 (/)를 사용하는 것입니다. 후행 슬래시를 생략하면 브라우저는 서버에 디렉토리를 요청하는 것을 서버에 알리기 위해 서버에 요청합니다. 브라우저는 두 번째 요청을하여 URL에 슬래시를 추가 한 다음 서버가 디렉토리의 기본 문서 또는 디렉토리 목록으로 만 응답 할 수 있습니다 (기본 문서 및 디렉토리 브라우징이 활성화 된 경우). 슬래시를 추가하면 첫 번째, 쓸모없는 수익이 제거됩니다. 사용자가 더 쉽게 읽을 수 있도록 디스플레이 이름의 후행 슬래시를 생략 할 수 있습니다.

예를 들어, 쓰기 :

<a href =? http : //msdn.microsoft.com/workshop/? title =? msdn web
워크숍?> http://msdn.microsoft.com/workshop </a>
이것은 웹 사이트의 홈페이지를 가리키는 URL에도 적용됩니다. 다음을 사용하십시오. <a href =? http : //msdn.microsoft.com/?> <a href =? . com?>.

팁 24 : 서버 변수에

액세스하면 웹 사이트가 서버에 특별한 요청을하고 요청한 모든 서버 변수를 수집합니다. 상황은 곰팡이가 많은 다락방의 폴더에서 파일을 검색하는 것과 유사합니다. 해당 문서를 찾으려면 다락방으로 이동하여 폴더를 찾은 다음 문서를 찾아야합니다. 서버 변수를 요청할 때도 같은 일이 발생합니다. 처음 서버 변수를 요청하면 성능이 져야합니다. 다른 서버 변수에 대한 후속 요청은 성능에 영향을 미치지 않습니다.

자격이없는 요청 객체에 액세스하지 마십시오 (예 : request ( "data")). request.servariables는 request.cookies, request.form, request.querystring 또는 request.clientCertificate에 있지 않은 항목에 대해 암시 적으로 호출됩니다. 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는 2 개의 프로세서를 넘어서는 스케일이 없습니다. 응용 프로그램에 사용하는 스크립팅 코드와 ADO가 많을수록 Windows 2000으로 업그레이드 한 후 더 많은 성능이 향상됩니다.

아직 Windows 2000으로 업그레이드 할 수없는 경우 최신 버전의 SQL Server, ADO, VBSCRIP 및 JSCRIPT, MSXML, Internet Explorer 및 NT 4 서비스 팩으로 업그레이드 할 수 있습니다. 그들은 성능과 신뢰성을 향상시킵니다.

팁 26 : 웹 서버 최적화

사이트 성능을 향상시킬 수있는 다양한 IIS 최적화 매개 변수가 있습니다. 예를 들어, IIS 4.0을 사용하면 ASP ProcessOrthreadMax 매개 변수 (IIS 문서 참조)를 늘리면 특히 백엔드 리소스 (예 : 데이터베이스) 또는 기타 중간 제품 (예 : 기타 중간 제품)을 기다리는 사이트에서 성능을 크게 향상시킬 수 있습니다. 스크린 브러시로). IIS 5.0에서는 ASP 스레드 게이팅을 활성화하는 것이 ASPProcessOrthreadMax에 대한 최적의 설정을 찾는 것보다 효율적이라는 것을 알 수 있습니다.

좋은 참조는 아래의 II 최적화를 참조하십시오.

최적의 구성 설정은 다른 요소 중에서 응용 프로그램 코드, 실행중인 시스템 하드웨어 및 클라이언트 워크로드에 따라 다릅니다. 최상의 설정을 찾는 유일한 방법은 성능 테스트를 수행하는 것입니다. 다음 팁에서 ​​논의 할 것입니다.

팁 27 : 성능 테스트 수행

이전에 말했듯이 성능은 특징입니다. 사이트의 성능을 향상 시키려면 사이트의 성능을 설정하고 성능 목표를 설정하고 도달 할 때까지 점차 개선하십시오. 아니요, 성능 테스트는 수행되지 않습니다. 종종 프로젝트가 끝날 무렵, 필요한 구조적 변화를하기에는 너무 늦고 고객이 실망 할 것입니다. 테스트 루틴의 일부로 성능 테스트를 수행하십시오. ASP 페이지 또는 COM 객체와 같은 개별 구성 요소 또는 사이트 전체에서 성능 테스트를 수행 할 수 있습니다.

많은 사람들이 단일 브라우저를 사용하여 웹 사이트의 성능을 테스트하기 위해 페이지를 요청합니다. 이렇게하면 사이트가 반응이 좋다는 느낌이 들지만 실제로 사이트가 부하에서 수행되는 방식을 알려주지는 않습니다.

일반적으로 성능을 정확하게 테스트하려면 전용 테스트 환경이 필요합니다. 이 환경에는 프로세서 속도, 프로세서 수, 메모리, 디스크, 네트워크 구성 등의 측면에서 프로덕션 환경과 유사한 하드웨어가 포함되어야합니다. 둘째, 클라이언트의 워크로드를 지정해야합니다. 몇 명의 동시 사용자 수, 요청을받는 빈도, 클릭 한 페이지 유형 등. 실제 사이트 사용에 대한 데이터가없는 경우 사용량을 추정해야합니다. 마지막으로, 예상 클라이언트 워크로드를 시뮬레이션 할 수있는 도구가 필요합니다. 이러한 도구를 사용하면 "N 동시 사용자가 있다면 얼마나 많은 서버가 필요한가?"와 같은 질문에 대답 할 수 있습니다. 병목 현상의 원인을 식별하고 그것들을 최적화 할 수도 있습니다.

아래에는 좋은 웹로드 테스트 도구가 나와 있습니다. 특히 Microsoft Web Application Stress (WAS) 툴킷을 권장합니다. 테스트 스크립트를 녹화 한 다음 웹 서버에 액세스하는 수백 또는 수천 명의 사용자를 시뮬레이션 할 수 있습니다. 초당 요청, 응답 시간 분포 및 오류 계수를 포함하여 여러 통계를보고했습니다. 리치 클라이언트 인터페이스와 원격 테스트를 수행 할 수있는 웹 기반 인터페이스에서 사용할 수 있습니다.

IIS 5.0 튜닝 가이드를 읽으십시오.

팁 28 : 리소스 링크 읽기

아래는 성능 관련 리소스에 대한 링크입니다. 그것에 대해 배우고 싶다면 확장 가능한 웹 응용 프로그램 개발을 읽으십시오.

리소스 최적화 ASP 스크립트 확장 가능한 웹 애플리케이션을

개발

하면

CACHENCE

가

있습니다

Nancy Winnick Cluts의

속도 및 최적화 리소스

IIS 최적화

인터넷 정보 서비스를 사용한 웹 서버 튜닝의 예술 및 과학 5.0

IIS 5.0의 ASP 활용,

JD Meier의 대량 사이트 용 IIS 4.0을 조정하고 인터넷 정보를 조정합니다. Michael Stephenson의 서버 성능

Mike Moore의

웹 서버 성능 최적화 설정의 미로를 탐색

ADO 및 SQL Server

의 Internet Information Server 4.0을 관리하여

Top 10 팁 : ADO 및 ASP를 통해 SQL 액세스

개선

JD MEIER

의 MDAC 응용 프로그램의 성능

SQL Server : Leland Ahlbeck의 성능 벤치 마크 및 가이드의

Microsoft 데이터 액세스 구성 요소에서 풀링을

Microsoft Data Access 구성 요소를

사용하여 데이터 액세스 구성 요소의 성능을 향상시킵니다

MDAC) 및 ActiveX Data Objects (ADO) Leland Ahlbeck,

Microsoft

SQL Server 7.0 실제 성능 튜닝 및 최적화 - Leland Ahlbeck의 서버 관점,

Microsoft SQL Server 7.0 실제 성능 튜닝 및 최적화 - Damien Lindauer의 서버 관점 - Damien Lindauer의 애플리케이션 관점

Dino Esposito

ASP

구성 요소 가이드 라인

Nancy Winnick Cluts가 활성화 된 서버 페이지를 사용하여 개발 한

ASP

스레딩

에서 VB 구성 요소에 대한 디자인 지침

Nancy Winnick Cluts

의 ATL을 사용한 활성 서버 구성 요소

Neil Allain

의 C ++를 사용하여 고성능 중간 계층 구성 요소

Active Server Pages 및 Jon Flanders Apartments의 COM을

. 활성 서버 페이지, Don Box,

House of Com : Contexts, By Don Box,

House of Com : Windows 2000 구성 요소 실행 환경의 성능 트레이드 오프, Don Box,

Visual Basic 및 Scripting을 최대한 활용하는 COM 구성 요소를 구축합니다.

MTS

사전 구성 요소를

위한

Ivo Salmre

구성 요소 디자인 원칙

의

사전 개체를 요약 한

페이지 캐시 객체 생성

문

​

​

​

​

​

Microsoft Visual Studio Calibility Center

Fitch & Mather Stocks

Microsoft Windows DNA 플랫폼

서버 서버 성능 및 확장 성 킬러를

FMStocks 애플리케이션

고성능 비주얼 기본 앱, Ken Spencer

Duwamish Books, Phase 4

Top Windows DNA 성능 실수 그리고 Gary Geiger와 Jon Pulsipher

Building의 정적 HTML에서 고성능 웹 농장에 이르기까지 Shawn Bice Microsoft 웹 애플리케이션 응용 스트레스 도구에 의해

충분히

스트레스

를받을 수 없습니다

.

Bibliography

를 사용하여 분산 응용 프로그램에서의

성능 키트

.

Microsoft Internet Information Services 5.0 리소스 가이드 (Windows 2000 서버 리소스 키트 포함), Microsoft Press.

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

Microsoft Press의 Ted Pattison의 Com 및 Microsoft Visual Basic 6.0을 사용하여 분산 응용 프로그램을 프로그래밍합니다.

효과적인 com, Don Box, Keith Brown, Tim Ewald 및 Chris는 Addison-Wesley를 판매합니다.

웹 유용성 개발 : 새로운 라이더 인 Jakob Nielsen의 단순성 관행.

learnasp.com

4guysfromrolla.com

15seconds.com

asptoday.com

asp101.com

asplists.com

용

ASP 웹 사이트

많은 전문 메일 목록에는 다음이 포함됩니다.

빠른 코드!
ASP 고급
초보자 관리가 아닙니다
확장 성
시각적 기본 구성 요소
XML
C ++/ATL 구성 요소 빌딩
useit.com :

charles carroll에 대한

George Reilly ASP의

ASP 스타일

ASP John Meade

가이드 라인

XML

내부의 XML 성능에 의한 Chris Lovett

내부 Chris Lovett의 MSXML3 성능.