ASP 개발자는 디자인 프로젝트에서 더 나은 성능과 확장성을 달성하기 위해 지속적으로 노력합니다. 다행히도 이 분야에 대한 훌륭한 조언을 제공하는 책과 사이트가 많이 있습니다. 그러나 이러한 제안은 ASP 플랫폼의 작업 구조에서 도출된 결론을 기반으로 하며 실제 성능 향상을 정량적으로 측정할 수는 없습니다. 이러한 권장 사항에는 더 복잡한 코딩이 필요하고 코드 읽기가 더 어렵기 때문에 개발자는 실제 결과를 보지 않고도 ASP 응용 프로그램의 성능 향상이 비용을 들일 가치가 있는지 여부를 판단할 수 있습니다.
이 기사는 두 부분으로 나누어 개발자가 특정 이니셔티브가 향후 프로젝트뿐만 아니라 원래 프로젝트를 업데이트할 가치가 있는지 판단하는 데 도움이 되는 몇 가지 성능 테스트 결과를 제시합니다. 첫 번째 부분에서는 ASP 개발의 몇 가지 기본 문제를 검토하겠습니다. 두 번째 부분에서는 일부 ADO 기능을 최적화하고 그 결과를 VB COM 개체를 호출하여 동일한 ADO 기능을 수행하는 ASP 페이지와 비교하는 방법을 다룹니다. 그 결과는 놀랍고 때로는 놀랍습니다.
이 기사에서는 다음 질문에 답할 것입니다.
* ASP 생성 콘텐츠를 응답 스트림에 기록하는 가장 효율적인 방법은 무엇입니까?
* 버퍼를 활성화해야 합니까?
* ASP 코드에 주석 추가를 고려해야 합니까?
* 페이지에 대해 기본 언어를 명시적으로 설정해야 합니까?
* 필요하지 않은 경우 세션 상태를 닫아야 합니까?
* 스크립트 로직을 서브루틴과 기능 영역에 배치해야 합니까?
* 포함 파일 사용의 의미는 무엇입니까?
* 오류 처리를 수행할 때 어떤 종류의 부하가 부과됩니까?
* 컨텍스트 핸들러 설정이 성능에 영향을 미치나요?
모든 테스트는 여기에서 찾을 수 있는 무료 도구인 Microsoft의 WAST(Web Application Focus Tool)를 사용하여 수행되었습니다. 나는 아래 설명된 ASP 페이지 테스트를 반복적으로(각각 70,000회 이상) 호출하는 WAST를 사용하여 간단한 테스트 스크립트를 만들었습니다. 응답 시간은 평균 TTLB(Total Total Time Last Byte)를 기준으로 하며, 이는 초기 요청 시간부터 도구가 서버로부터 마지막 데이터 비트를 수신하는 시간까지의 시간입니다. 테스트 서버는 196MB RAM을 갖춘 Pentium 166이고 클라이언트는 256MB RAM을 갖춘 Pentium 450입니다. 이러한 머신의 성능이 그리 뛰어나지 않다고 생각할 수도 있지만, 우리는 서버의 용량을 테스트하는 것이 아니라 서버가 한 번에 한 페이지를 처리하는 데 걸리는 시간을 테스트하고 있다는 사실을 잊지 마십시오. 테스트 중에는 기계가 다른 작업을 수행하지 않습니다. WAST 테스트 스크립트, 테스트 보고서 및 모든 ASP 테스트 페이지는 사용자가 직접 검토하고 테스트할 수 있도록 ZIP 파일에 포함되어 있습니다.
ASP 생성 콘텐츠를 응답 스트림에 기록하는 가장 효율적인 방법은 무엇입니까?
ASP를 사용하는 가장 큰 이유 중 하나는 서버에서 동적 콘텐츠를 생성하는 것입니다. 따라서 테스트의 확실한 시작점은 동적 콘텐츠를 응답 스트림으로 보내는 가장 적절한 방법을 결정하는 것입니다. 많은 옵션 중에서 가장 기본적인 두 가지 옵션이 있습니다. 하나는 인라인 ASP 태그를 사용하는 것이고, 다른 하나는 Response.Write 문을 사용하는 것입니다.
이러한 옵션을 테스트하기 위해 몇 가지 변수를 정의한 다음 해당 값을 테이블에 삽입하는 간단한 ASP 페이지를 만들었습니다. 이 페이지는 간단하고 실용적이지는 않지만 일부 개별 문제를 격리하고 테스트할 수 있습니다.
ASP 인라인 태그 사용
첫 번째 테스트에서는 인라인 ASP 태그 < %= x % >를 사용합니다. 여기서 x는 할당된 변수입니다. 이 방법은 수행하기 가장 쉬우며 페이지의 HTML 부분을 읽고 유지하기 쉬운 형식으로 유지합니다.
<% 옵션 명시적
희미한 이름
DimLastName
희미한 중간초기
희미한 주소
희미한 도시
희미한 상태
Dim전화번호
희미한 팩스 번호
희미한 이메일
희미한 생년월일
이름 = John
중간초기 = Q
성 = 공개
주소 = 100 Main Street
도시=뉴욕
주=NY
전화번호 = 1-212-555-1234
팩스번호 = 1-212-555-1234
이메일 = [email protected]
생년월일 = 1950년 1월 1일
%>
<HTML>
<헤드>
＜ TITLE ＞응답 테스트 ＜ / TITLE ＞
＜ /HEAD ＞
<바디>
＜ H1 ＞응답 테스트 ＜ /H1 ＞
＜ 표 ＞
< tr >< td >< b >이름:< /b >< /td >< td >< %= 이름 % >< /td >< /tr >
< tr >< td >< b >중간 이니셜:< /b >< /td >< td >< %= 중간 이니셜 % >< /td >< /tr >
< tr >< td >< b >성:< /b >< /td >< td >< %= 성 % >< /td >< /tr >
< tr >< td >< b >주소:< /b >< /td >< td >< %= 주소 % >< /td >< /tr >
< tr >< td >< b > 도시:< /b >< /td >< td >< %= 도시 % >< /td >< /tr >
< tr >< td >< b >상태:< /b >< /td >< td >< %= 상태 % >< /td >< /tr >
< tr >< td >< b >전화번호:< /b >< /td >< td >< %= 전화번호 % >< /td >< /tr >
< tr >< td >< b >팩스 번호:< /b >< /td >< td >< %= 팩스 번호 % >< /td >< /tr >
< tr >< td >< b >이메일:< /b >< /td >< td >< %= 이메일 % >< /td >< /tr >
< tr >< td >< b >생년월일:< /b >< /td >< td >< %= 생년월일 % >< /td >< /tr >
＜ /테이블 ＞
＜ /BODY ＞
＜ /HTML ＞
/app1/response1.asp의 전체 코드
이전 최고 속도(응답 속도) = 8.28msec/페이지
HTML의 각 줄에 Response.Write 문을 사용하세요.
더 나은 학습 문서 중 다수에서는 이전 방법을 피하는 것이 좋습니다. 그 주된 이유는 페이지를 출력하고 페이지를 처리하여 지연 시간을 부과하는 과정에서 웹 서버가 일반 HTML 전송과 스크립트 처리 사이를 변환해야 하는 경우 컨텍스트 전환이라는 문제가 발생하기 때문입니다. 대부분의 프로그래머가 이 말을 들으면 첫 번째 반응은 원시 HTML의 각 줄을 Response.Write 함수로 래핑하는 것입니다.
…
응답.쓰기(<html>)
응답.쓰기(<head>)
Response.Write(<title>응답 테스트</title>)
응답.쓰기(</head>)
응답.쓰기(<본문>)
응답.쓰기(<h1>응답 테스트</h1>)
응답.쓰기(<테이블>)
Response.Write(< tr >< td >< b >이름:< /b >< /td >< td > & FirstName & < /td >< /tr >)
Response.Write(< tr >< td >< b >중간 이니셜:< /b >< /td >< td > & Middle 이니셜 & < /td >< /tr >)
… <
/app1/response2.asp의 조각
이전 최고 속도(응답 속도) = 8.28msec/페이지
응답 시간 = 8.08msec/페이지
차이 = -0.20msec(2.4% 감소)
이 접근 방식을 사용하면 인라인 마크업을 사용하는 것에 비해 성능 향상이 매우 적다는 것을 알 수 있습니다. 아마도 페이지가 여러 개의 작은 함수 호출로 서버를 로드하기 때문일 것입니다. 이 접근 방식의 가장 큰 단점은 이제 HTML이 스크립트에 포함되어 있기 때문에 스크립트 코드가 더 장황해지고 읽고 유지하기가 더 어려워진다는 것입니다.
래퍼 함수 사용
아마도 Response.Write 문 접근 방식을 사용하려고 할 때 가장 실망스러운 발견은 Response.Write 함수가 각 줄의 끝에 CRLF를 배치할 수 없다는 것입니다. 그래서 브라우저에서 소스코드를 읽어보면 완벽하게 레이아웃된 HTML이 이제 끝이 없는 한 줄이 되었습니다. 다음 발견은 훨씬 더 끔찍할 수도 있다고 생각합니다. Response 개체에 자매 함수 Writeln이 없습니다. 따라서 분명한 반응은 Response.Write 함수에 대한 래퍼 함수를 만들어 각 줄에 CRLF를 추가하는 것입니다.
…
writeCR(< tr >< td >< b >이름:< /b >< /td >< td > & FirstName & < /td >< /tr >)
…
SUB 쓰기CR(str)
응답.쓰기(str & vbCRLF)
끝부분
/app1/response4.asp의 조각
이전 최고 속도(응답 속도) = 8.08msec/페이지
응답 시간 = 10.11msec/페이지
차이 = +2.03msec(25.1% 증가)
물론 이 접근 방식은 함수 호출 수를 효과적으로 두 배로 늘리기 때문에 성능에 미치는 영향이 크므로 어떤 희생을 치르더라도 피해야 합니다. 아이러니하게도 CRLF는 브라우저가 페이지에 렌더링할 필요가 없는 반응 스트림에 한 줄당 2바이트를 추가합니다. 형식이 잘 지정된 HTML이 하는 일은 경쟁업체가 HTML 소스 코드를 읽고 디자인을 더 쉽게 이해할 수 있도록 하는 것입니다.
연속된 응답을 연결합니다. 단일 문으로 작성합니다.
래퍼 함수를 사용한 이전 테스트와 관계없이 다음 논리적 단계는 별도의 Response.Write 문에서 모든 문자열을 추출하고 이를 단일 문으로 연결하여 함수 호출 수를 줄여 페이지 성능을 크게 향상시키는 것입니다.
…
응답.쓰기(<html>&_
＜ 머리 ＞ & _
<제목>응답 테스트</제목> & _
＜ /머리 ＞ & _
<몸> & _
＜ h1 ＞응답 테스트 ＜ /h1 ＞ & _
＜ 테이블 ＞ & _
< tr >< td >< b >이름:< /b >< /td >< td > & 이름 & < /td >< /tr > & _
…
< tr >< td >< b >생년월일:< /b >< /td >< td > & 생년월일 & < /td >< /tr > & _
＜ /테이블 ＞ & _
＜ /본체 ＞ & _
＜ /html ＞)
/app1/response3.asp의 조각
이전 최고 속도(응답 속도) = 8.08msec/페이지
응답 시간 = 7.05msec/페이지
차이 = -1.03msec(12.7% 감소)
현재로서는 가장 최적화된 구성입니다.
연속된 Response.Write를 단일 문으로 연결하고 각 줄 끝에 CRLF를 추가합니다.
소스 코드가 브라우저에서 깨끗하게 보이도록 요구하는 사람들을 고려하여 이전 테스트에서 vbCRLF 상수를 사용하여 각 줄 끝에 캐리지 리턴을 삽입하고 다시 실행했습니다.
…
응답.쓰기(<html>&vbCRLF&_
＜ 머리 ＞ & vbCRLF & _
＜ 제목 ＞응답 테스트 ＜ /title ＞ & vbCRLF & _
＜ /머리 ＞ & vbCRLF & _
…
/app1/response5.asp의 조각
이전 최고 속도(응답 속도) = 7.05msec/페이지
응답 시간 = 7.63msec/페이지
차이 = +0.58msec(8.5% 증가)
결과적으로 추가 연결 및 문자 수 증가로 인해 성능이 약간 저하됩니다.
검토 및 관찰
ASP 출력에 대한 이전 테스트에서 일부 규칙을 도출할 수 있습니다.
* 인라인 ASP의 과도한 사용을 피하십시오.
* 항상 연속된 Response.Write 문을 단일 문으로 연결하세요.
* CRLF를 추가하기 위해 Response.Write 주위에 래퍼 함수를 사용하지 마십시오.
* HTML 출력 형식을 지정해야 하는 경우 Response.Write 문 내에 CRLF를 직접 추가하세요.
버퍼를 활성화해야 합니까?
스크립트를 통해 버퍼 시작
ASP 스크립트 상단에 Response.Buffer=True를 포함하면 IIS는 페이지의 콘텐츠를 캐시합니다.
<% 옵션 명시적
응답.버퍼 = true
희미한 이름
…
/app1/buffer__1.asp의 조각
이전 최고 속도(응답 시간) = 7.05msec/페이지
응답 시간 = 6.08msec/페이지
차이 = -0.97msec(13.7% 감소)
성능이 크게 향상되었습니다. 하지만 더 나은 것이 있습니다.
서버 구성을 통해 버퍼 시작
IIS 5.0에서는 버퍼가 기본적으로 활성화되어 있지만 IIS 4.0에서는 수동으로 활성화해야 합니다. 이제 사이트의 속성 대화 상자를 찾아 홈 디렉터리 탭에서 구성 버튼을 선택하세요. 그런 다음 앱 옵션에서 버퍼링 활성화를 선택합니다. 이 테스트에서는 Response.Buffer 문이 스크립트에서 이동되었습니다.
이전 최고 = 7.05msec/페이지
응답 시간 = 5.57msec/페이지
차이 = -1.48msec(21.0% 감소)
현재 이는 역대 가장 빠른 응답으로, 이전 최상의 응답 시간보다 21% 더 낮습니다. 이제부터 향후 테스트에서는 이 반응 시간을 기준 값으로 사용할 것입니다.
검토 및 관찰
버퍼는 성능을 향상시키는 좋은 방법이므로 버퍼를 서버의 기본값으로 설정하는 것이 필요합니다. 어떤 이유로 페이지가 버퍼를 제대로 실행할 수 없는 경우 Response.Buffer=False 명령을 사용하세요. 버퍼의 한 가지 단점은 전체 페이지가 처리될 때까지 사용자가 서버에서 아무것도 볼 수 없다는 것입니다. 따라서 복잡한 페이지를 처리하는 동안 가끔 Response.Flush를 호출하여 사용자를 업데이트하는 것이 좋습니다.
이제 규칙이 하나 더 추가되었습니다. 항상 서버 설정을 통해 버퍼링을 활성화합니다.
ASP 코드에 주석 추가를 고려해야 합니까?
대부분의 HTML 개발자는 HTML 주석을 포함하는 것이 나쁜 생각이라는 것을 알고 있습니다. 첫째로 전송되는 데이터의 크기가 커지고 둘째로 다른 개발자에게 페이지 구성에 대한 정보를 제공할 뿐입니다. 그러나 ASP 페이지의 주석은 어떻습니까? 서버를 떠나지 않지만 페이지 크기가 늘어나므로 ASP를 사용하여 분할해야 합니다.
이 테스트에서는 각각 80자로 구성된 20개의 댓글을 추가하여 총 1,600자가 되었습니다.
<% 옵션 명시적
'------------------------------------------------ - ---------------------------------
…20줄…
'------------------------------------------------ - ---------------------------------
희미한 이름
…
/app2/comment_1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 5.58msec/페이지
차이 = +0.01msec(0.1% 증가)
테스트 결과는 놀라웠습니다. 댓글의 길이는 파일 자체의 거의 두 배이지만 댓글의 존재 여부는 응답 시간에 큰 영향을 미치지 않습니다. 따라서 우리는 다음 규칙을 따를 수 있습니다.
적당히 사용되는 한 ASP 주석은 성능에 거의 또는 전혀 영향을 미치지 않습니다.
페이지에 대해 기본 언어를 명시적으로 설정해야 합니까?
IIS는 기본적으로 VBScript를 처리하지만 대부분의 경우 <%@LANGUAGE=VBSCRIPT%> 문을 사용하여 언어가 명시적으로 VBScript로 설정되는 것을 확인했습니다. 다음 테스트에서는 이 선언이 성능에 어떤 영향을 미치는지 조사할 것입니다.
< %@ LANGUAGE=VBSCRIPT % >
<% 옵션 명시적
희미한 이름
…
/app2/언어1.asp 조각.
기준 = 5.57msec/페이지
응답 시간 = 5.64msec/페이지
차이 = +0.07msec(1.2% 증가)
보시다시피 언어 선언을 포함하는 것은 성능에 약간의 영향을 미칩니다. 그러므로:
* 사이트에서 사용되는 언어와 일치하도록 서버의 기본 언어 구성을 설정합니다.
* 기본이 아닌 언어를 사용하지 않는 한 언어 선언을 설정하지 마십시오.
필요하지 않은 경우 세션 상태를 꺼야 합니까?
IIS 세션 컨텍스트를 사용하지 않는 데에는 여러 가지 이유가 있으며 이에 대한 내용은 해당 기사에서 다루어질 수 있습니다. 지금 우리가 대답하려는 질문은 페이지에 필요하지 않을 때 세션 컨텍스트를 닫는 것이 성능 향상에 도움이 되는지 여부입니다. 이론적으로는 '예'여야 합니다. 그러면 세션 컨텍스트를 인스턴스화하기 위해 페이지를 사용할 필요가 없기 때문입니다.
버퍼와 마찬가지로 세션 상태를 구성하는 방법에는 스크립트와 서버 설정을 통해 두 가지가 있습니다.
스크립트를 통해 세션 컨텍스트 닫기
이 테스트에서는 페이지에서 세션 컨텍스트를 닫기 위해 세션 상태 선언을 추가했습니다.
< %@ ENABLESESSIONSTATE = 거짓 % >
<% 옵션 명시적
희미한 이름
…
/app2/session_1.asp 조각.
기준 = 5.57msec/페이지
응답 시간 = 5.46msec/페이지
차이 = -0.11msec(2.0% 감소)
이런 작은 노력으로 좋은 진전이 있었습니다. 이제 두 번째 부분을 살펴보세요.
서버 구성을 통해 세션 컨텍스트를 닫습니다.
서버에서 세션 컨텍스트를 닫으려면 사이트의 속성 대화 상자로 이동하세요. 홈 디렉터리 탭에서 구성 버튼을 선택합니다. 그런 다음 앱 옵션에서 세션 상태 활성화를 선택 취소합니다. ENABLESESSIONSTATE 문 없이 테스트를 실행합니다.
기준 = 5.57msec/페이지
응답 시간 = 5.14msec/페이지
차이 = -0.43msec(7.7% 감소)
이는 성능의 또 다른 중요한 개선입니다. 따라서 우리의 규칙은 다음과 같습니다: 필요하지 않은 경우 항상 페이지 또는 애플리케이션 수준에서 세션 상태를 닫습니다.
Option Explicit를 사용하면 성능이 크게 변경되나요?
사용하기 전에 모든 변수가 페이지에서 선언되도록 하려면 ASP 페이지 상단에 Option Explicit를 설정하십시오. 여기에는 두 가지 이유가 있습니다. 첫째, 애플리케이션은 변수 액세스를 더 빠르게 처리할 수 있습니다. 둘째, 이는 실수로 변수 이름을 잘못 사용하는 것을 방지합니다. 이 테스트에서는 Option Explicit 참조와 변수의 Dim 선언을 제거합니다.
기준 = 5.57msec/페이지
응답 시간 = 6.12msec/페이지
차이 = +0.55msec(9.8% 증가),
페이지에서 일부 코드 줄이 제거되었음에도 불구하고 응답 시간은 여전히 증가했습니다. 따라서 명시적인 Option을 사용하는 것은 때로는 시간이 많이 소요되지만 성능에는 상당한 영향을 미칩니다. 그래서 우리는 또 다른 규칙을 추가할 수 있습니다: 항상 VBScript에서는 명시적인 Option을 사용하십시오.
스크립트 로직을 서브루틴과 기능 영역에 배치해야 합니까?
함수와 서브루틴을 사용하는 것은 특히 코드 영역이 페이지에서 여러 번 사용될 때 코드를 구성하고 관리하는 좋은 방법입니다. 단점은 동일한 작업을 수행하는 시스템에 추가 함수 호출을 추가한다는 것입니다. 서브루틴과 함수의 또 다른 문제는 변수의 범위입니다. 이론적으로는 기능 영역 내에서 변수를 지정하는 것이 더 효율적입니다. 이제 이 두 가지 측면이 어떻게 작용하는지 살펴보겠습니다.
Response.Write 문을 서브루틴으로 이동
이 테스트는 단순히 Response.Write 문을 서브루틴 영역으로 이동합니다.
…
writeTable() 호출
하위 쓰기 테이블()
응답.쓰기(<html>&_
＜ 머리 ＞ & _
…
<tr >< td >< b >이메일:< /b >< /td >< td > & 이메일 & < /td >< /tr > & _
< tr >< td >< b >생년월일:< /b >< /td >< td > & 생년월일 & < /td >< /tr > & _
＜ /테이블 ＞ & _
＜ /본체 ＞ & _
＜ /html ＞)
끝부분
/app2/function1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 6.02msec/페이지
차이 = +0.45msec(8.1% 증가)
예상대로 서브루틴 호출은 페이지에 추가 오버헤드를 발생시킵니다.
모든 스크립트를 서브루틴으로 이동
이 테스트에서는 Response.write 문과 변수 선언이 서브루틴 영역으로 이동됩니다.
<% 옵션 명시적
writeTable() 호출
하위 쓰기 테이블()
희미한 이름
…
희미한 생년월일
이름 = John
…
생년월일 = 1950년 1월 1일
응답.쓰기(<html>&_
＜ 머리 ＞ & _
<title>응답 테스트<//title> & _
＜ /머리 ＞ & _
<몸> & _
< h1 >응답 테스트< /h1 > & _
＜ 테이블 ＞ & _
< tr >< td >< b >이름:< /b >< /td >< td > & 이름 & < /td >< /tr > & _
…
< tr >< td >< b >생년월일:< /b >< /td >< td > & 생년월일 & < /td >< /tr > & _
＜ /테이블 ＞ & _
＜ /본체 ＞ & _
＜ /html ＞)
끝부분
/app2/function2.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 5.22msec/페이지
차이 = -0.35msec(6.3% 감소)
매우 흥미롭습니다! 변수를 함수 범위로 이동하면 추가 함수 호출이 추가되지만 실제로는 성능이 향상됩니다. 다음 규칙을 추가할 수 있습니다.
* 한 페이지에서 코드를 두 번 이상 사용하려면 기능 영역에 코드를 넣으세요.
* 적절한 경우 변수 선언을 함수 범위로 이동합니다.
포함 파일 사용의 의미는 무엇입니까?
ASP 프로그래밍의 중요한 기능은 다른 페이지의 코드를 포함한다는 것입니다. 이 기능을 사용하면 프로그래머는 여러 페이지에서 기능을 공유할 수 있으므로 코드를 더 쉽게 유지 관리할 수 있습니다. 단점은 서버가 여러 소스로부터 페이지를 조합해야 한다는 것입니다. 다음은 포함 파일을 사용한 두 가지 테스트입니다.
인라인 코드를 사용하여 파일 포함
이 테스트에서는 작은 코드 조각이 포함 파일로 이동되었습니다.
<% 옵션 명시적
희미한 이름
…
희미한 생년월일
이름 = John
…
생년월일 = 1950년 1월 1일
%>
＜ !-- #include 파일=inc1.asp -- ＞
/app2/include_1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 5.93msec/페이지
차이 = +0.36msec(6.5% 증가)
이것은 놀라운 일이 아닙니다. 페이로드는 포함 파일을 사용하여 구성됩니다.
기능 영역에서 포함 파일 사용
여기서 코드는 포함 파일의 서브루틴으로 래핑됩니다. 포함 참조는 페이지 상단에 작성되며 ASP 스크립트의 적절한 위치에서 서브루틴을 호출합니다.
<% 옵션 명시적
희미한 이름
…
희미한 생년월일
이름 = John
…
생년월일 = 1950년 1월 1일
writeTable() 호출
%>
＜ !-- #include 파일=inc2.asp -- ＞
/app2/include_2.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 6.08msec/페이지
차이=+0.51msec(9.2% 증가)
이는 함수 호출보다 성능에 더 큰 영향을 미칩니다. 따라서 페이지 간에 코드가 공유되는 경우에만 포함 파일을 사용하십시오.
오류 처리를 수행할 때 부하가 얼마나 발생합니까?
모든 실제 애플리케이션에는 오류 처리가 필요합니다. 이 테스트에서는 On Error Resume Next 함수를 호출하여 오류 처리기를 호출합니다.
<% 옵션 명시적
오류 발생 시 다음 재개
희미한 이름
…
/app2/error_1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 5.67msec/페이지
차이 = 0.10msec(1.8% 증가)
보시다시피 오류 처리에는 대가가 따릅니다. 다음을 제안할 수 있습니다. 테스트하거나 제어할 수 없는 일이 발생하는 경우에만 오류 핸들을 사용하세요. 기본적인 예는 COM 개체를 사용하여 ADO 또는 FileSystem 개체와 같은 다른 리소스에 액세스하는 것입니다.
컨텍스트 핸들러 설정이 성능에 영향을 미치나요?
오류가 발생하면 페이지에 컨텍스트 핸들러를 설정하면 스크립트가 작업을 되돌릴 수 있습니다. 이는 페이지의 처리 문을 사용하여 설정됩니다.
＜ %@ 거래 = 필수 % ＞
<% 옵션 명시적
희미한 이름
…
/app2/transact1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 13.39msec/페이지
차이 = +7.82msec(140.4% 증가)
아! 그야말로 가장 드라마틱한 결과다. 따라서 다음 규칙에 유의하십시오. 둘 이상의 작업이 하나의 단위로 수행되는 경우에만 처리 컨텍스트를 사용하십시오.
결론적으로
이 글의 첫 번째 부분에서 중요한 것은 많은 작은 것들이 쌓이는 것입니다. 이 문제를 강조하기 위해 이전에 테스트한 모든 작업을 수행하는 최종 테스트를 설정했습니다. 무해해 보이지만 실제로는 나쁜 영향을 미쳤습니다. 여러 개의 Response.Write 문을 포함하고, 버퍼를 끄고, 기본 언어를 설정하고, Option Explicit 참조를 제거하고, 오류 처리기를 초기화했습니다.
< %@ LANGUAGE=VBSCRIPT % >
< %
오류 발생 시 다음 재개
이름 = John
…
생년월일 = 1950년 1월 1일
응답.쓰기(<html>)
응답.쓰기(<head>)
Response.Write(<title>응답 테스트</title>)
응답.쓰기(</head>)
응답.쓰기(<본문>)
응답.쓰기(<h1>응답 테스트</h1>)
응답.쓰기(<테이블>)
Response.Write(< tr >< td >< b >이름:< /b >< /td >< td > &_
이름 & < /td >< /tr >)
…
Response.Write(< tr >< td >< b >생년월일:< /b >< /td >< td > &_
생년월일 & < /td >< /tr >)
응답.쓰기(</table>)
응답.쓰기(</body>)
응답.쓰기(</html>)
%>
/app2/final_1.asp 조각
기준 = 5.57msec/페이지
응답 시간 = 8.85msec/페이지
차이 = +3.28msec(58.9% 증가)
당연하게 들릴 수도 있지만 페이지에 배치하는 코드가 성능에 영향을 미친다는 점을 이해하는 것이 더 중요합니다. 페이지의 작은 변경으로 인해 응답 시간이 크게 늘어날 수 있습니다.
규칙 요약
* 인라인 ASP의 과도한 사용을 피하십시오.
* 항상 연속된 Response.Write 문을 단일 문으로 연결하세요.
* CRLF를 추가하기 위해 Response.Write 주위에 래퍼 함수를 사용하지 마십시오.
* HTML 출력 형식을 지정해야 하는 경우 Response.Write 문 내에 CRLF를 직접 추가하세요.
* 항상 서버 설정을 통해 버퍼링을 활성화하십시오.
* 적당히 사용하는 한 ASP 주석은 성능에 거의 또는 전혀 영향을 미치지 않습니다.
* 사이트에서 사용되는 언어와 일치하도록 서버의 기본 언어 구성을 설정합니다.
* 기본이 아닌 언어를 사용하지 않는 한 언어 선언을 설정하지 마십시오.
* VBScript에서는 항상 명시적인 옵션을 사용하세요.
* 필요하지 않은 경우 항상 페이지 또는 애플리케이션 수준에서 세션 상태를 끄십시오.
* 페이지 간에 코드가 공유되는 경우에만 포함 파일을 사용하세요.
* 한 페이지에서 코드를 두 번 이상 사용하려면 기능 영역에 코드를 넣으세요.
* 적절한 경우 변수 선언을 함수 범위로 이동합니다.
* 테스트 또는 제어 능력을 넘어서는 조건이 발생하는 경우에만 오류 핸들을 사용하십시오.
* 두 개 이상의 작업이 하나의 단위로 수행되는 경우에만 컨텍스트 처리를 사용하십시오.
지금 돌이켜보면 일반적인 지침이 될 수 있는 질문이 많이 있습니다.
* 중복 방지 - 이미 기본적으로 설정된 속성을 설정하지 마세요.
* 함수 호출 횟수를 제한하세요.
* 코드의 범위를 줄입니다.