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

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

16. 실행 시간이 긴 페이지를 만들 때 Response.IsClientConnected를 사용하십시오. 

참을성이 없는 사용자라면 자신의 요청을 실행하기도 전에 미리 ASP 페이지를 포기해 버릴 수도 있습니다. 이러한 사용자들이 새로 고침을 누르거나 서버의 다른 페이지로 이동하면 새 요청이 ASP 요청 대기열의 맨 끝부분에 넣어지고 연결이 끊긴 요청이 대기열의 중간 부분에 넣어집니다. 이러한 상황은 서버에 과도한 로드가 걸려 있을 때 간혹 발생하는데, 이 경우 요청 대기열이 길어져서 더 많은 응답 시간이 소요되므로 문제가 더욱 악화됩니다. 사용자의 연결이 끊어지면 ASP 페이지를 실행할 지점이 없어집니다. 특히, 속도가 느리고 그 내용이 많은 ASP 페이지인 경우에는 더욱 그렇습니다. Response.IsClientConnected 속성을 사용하면 이러한 상황이 발생했는지를 검사할 수 있습니다. False가 반환되면 Response.End를 호출하여 나머지 페이지를 포기해야 합니다. 실제로 IIS 5.0에서는 이러한 절차를 코드화했습니다. 즉, 새 요청을 실행하려고 할 때마다 ASP는 해당 요청이 대기열에 있었던 기간을 검사합니다. 그 기간이 3초를 초과하는 경우, ASP는 클라이언트가 아직도 연결되어 있는지를 검사하여 클라이언트 연결이 끊어져 있으면 그 즉시 해당 요청을 종료합니다. 메타베이스에 있는 AspQueueConnectionTestTime 설정을 사용하면 이러한 시간 초과 값(3초)을 변경할 수 있습니다. 

매우 긴 실행 시간을 필요로 하는 페이지가 있는 경우에는 간혹 Response.IsClientConnected를 검사해야 합니다. 응답 버퍼링 기능이 설정되어 있는 경우에는 가끔 Response.Flush를 실행하여 무슨 일이 진행되고 있는지를 사용자에게 알리는 것이 좋습니다. 

참고 IIS 4.0에서는 Response.Write를 먼저 실행하지 않으면 Response.IsClientConnected가 제대로 작동하지 않습니다. 또한 버퍼링 기능이 설정되어 있으면 Response.Flush도 실행해야 합니다. IIS 5.0에서는 이들을 실행하지 않더라도 Response.IsClientConnected가 제대로 작동합니다. Response.IsClientConnected를 실행하는데 어느 정도의 대가가 따를 수도 있으므로, Response.IsClientConnected는 500밀리초 이상이 소요되는 작업을 수행하기 전에만 사용해야 합니다. 1초에 수 십개의 페이지를 계속 처리해야 한다는 점에서 보면 500밀리초는 매우 긴 시간입니다. 일반적으로 20개 또는 50개의 테이블 행에 도달할 때마다 테이블 행을 표시하는 경우처럼, 간격이 짧은 루프가 반복될 때 이 속성을 호출하면 안됩니다.

 

17.태그를 사용하여 개체를 초기화하십시오. 

모든 코드 경로, 특히 서버 또는 응용 프로그램 범위 개체에 사용되지 않는 개체를 참조해야 할 경우에는 Server.CreateObject 메서드를 사용하지 말고 Global.asa에서 태그를 사용하여 선언하십시오. Server.CreateObject는 즉시 개체를 만들기 때문에, 나중에 그 개체를 사용하지 않을 경우에는 리소스를 낭비하는 결과를 초래합니다. 태그는 개체 이름(objname)을 선언하지만, 그 개체 이름은 해당 메서드나 속성들 중 하나가 처음으로 사용된 후 비로소 만들어집니다. 

이것은 지연 평가(Lazy Evaluation)의 다른 예입니다.

 

 

18. TypeLib 선언을 ADO 및 그 밖의 다른 구성 요소에 사용하십시오.

ADO를 사용할 때, 개발자가 ADO의 다양한 상수들에 액세스할 목적으로 adovbs.txt를 포함시키는 경우가 간혹 있습니다. 이 파일은 상수가 사용될 모든 페이지에 포함되어야 합니다. 이 상수 파일의 크기는 매우 크기 때문에, 모든 ASP 페이지의 컴파일 시간 및 스크립트 크기에 엄청난 오버헤드가 추가됩니다.

 

IIS 5.0에는 구성 요소의 유형 라이브러리에 대한 바인드 기능이 새로 추가되었습니다. 이 기능을 사용하면 일단 유형 라이브러리를 참조한 이후에 모든 ASP 페이지에서 이를 다시 사용할 수 있습니다. 페이지마다 상수 파일을 컴파일할 필요는 없으므로, 구성 요소 개발자는 ASP에서 사용할 VBScript #include 파일을 만들 필요가 없습니다.

 

ADO TypeLib에 액세스하려면 다음 명령문들 중 하나를 Global.asa에 넣으십시오.

 

<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library" 

TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->

 

또는

 

<!-- METADATA TYPE="TypeLib" 

FILE="C:\Program Files\Common Files\system\ado\msado15.dll" -->

 

 

19. 브라우저의 유효성 검사 기능을 활용하십시오. 

