lecture Home > ASP Tips > ASP에서 성능문제 향상방법

ASP에서 성능문제 향상방법

   강좌 최초 작성일 : 2000년 04월 02일
   강좌 최종 수정일 : 2001년 07월 17일

   작성자 : Taeyo(김 태영)
   편집자 : Taeyo(김 태영)

   강좌 제목 : ASP 스크립트에서 성능 문제를 최소로 줄이는데 도움이 되는 몇 가지

강좌 전 태오의 잡담>

유 머스트 컴배콤... 히히

강좌 시작 >

아래의 내용은 IIS 5관련 도큐먼트를 읽다가 나온 내용중에 무엇보다 중요하다고 느껴지는 문서가 있길래 그 문서에 제 의견을 추가해서 함 올려보았습니다. 그러니,원래의 원본 문서의 모든 copyright는 MS에게 있겠지요? 그 일부를 그대로 인용했구요.. 사이사이 제 의견을 넣어보았습니다.  ^__^

ASP 스크립트에서 성능 문제를 최소로 줄이는데 도움이 되는 몇 가지 팁

1. 첫번째....   

Global.asa에 개체를 작성하거나 각각의 ASP 스크립트에 요구에 따라 개체를 작성하여 응용 프로그램 영역에 위치시킴으로써 응용 프로그램 영역의 개체와 데이터를 캐시하십시오. IIS 5.0에서는 기본값으로 설정되어 있는 ASP 버퍼링에 의해 Response.Write 호출의 출력을 결합하십시오. 시간이 많이 걸리는 작업을 수행하는 동안 버퍼링된 출력을 사용하는 응용 프로그램의 인지 성능을 개선하려면 응용 프로그램이 주기적으로 Reponse.Flush를 사용하여 사용자와의 접촉을 유지 관리해야 합니다. 

웹 응용 프로그램에 ASP 버퍼링을 사용 불가능으로 설정한 경우에는 개별 출력 문자열을 하나의 더 큰 문자열로 결합하여 Response.Write에 대한 호출 수를 줄임으로써 성능을 향상시킬 수 있습니다. 그러나 이를 달성하기 위해 확장 문자열 조작을 수행하면 성능은 개선되는 반면 문자열을 처리하는 시간은 더 오래 걸려 그 효과가 상쇄됩니다. 

즉, 버퍼를 사용하시라는 이야기입니다... 그래서, Win 2000(IIS 5)에서는 모든 ASP 페이지가 기본적으로 버퍼를 사용하고 있답니다. 그렇다면 버퍼를 잘 사용할 줄 알아야 하겠네요  ^^ 그쵸?

2. 두번째 

응용 프로그램 영역이나 세션 영역에서 개체의 인스턴스를 만들 때 Server.CreateObject 대신 <OBJECT> 태그를 사용하십시오. IIS는 개체가 실제로 사용될 때까지 <OBJECT> 태그로 지정된 개체의 인스턴스 작성을 지연시키기 때문입니다. <OBJECT> 태그를 사용하면 스크립트가 해당 개체를 사용하기 전에는 응용 프로그램이 개체의 인스턴스를 만들지 않습니다. 반대로 Server.CreateObject를 사용하면 개체가 스크립트에서 사용되는지 여부와는 상관 없이 개체의 인스턴스가 즉시 작성됩니다. 

그러니까 가능하다면 다음처럼 사용하라는 이야기인 것 같습니다.

기존의 소스 :
<%
   Set dbcon = Server.CreateObject("ADODB.Connection")
  dbcon.open("DSN=***;UID=***;PWD=***;")
   .....
%>

개선(?)된 소스 :
<OBJECT RUNAT=server PROGID=ADODB.Connection id=dbcon></OBJECT>
<%
  dbcon.open("DSN=***;UID=***;PWD=***;")
   .....
%>

3. 세번째

지역 변수를 사용하고 공용 변수를 가급적 사용하지 마십시오. 지역 변수 값에 액세스하기 위해 이름 공간 전체를 찾을 필요가 없기 때문에 ASP 스크립트 엔진은 공용 변수보다 지역 변수에 더 빨리 액세스할 수 있습니다. 

4. 네번째 

가능하면 HTTP 라운드 트립의 필요성을 최소화하기 위해 사용자 입력에 대해 클라이언트쪽 유효성 검사를 사용하십시오. 모든 기능이 갖추어져 있는 강력한 브라우저를 사용하면 더 중요한 작업에 사용하기 위해 서버쪽 리소스를 남겨둡니다. 응용 프로그램에 따라 데이터 손상을 방지하기 위해 서버에서 무결성 검사를 일부 수행해야 합니다. 

이 이야기는  이미 제 스터디때에도 나왔던 이야기입니다만. 클라이언트 스크립트의 중요성을 시사하는 글 같습니다. 가능하다면 서버의 부하를 줄이기 위해 클라이어트 스크립트로 체크할 수 있는 내용은 다 검사하라는 것이지요... 그리고, 만약을 위해서 서버측에서는 확인차원으로 가장 문제가 되는 내용만을 재 검사해주면 되겠구요... 역시 클라이언트 스크립트는 중요함다.

하긴, 이 것도 ASP.NET 이 등장하면 필요없는 이야기일 수 있겠네요. .NET 에서는 유효성확인 컨트롤이 제공되기에.. 클라이언트 스크립트로 굳이 체크하지 않아도 되거든요.. 손쉽게 말이지요

5. 다섯번째

값을 두 번 이상 참조하는 경우에는 값 집합에서 개별 값을 지역 변수로 복사하십시오. 이렇게 하면 ASP는 각 참조나 모든 참조에 대해 조회 작업을 하지 않아도 됩니다. 

