출처: Microsoft TechNet (http://www.microsoft.com/korea/technet/IIS/Tips/asptips17_29.asp)
1. 자주 사용되는 데이터는 웹 서버에 캐시하라
가. 자주 변경되지 않는 것은 데이터베이스에서 직접 액세스하지 말고 캐쉬하라.
나. 캐쉬 대상 : 콤보 상자 목록, 참조 테이블, DHTML 스크랩, XML(Extensible Markup Language) 문자열, 메뉴 항목과 데이터 원본 이름(DSN), 인터넷 프로토콜(IP) 주소 및 웹 경로를 포함하는 사이트 구성 변수
다. HTML 문서로 저장
라. 자주 사용되는 데이터는 메모리(Application변수나 Session 변수)에 캐쉬한다.
마. 데이터 및 HTML은 웹 서버 디스크에 캐시하십시오
(1) 메모리에 캐시할 데이터가 너무 많은 경우에는 데이터를 텍스트 또는 XML 파일 형식으로 웹 서버의 하드 디스크에 캐시한다.
(2) ADO의 RecordSet의 Save() 및 Open() 함수를 활용하여 디스크에 저장
(3) Scripting.FileSystemObject를 이용하여 파일로 저장
2. 덩치 큰 COM 개체 등은 메모리에 캐쉬하지 마라.
3. 데이터베이스 연결은 응용 프로그램이나 세션 개체에 캐시하지 마라.
4. 세션 개체를 올바르게 사용하라.
가. 웹 서버에 대한 사용자 "Sticking" 현상 발생
나. 세션을 사용하고 있지 않으면 세션 기능을 반드시 해제
<% @EnableSessionState=False %>
다. 상태의 크기가 4KB 미만으로 작은 경우에는 일반적으로 쿠키, QueryString 변수 및 <input type=hidden>를 사용하는 것이 좋다
5. 스크립트 코드를 COM 개체로 만들어 사용하라.
가. COM 개체는 비즈니스 로직으로부터 표현 로직을 분리할 수 있다.
나. COM 개체는 코드 재사용을 가능케 한다.
다. 작은 양의 ASP는 COM으로 안 만드는 것이 좋다.
6. 최신의 리소스를 얻어 신속하게 해제하라.
가. 다운로드 컴포넌트
나. 신속하게 Close하고 Nothing을 설정하라.
7. 독립 프로세스 실행을 통해 성능과 안정성을 적절히 안배하십시오
가. 낮은 격리 : 모든 IIS 버전에서 지원되며 속도가 가장 빠릅니다
나. 보통 격리 : 독립 프로세스로 실행
다. 높은 격리 : 독립 프로세스로 실행. ASP 작동이 중단되더라도 웹 서버 작동은 유지. 동시 접속자 수가 증가할 경우에만 높은 격리를 사용하는 것이 좋다.
※ ASP 응용 프로그램을 독립 프로세스(보통 또는 높음 격리)로 실행하면 ASP 응용 프로그램은 Windows NT4의 경우 Mtx.exe로 실행, Windows 2000의 경우 DllHost.exe로 실행된다.
※ 권장 사항 : IIS 4.0에서는 ASP의 낮음 격리 수준을, IIS 5.0에서는 ASP의 보통 격리 수준을 사용하고 COM+ 라이브러리 응용 프로그램을 사용하라.
8. Option Explicit를 사용하십시오
가. Option Explicit는 ASP 스크립트의 첫 번째 줄에 사용한다.
나. 모든 변수를 먼저 선언해야 한다. 만약 선언하지 않을 경우 에러가 발생된다.
다. 변수 이름의 오타를 막을 수 있다.
라. 선언된 변수가 선언되지 않은 변수보다 빠르게 실행된다.
(1) 선언되지 않은 변수 : 스크립팅 실행 시간에 필요할 때마다 변수 선언하여 사용
(2) 선언된 변수 : 컴파일 시간 또는 실행 시간에 미리 할당
9. 가급적 전역 변수보다는 함수 내의 지역 변수를 사용하라.
10. 자주 사용되는 데이터를 변수에 저장하라.
가. COM 개체에서 읽어온 데이터
나. Request 변수(Form 및 QueryString 변수)
11. 배열 크기 재정의를 피하라.
가. 배열 크기가 불확실할 때에는 적당하게 크게 잡아라. 약간의 낭비가 오히려 낫다.
12. 응답 버퍼링을 사용하십시오
가. IIS : IIS를 이용한 전체 응용 프로그램의 응답 버퍼링 기능을 설정(권장 사항)
나. 스크립트 : Response.Buffer를 true로 설정, 이것은 HTML이 ASP 스크립트에 나타나기 이전과 Response.Cookies 컬렉션을 사용하여 쿠키가 설정되기 이전에 미리 실행되어야 한다.
다. 중간 중간에 버퍼링되 내용을 출력할 때 Response.Flush를 사용한다. 예를 들어, 1,000개의 행으로 구성된 테이블에서 100개의 행을 표시한 후 ASP는 Response.Flush를 호출하여 브라우저에 보낸다. 그러나 대부분 </table> 태그가 나타날 때까지는 대부분의 브라우저에서 테이블 표시를 시작할 수 없으므로 100개씩 테이블을 쪼개서 나타낸다.
13. 인라인 스크립트 및 Response.Write 명령문을 일괄 처리하십시오
가. 여러 개의 인접한 인라인 표현식들을 한 번의 Response.Write 호출로 바꾸라.
14. 실행 시간이 긴 페이지를 만들 때 Response.IsClientConnected를 사용하십시오.
가. False가 반환되면 Response.End를 호출하여 나머지 페이지를 포기한다.
나. IIS 5.0에서는 이러한 절차를 코드화했다. 즉 3초를 지나면 클라이언트가 아직도 연결되어 있는지를 검사하여 클라이언트 연결이 끊어져 있으면 그 즉시 해당 요청을 종료한다.
15. <OBJECT> 태그를 사용하여 개체를 초기화하십시오
가. Server.CreateObject 메서드보다는 <object runat=server id=objname> 태그를 사용하라.
나. <object id=objname> 태그는 개체 이름을 선언만 하고 있다가 호출될 때 비로서 만들어진다.
16. TypeLib 선언을 ADO 및 그 밖의 다른 구성 요소에 사용하십시오
가. IIS 5.0에는 구성 요소의 유형 라이브러리에 대한 바인드 기능이 새로 추가되었다.
나. ADO 상수를 사용할 때에는 다음 명령문을 Global.asa에 넣으라.
<!-- METADATA NAME=“Microsoft ActiveX Data Objects 2.5 Library”
TYPE=“TypeLib” UUID=“{00000205-0000-0010-8000-00AA006D2EA4}” -->
17. 서버에 값을 넘기기 전에 클라이언트에서 유효성 검사하라.
18. 루프 형식의 문자열 연결을 피하라.
가. 반복적인 문자열 연결로 인해 제곱 배의 시간이 소요된다. 다음 예의 걸린 시간은 1+2+3+...+N, 즉 N*(N+1)/2이다.
s = “”
For i = Asc(“A”) to Asc(“Z”)
s = s & Chr(i)
Next
나. 이 경우 Response.Write()로 바꾼다.
다. JScript인 경우에는 +=이 효율적이다.
s=s+"a"는 s+="a"에 비해 비 효율적이다.
19. 브라우저 및 프록시 캐싱을 사용하십시오.
가. response 객체 사용
<% Response.Expires = 10 %>
<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>
나. <meta>태그 이용
<META HTTP-EQUIV=“Expires” VALUE=”May 31,2001 13:30:15”>
다. HTTP 프록시에서 캐쉬
<% Response.CacheControl = “Public” %>
20. 가능하면 Response.Redirect가 아닌 Server.Transfer를 사용하라.(IIS 5.0)
가. 브라우저가 웹 서버에 두 번 왕복 이동한다.
나. Server.Transfer : 이동한 페이지에서 종료된다.
다. Server.Execute : 이동한 페이지에서 종료 후에 원래 페이지로 복귀한다.
21. 디렉터리 URL의 맨 마지막에 슬래시를 추가한다.
가. 슬래시가 생략되면 기본 문서가 아닌 디렉토리를 요청한 후에 기본 문서나 디렉토리 찾아보기를 실행한다.
나. <a href=“http://msdn.microsoft.com”>를 <a href=“http://msdn.microsoft.com”>로 수정한다.
22. Request.ServerVariables 사용을 피하십시오
가. Request.ServerVariables에 액세스하면 웹 사이트가 서버에게 특수한 요청을 보내어 요청한 변수 뿐만 아니라 모든 서버 변수들을 모은다.
나. Request("Data")을 요청할 경우 Request.Cookies, Request.Form, Request.QueryString 또는 Request.ClientCertificate에 들어 있지 않은 항목에 대해서는 Request.ServerVariables를 호출한다.
다. Request.ServerVariables 컬렉션 속도는 다른 컬렉션 속도보다 매우 느리다.
23. 시스템 구성 요소를 최신으로 업그레이드하십시오
24. 성능 테스트를 하라.
가. Microsoft WAS(Web Application Stress) 도구 : 웹 서버를 방문하는 사용자들을 수 백명 또는 수 천명까지 시뮬레이트할 수 있다.
나. WAS는 초당 요청수, 응답 시간 배포, 오류 카운트 등을 파악
25. Stored Procedure를 사용한다. (일반 ASP자체 쿼리보다 최고 30% 성능 향상.)
26. 뷰테이블 사용 시 뷰테이블 자체에서 정렬을 해야 한다. 이미 만들어진 뷰테이블을 이용하여 Asp 코드에서 정렬하면 속도가 크게 떨어진다.
27. Query를 사용할 때 꼭 필요한 컬럼만 명시하여 불러오거나 이용해야 한다. SQL은 아주 정직해서 불러오는 컬럼의 갯수(레코드 수가 동일하다고 가정시)에 비례하여 시간이 걸린다.
28. Recordset 객체보다는 Command 객체를 이용하는 것이 빠르다. 10%정도의 향상을 볼 수 있었다.
29. Recordset 객체 사용시 CursorLocation를 적절한 것을 사용해야 한다. (1, 서버, 3. 클라이언트) 속도의 차이가 클 수 있다. CursorType도 영향을 미친다. 반드시 테스트 필요. 보통은 CursorLocation은 클라이언트에 두는 것이 추세다. 테스트때 클라이언트에 커서를 두었을때 서버에 두었을때보다 속도가 최고 3배이상 빨라지는 것을 경험했다.
30. 1000글자가 넘어가는 문장의 경우는 변수에 담아서 한번에 Response.Write 하는 것보다는 한 줄 한 줄 직접 뿌려주는 것이 빠르다.
31. 사용한 객체는 반드시 Close, Nothing 해준다. 안 해주면 메모리 누수가 일어난다. 웹서버들이 잘 죽는 경우는 반드시 이것을 체크해야 한다.
32. 다중 레코드를 이용할 시에는 Do until, Rs.MoveNext 구문보다는 GetRows() 함수를 이용하는 것이 빠르다.
33. 사용자 Function을 만들어 쓰는 것이 디버깅 등에 좋다.
34. Inlcude를 많이 시키면 속도가 느려진다고 일반적으로 알려져 있지만 실제로는 속도차이가 전혀 없다.
35. 뷰 테이블에 아무리 많은 테이블, 컬럼들을 Join 해도 단일 테이블의 같은 수의 컬럼을 사용하는 속도와 동일하다.
36. 보안 철저
가. 수시로 windows 보안 업데이트
나. 파일 업로드 위치에는 절대로 스크립트 실행 권한을 주지 않는다.
다. asp 스크립트가 주석 처리되지 않도록 한다.