최근에 개발되는 브라우저에서는 XML, DHTML, Java 애플릿 및 원격 데이터 서비스 등과 같은 기능들에 대한 고급 지원 기능을 제공합니다. 가능하면 항상 이러한 기능들을 사용하십시오. 이러한 모든 기술들은 데이터 캐싱 뿐만 아니라 클라이언트측 유효성 검사를 수행하므로 웹 서버에 대한 왕복 이동 시간을 줄여줍니다. 스마트 브라우저를 실행하고 있는 경우, 그 브라우저에서는 약간의 유효성 검사를 수행할 수 있습니다. 예를 들어, POST를 실행하기 전에 신용 카드에 유효한 검사값이 들어 있는지를 검사합니다. 다시 말해서, 가능하면 항상 이러한 기능들을 사용하십시오. 클라이언트 대 서버간 왕복 이동 시간이 줄어들면 서버가 액세스하는 백엔드 리소스 뿐만 아니라 웹 서버에 걸리는 스트레스와 네트워크 트래픽도 줄어듭니다. 단, 브라우저에서 수신하는 초기 페이지의 크기는 더 커집니다. 또한 사용자가 새 페이지를 그다지 자주 페치할 필요가 없으므로 성능이 훨씬 나아집니다. 그렇지만 서버측 유효성 검사를 수행하지 않아도 되는 것은 아닙니다. 서버측 유효성 검사는 항상 수행해야 합니다. 서버측 유효성 검사를 수행하면 브라우저가 클라이언트측 유효성 검사 루틴을 실행하지 않더라도 클라이언트로부터 해킹과 같은 나쁜 데이터가 들어오는 것이 방지됩니다. 

"모든 브라우저에서 실행되는" HTML을 작성할 때 보통 이러한 기능이 사용됩니다. 이는 간혹 성능상의 장점을 제공하는 자주 사용되는 브라우저 기능을 이용하려는 개발자의 의욕을 꺾는 결과를 초래합니다. 따라서 "사용 가능한" 브라우저 종류를 고려해야 하는 고성능 사이트에서 유용한 전략은 가장 자주 사용되는 브라우저에 맞게 페이지를 최적화하는 것입니다. 브라우저 기능 구성 요소를 사용하는 ASP에서는 브라우저 기능들을 간편하게 검색할 수 있습니다. Microsoft FrontPage와 같은 도구를 사용하면 원하는 HTML 버전과 브라우저에서 작동하는 코드를 설계하는데 도움이 됩니다. 자세한 내용은 When is Better Worse? Weighing the Technology Trade-Offs를 참조하십시오.

 

 

20. 루프 형식의 문자열 연결을 피하십시오.

대부분의 개발자들은 다음과 같은 루프 형식의 문자열을 사용합니다.

 

s = "<table>" & vbCrLf

For Each fld in rs.Fields

s = s & " <th>" & fld.Name & "</th> "

Next

 

While Not rs.EOF

s = s & vbCrLf & " <tr>"

For Each fld in rs.Fields

s = s & " <td>" & fld.Value & "</td> "

Next

s = s & " </tr>"

rs.MoveNext

Wend

 

s = s & vbCrLf & "</table>" & vbCrLf

Response.Write s

 

이러한 접근 방법에는 몇 가지 문제가 있습니다. 첫번째 문제는 반복적인 문자열 연결로 인해 제곱 배의 시간이 소요된다는 점입니다. 공식적인 수치는 아니지만, 이러한 루프를 실행하는데 소요되는 시간은 레코드 수와 필드 수를 곱한 값의 제곱에 비례합니다. 이는 아래의 간단한 예를 살펴보면 더욱 분명해집니다.

 

s = ""

For i = Asc("A") to Asc("Z")

s = s & Chr(i)

Next

 

첫번째 반복에서 한 개의 문자로 구성된 문자열("A")이 얻어집니다. 두번째 반복에서 VBScript는 문자열을 다시 할당하고 두 개의 문자("AB")를 s에 복사해야 합니다. 세번째 반복에서 VBScript는 다시 s를 할당하고 세 개의 문자를 s에 복사해야 합니다. N번째(26번째) 반복에서 VBScript는 s를 다시 할당하고 N개의 문자를 s에 복사해야 합니다. 따라서 그 복사 합계는 1+2+3+...+N, 즉 N*(N+1)/2입니다.

 

위의 레코드 집합 예에서 레코드 수가 100개이고 필드 수가 5개인 경우에는 100*5 = 500회의 내부 루프가 실행되어야 하며, 모든 복사 및 재할당에 소요되는 시간은 500*500 = 250,000입니다. 이러한 수치는 보통 크기의 레코드 집합인 경우에는 아주 큰 값입니다.

 

이 예에서 문자열 연결을 Response.Write()로 바꾸거나 인라인 스크립트(<% = fld.Value %>)로 바꾸면 코드 성능이 향상될 수 있습니다. 응답 버퍼링 기능이 설정되어 있으면 Response.Write가 데이터를 응답 버퍼의 끝에 추가하므로 그 속도가 더욱 빨라집니다. 또한 재할당 동작이 발생하지 않으므로 아주 효율적입니다.

 

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

 

문자열을 JScript에 연결하는 경우에는 반드시 += operator; that is, use s += "some string", not s = s + "some string"을 사용하십시오.