6. 여섯번째

가능하면 전체 응용 프로그램의 세션 상태를 해제하십시오. 응용 프로그램에서 IIS 세션을 사용하지 않아도 되는 경우에는 인터넷 정보 서비스 스냅인을 사용하여 전체 응용 프로그램의 세션 상태를 사용 불가능으로 설정해야 합니다. IIS의 세션은 메모리에 남게 되고 세션에 할당된 메모리는 세션이 종료되거나 시간 초과될 때까지는 계속 사용됩니다. 동시에 많은 사용자가 응용 프로그램을 사용할 경우에는 서버 자원이 고갈되어 성능에 영향을 줄 수 있습니다. 응용 프로그램의 일부에 세션 상태가 필요 없으면 @ENABLESESSIONSTATE 지시어를 사용하여 해당 페이지에 대한 세션 상태를 사용 불가능으로 설정해야 합니다. 

7. 일곱번째

페이지에 <FRAMESET> 요소가 포함되어 있는 경우에는 가능한 세션 상태를 해제하는 것이 좋습니다. Internet Explorer를 포함하여 일부 브라우저는 별도의 스레드를 사용하여 프레임셋의 각 프레임을 처리합니다. 프레임셋 페이지에 대해 세션 상태를 사용하면, IIS는 독립된 요청을 처리하는 스레드를 강제로 직렬화하기 때문에 이 병렬 스레드를 사용하여 클라이언트쪽 성능에서 얻는 이점이 사라집니다. 

8. 여덟번째

세션 상태에 의존하고 있는 경우 Session 개체와 세션 상태에 대량의 데이터를 두지 마십시오. IIS의 세션이 지속되면 세션에 할당된 메모리는 세션이 종료되거나 시간 초과될 때까지 계속 할당되어 있으므로 여러 사용자가 동시에 응용 프로그램을 사용하고 있으면 서버 자원이 고갈되어 성능에 영향을 줍니다. 

9. 아홉번째

빈 Session_OnStart 또는 Session_OnEnd를 제공하지 마십시오. IIS와 ASP 구성을 변경할 경우 그 영향을 주의깊게 살펴 보십시오. 자세한 내용은 IIS 구성 최적화를 참고하십시오. 

여섯번째~ 아홉번째 까지의 이야기가 다 세션에 관계된 것인데요. 간단하게 세션은 가능하면 사용하지 않는 것이 여러모로 좋습니다.세션이 꼭 필요한 경우는 거의 없는 듯 합니다

간혹, 세션변수에 객체(예를 들면,디비커넥션 객체나, 레코드 셋 객체)를 담아두시는 분이 있는 데 그것은 결코 피하셔야 하는 방법입니다. 여덟번째 이야기가 그것인데, 아주 중요합니다. 이렇게 세션변수에 객채들 담아두면 서버는 힘이 너무 듭니다.. T.T

그리고, 많은 분들이 세션을 사용하는 것은 세션을 사용할 경우 이 변수를 전역으로 쉽게 사용할 수가 있기 때문인데요. 그렇다는 것은 코딩도 많이 줄어든다는 것을 의미합니다.. 그리고, 필요한 변수를 특정 페이지에서 얻어내려고 페이지간에 계속 넘겨주어야 한다는 것은 노가다처럼 느껴지기도 하니까요..

그러나, 잠깐의 노가다가 서버의 성능을 엄청나게 바꾸어 놓을 수 있습니다. 세션을 사용하기 전 반드시 스스로에게 물어보세요...반드시 세션이 필요한가???  미래를 바라보시구 말입니다....

굳이 사용자정보를 임시적으로 저장할 공간이 필요하다면 보안적이지 않은 정보들만을 원타임 쿠키에 저장하시기 바랍니다. 그 편이 바람직합니다. 요즘은 거의 세션변수를 사용하지 않는 추세입니다. 서버에 부하를 많이 주니까요 ^^

10. 열 번째

ASP 페이지를 응용 프로그램의 일부로 실행하고 있는 경우에는 응용 프로그램을 응용 프로그램 디버깅을 위한 독립 프로세스로 지정하십시오. IIS 4.0에 도입된 프로세스 격리는 유용한 기능입니다. 그러나 프로세스 격리를 지원하기 위해 필요한 교차 프로세스 마샬링은 ASP 처리에 어느 정도의 오버헤드를 초래할 수 있습니다. 

간단한 ASP 페이지에서는 오버헤드의 차이가 가장 중요하게 고려되지만 더 복잡한 페이지에서는 큰 문제가 되지 않습니다. 그러나 성능과 확장성을 최대화하려면 응용 프로그램이 충분히 디버그되고 IIS와의 종속 프로세스를 실행할 수 있을만큼 충분히 안정될 때까지 응용 프로그램을 독립 프로세스로 실행하는 방안을 고려해야 합니다. 

11. 열 한번째

가급적 ReDimming 배열을 사용하지 마십시오. 배열이 처음 초기화될 때 전체 배열 크기를 할당하는 것이 더 효율적입니다. 

　

대충 이렇다네요... 제가 읽으면서..  "그렇다 맞다... 그러면 빨라지겠구나...  !!"  라구 느낀 것을 위주로 글을 작성해 보았습니다. 그러나, 그것은 개인적은 견해일 뿐... 사실은 이외에도 MSDN이나 IIS 5 Documentation의 모든 내용은....  모두 중요합니다...   ^___^

여러분의 개발시에도 참고할 만한 좋은 내용이기를 바랍니다.

 

Back