강좌 전 태오의 잡담>

ASP라는 것을 처음 만들어 낸 사람은 누구일까요? 저도 궁금했었는데... 그 사람은 바로 '스캇 구슬이(Scott Guthrie)' 라구 하네요.. 성이 좀 웃기지만.. ^^  대단한 사람인 것 같죠?

강좌 시작 >

오늘의 강좌는 Professional ASP.NET 책에서 일부 발췌하여 정리한 강좌입니다. 스캇 구쓰리 라는 사람이 제안하는 ASP.NET에서의 퍼포먼스 관련 팁들이지요..

강좌의 내용이 그리 길지는 않을 것입니다만. ASP.NET을 공부하고자 할 경우 반드시 알아두면 좋을만한 내용들로 가득 차게 될 겁니다. 저도 읽으면서 오오~~  ASP에서 ASP.NET으로 바꾼다면 이 정도의 성능의 향상을 볼 수 있는 것인가? 하고 놀랐으니까요..

그리고, 무조건 ASP에서 ASP.NET 으로 바꾸는 것만이 최선은 아닐 것이라는 개인적인 사견도.. 잠시 지나가는 말로 드립니다.  ASP에서 ASP.NET 으로 바꾸면 대부분은 나은 성능이나 환경을 구축할 수가 있겠지만, 작은 기업환경에서는 오히려 ASP로 구동시킬 경우 더 나을 경우가 얼마든지 있을 수 있다는 개인적인 느낌입니다. 물론, Believe it or Not 입니다. ^^

이번 강좌에서 그런 부분에 대한 힌트도 얻어보시길 바란답니다. ^^

1. ASP.NET은 ASP보다 빠르다??

여러분이 ASP.NET에 대한 글을 조금이라도 읽어보셨다면 "ASP.NET 페이지들은 처음 실행할 때, 컴파일이 되어지고 그 어셈블리가 메모리에 올라오게 되어, 일단 한번 컴파일이 되고나면 속도가 매우 빠르다" 라고들 들으셨을 것입니다. 같은 요청을 두번이상 한다면, 그 때부터는 메모리에서 바루 데이터를 가져오는 것이기에 빠를 수 밖에 없죠.

물론, 그 말은 맞습니다. 하지만, 이 말은 다르게 표현하면 "ASP.NET 페이지는 처음 로드시에는 ASP보다 느리다." 라고도 말할 수 있겠죠? 그렇다면, 코드가 대단히 적어서, 컴파일을 해서 메모리에 올려놓고 그 내용을 불러오는 시간이나, 그냥 코드를 매번 컴파일해서 불러오는 시간의 차이가 아주 미세하다면 어떻게 될까요? 이런 것을 생각해 보신 분이 있나요? 그렇다면, 그러한 생각은 이제 그만하시기 바랍니다. 그것은 그다지 따지고 들만한 이슈가 되지 못하기 때문입니다.

일단, 그렇게 적은 코드로 구성되어지는 ASP 페이지는 거의 없기 때문이지요. 그리고, 굳이 따지고 든다면.. 아주 적은 코드를 가지는 페이지들은 ASP 페이지나 ASP.NET 페이지나  거의 비슷한 성능을 물론 낼 것이기는 합니다만, 복잡한 페이지(이게 일반적인 페이지들이죠 ^^)에서는 사실 코드를 컴파일해서 사용하는 것이 훨씬 빠를 것이라는 것은 자명합니다. ^^

그러므로, ASP.NET이 ASP보다 빠르다는 것은 맞는 말이 될 것입니다.

2. ASP.NET에서는 세션을 마음껏 사용해도 좋다???

결과부터 말씀드린다면.. 그럴리가 있겠습니까???  세션은 여전히 서버의 자원을 차지하는 친구입니다. 고로 과대한 세션의 불필요한 사용은 서버에 이로울 것이 전혀 없습니다. ASP.NET에 들어서도 세션의 사용은 충분히 고려하고 사용하는 것이 좋습니다. 해서, 가급적 쿠키를 사용하도록 장려되는 것이지요

하지만, ASP.NET 에서는 세션을 보다 효과적으로 사용할 수 있도록 여러 옵션을 주고 있습니다. 페이지 단위, 어플리케이션 단위로 세션을 Enable, Disable 할 수 있도록 옵션을 줄 수 있는 것이 바로 그것이지요.

즉, 다시 말해서, 만일 여러분이 세션을 사용할 일이 전혀 없는 페이지가 있다면 그 페이지에서는 세션을 사용하지 않겠다고 페이지 단위의 설정을 해주시는 것이 좋습니다. 다음처럼 말입니다.

<% Page EnableSessionState="false" %>

그리고, 만일 페이지에서 세션을 단지 읽어들이기 위해서만 사용한다면 마찬가지로 세션상태를  읽기전용으로 세팅하시기 바랍니다. 다음처럼요

<% Page EnableSessionState="ReadOnly" %>

이런 세팅은 서버에 이롭게 동작할 것입니다. 기억해 두세요.

그리고, ASP.NET 에서는 세션정보를 SQL 서버에다가 저장해 두고 사용할 수 있는 방법이 생겼습니다. 해서 여러대의 웹 서버를 운영하는 회사에서는 한대의 웹 서버가 뻗을 경우, 사용자들의 세션을 모두 분실하는 위험에서 벗어날 수가 있게 되었습니다.

하지만, 이렇게 SQL 서버에 세션상태정보를 저장해 둘 경우에는 상당히 큰... 서버의 부하를 가져오게 된다는 점을 기억하세요. 거의 배에 가까운 부하를 받게 됩니다. 서버가..  -_-; 해서, 이러한 세션저장방법은 반드시 웹팜(Web Farm)을 적용하실 경우에만 사용하시기를 바란다는 구쓰리 아저씨의 조언이 있었습니다.

3. 이제 모든 폼의 컨트롤들을 ASP 서버 컨트롤로 바꾸는 것이 바람직하다???

천만에요.그럴리가 있겠습니까? 물론, 서버 컨트롤로 바꾸면 프로그래밍은 매우 쉬어지기는 합니다만, 한 사람이 쉬워지면 언제나 그렇듯이 누군가는 힘들어지게 됩니다. 우리의 경우는 그게 바로 서버가 되겠죠?

구쓰리 아저씨의 말에 의하면 서버 컨트롤을 포함하는 페이지는 서버 컨트롤들을 사용하지 않는 것에 비해 많게는 30%까지의 성능 저하를 가져올 수 있다고 합니다. 그러므로, 아무 생각없이 페이지의 모든 컨트롤을 ASP 서버 컨트롤로 바꾸는 것은 조금은 바보같은 행동이라고 할 수 있을 것입니다.

그렇다면, 어떤 경우에는 서버 컨트롤이 아닌 일반 컨트롤을 사용해도 되는 것일까요? 구쓰리 아저씨는 그 부분에 대해 3개의 힌트를 주고 있습니다.

1) 컨트롤이 클라이언트측 스크립트를 실행하기 위해 필요한 경우
   : 새 창을 띄우거나,  클라이언트측 ActiveX 컨트롤 혹은 자바 애플릿과 상호 작용하는 역할이거나
     또는 DHTML을 이용해서 페이지나 alert 대화 상자에 뭔가를 출력하거나 하는 경우를 말합니다.

2) 다른 페이지나 URL을 여는 하이퍼링크일 경우는 서버 컨트롤이 필요없습니다.
    단, 하이퍼링크로 넘어오는 값이 없어서, 서버에서 어떤 처리를 할 필요가 없을 경우에 한합니다.
    만일, 하이퍼링크로 어떤 값이 서버로 전달되고, 처리가 필요하다면 이야기는 달라질 수 있슴다.

3) 서버측 코드에서 컨트롤의 속성이나 메소드, 이벤트를 접근할 필요가 없는 경우

이러한 경우에는 뭐.. 당연한 이야기이겠지만 서버 컨트롤을 사용할 이유가 전혀없을 것입니다. 구쓰리 아저씨는 참으로 당연한 말을 하시기도 하더군요 ^^

4. DataSet 을 사용해야 하나? DataReader을 사용해야 하나?

저도 이 부분은 상당히 궁금했습니다. 물론, DataReader 을 사용할 경우가 속도는 더욱 빠르겠지만, 책들의 소스를 보면 대부분이 DataSet을 사용하고 있어서요. 도대체 DataSet에게 어떤 메리트가 있길래, 소스들을 그를 고집하는가? 하고 궁금해 했지요...

구쓰리 아저씨는 다음과 같은 경우에는 DataReader 보다는 DataSet을 사용하는 것이 좋다고 하네요.

1) 데이터가 클라이언트에 대해 원격 인스턴스일 때.
  : 말이 조금은 어려운데요.. 예를 들면, 웹 서비스(Web Services)와 같은 원격 데이터를 다룰 경우에는 
    DataSet으로 그 데이터를 반환하는 것이 유리하다고 합니다.

2) 하나 이상의 레코드 집합과 그들간의 관계성 저장해야 할 때.
  : 이것은 DataSet의 장점인 부분이죠. 관계성을 저장해 두어서 계층적으로 데이터를 출력할 수 있는
    방법을 DataSet은 제공해 주니까요 ^^

하지만, 이러한 경우가 아니라면 가급적 DataReader 를 사용하는 것이 더 빠른 성능을 낼 수 있습니다.

5. System.Data.OleDb  Vs System.Data.sqlClient

MS SQL을 사용하는 경우라면 반드시 System.Data.sqlClient 네임 스페이스의 Sql 접두어 개체들을 사용해야만 합니다. 이유는 OLEDB 쪽 객체를 사용하는 것보다 SQL 접두어 개체쪽이 훨씬 빠르고 효율적이기 때문이지요. MS SQL 을 사용하면서 OLEDB 쪽 객체를 사용한다면 이것은

휴지를 가지고 코를 풀지 않고, 코를 손으로 푼 다음 휴지에 닦는 것보다 1억배는 바보스러운 행동이라는 말을 들을 수 있는 행동이 되겠습니다. 진짭니다.

6. 데이터 바인딩 기술.. 이것이 정말로 ASP때의 방법보다 좋아진 것이 맞는가?

이 부분은 눈으로 보이지 않는 부분이기에 많은 의구심이 드는 부분중에 하나입니다. 하지만, 이 부분에 대해서는 구쓰리 아저씨가 상당히 구체적인 답을 주고 있네요. 구쓰리 아저씨의 말에 의하면...

Recordset으로부터 명시적으로 HTML 테이블을 만들기 위해 ADO를 사용했던 ASP과 비교해서, ASP.NET은

1) OleDb 데이터 제공자를 이용해서 DataReader 개체로부터 데이터를 받아 데이터 바인드하면
    약 3배 정도의 속도 향상 이득을 얻을 수 있구요.

2) SQL 데이터 제공자를 이용해서 DataReader 개체로부터 데이터를 받아 데이터 바인드하면
    약 5배 까지의 속도 향상의 이득을 볼 수 있다고 합니다.

그리고, DataReader가 아닌 DataSet을 사용해야만 하는 경우라면 반드시 DataView 개체를 먼저 만들어서 바인딩하지 말구, DataSet객체의 DataMember 프로퍼티를 사용하여 테이블을 지정하라고 추천하고 있습니다. 꼭 기억하세요...

7. Early-Binding(조기 바인딩) vs Late Bound(지연 바인딩, 후기 바인딩)

ASP 에서는 지연 바인딩이 기본이었습니다. 즉, 데이터의 타입이 실행시 결정이 되어지기에 성능상의 문제가 항상 거론되었었지요. 해서 프로그래머들은 데이터 타입을 미리 지정하여 사용할 수 없는 VBScript, 그리고 ASP를 언어라고 취급하지 않기도 했습니다.

확실히 지연 바인드되는 경우는 조기 바인딩되는 경우에 비해 성능의 현저한 저하가 있으니까요.

하지만, 이제 .NET 프레임워크가 제공하는 모든 .NET 개체들은, 모든 ASP.NET 서버 컨트롤들을 포함하여 자동으로 조기 바운드되어집니다. 물론, 프로그래머에 따라 지연 바운드되게 코드를 작성할 수도 있습니다만 결코 바람직하지 않습니다.

지연 바운딩을 사용하는 COM, COM+은 사실상 ASP 페이지에서의 VBScript와 성능상의 차이가 거의 없습니다. 이것은 컴포넌트의 잇점을 전혀 사용하지 못하는 컴포넌트를 만들어 놓은 꼴이 되는 것이지요.

해서 우리가 대부분의 COM 컴포넌트를 제작할 경우는 언제나 조기 바인딩이 되도록 프로그램을 작성하였던 것이랍니다.

Dim iPos 와 같은 식이 아닌
Dim iPos as Integer 과 같은 식의 변수 타입 선언을 이제는 생활화해야 한다는 것이지요

조기 바인딩이 된 COM, COM+ 컴포넌트는 지연 바운딩되게 작성될 수 밖에 없는 ASP 페이지에 비해 성능이 약 50% 정도 높다고 합니다.

또한, 조기 바인등을 사용하는 .NET 컴포넌트들은 3배 이상 성능이 높아진다고 하네요. 이 정도로 성능이 향상된다면 조기 바인딩.. 귀찮아 할 이유가 전혀 없겠죠?

8. 새로 거듭난 Request 개체와 Response 개체의 사용법 마스터는 필수!!!

이전 제 세미나나, 여러 ASP 퍼포먼스 향상 문서를 보셨다면 자주 거론되는 이야기 중에 하나로 "Request 개체의 ServerVariables 메소드를 사용하는 것을 자제하라" 라는 말을 자주 듣거나 보았을 것입니다. 이것은 이 메소드를 통해서 환경변수값들을 읽어오는 것 자체가 서버에 부하를 주기 때문이었지요.

해서, 가급적이면 꼭 필요한 경우가 아니라면 ServerVariables 메소드를 사용하지 말라는 이야기를 자주 한 것이랍니다. 하지만, 이제 ASP.NET 에서는 이러한 부분들에 대한 걱정이 많이 해소되었습니다.

새롭게 등장한 Request 개체의 메소드들 Request.Url, Request.Referrer, Request.PhysicalPath, Request.UserAgent 등이 제공되므로, 이제 ServerVariables 메소드를 사용할 일은 많이 줄어들 것이며 좋은 성능으로 우리가 원하는 환경값들을 얻어올 수가 있게 될 것이랍니다.

또한, ASP 페이지에서 텍스트 파일을 열고 데이터를 가져오기 위해서 사용되던 방법(주로 FileSystemObject의 사용을 통해)도 Response 개체의 새로운 메소드인 Response.WriteFile 를 통해서 쉽게 파일로 부터 데이터를 읽어와 출력할 수 있게 되었습니다. 이러한 메소드외에도 지원되는 많은 새로운 메소드들을 꼭 공부할 필요가 있어보인 답니다.

몰라서 못 쓴다면 모를까.. 알았다면 꼭 공부해서 더 나은 성능을 내기위해 노력해야 하지 않겠습니까? 그게 알고 있는 사람들의 의무, 책임감입니다. 그러고보니 참으로 지식이라는 것은 무서운 것이네요.. 또한, 한없이 드넓은 것 또한 지식이 아닌가 합니다. 그리고, 그 안에 어쩌면 진실된 자유가 있는지도 모르죠...(어젯밤 술이 좀 과했나? -_-;)

안타깝게도 오늘의 강좌는 여기까지입니다.

혹시 이 강좌를 읽으신 다음, 어이없게도 "오오.. 태오가  미국가서 구쓰리라는 아저씨를 만나서 대담을 나누고 왔나보다"고 하신다면 정말 저 황당해 집니다... 절대 그거 아닙니다. 전 구쓰리가 아니라 판쓰리도 한번 못 만나봤습니다. 이 내용은 Professional ASP.NET에 나온 내용을 일부 발췌, 편집했음을 이미 말씀드렸었지요? 그 책에서 구쓰리 아저씨가 한 말들을 정리해서 알려드린 것이지... 제가 구쓰리 아저씨를 만나보지는 못했습니다. ^^ 어떻게 생겼는지도 몰르구, 실제 존재인물인지도 저는 모르고 있습니다.

더 많은 좋은 팁들을 알려드릴 수 있으면 좋았겠지만, 저도 아직 공부를 하고 있는 중이라 그다지 많은 지식이 있지는 않네요... 더 나은 정보를 같이 공유할 수 있었으면 합니다. 그리고, 강좌나 좋은 정보를 주실 분들은 메일로 글을 보내주시거나, Knowhow 게시판에 올려주셔도 좋아요...

좋은 글들은 꼭.. 게시자님을 달덩이만하게 크게 적어서.. 강좌로 멋지게 올려드리겠습니다.

ps : 드뎌.. Professional ASP.NET 책에 대한 감수가 끝났습니다. 조만간 번역서가 나오겠네요 ^^

언제나 좋은 하루 되세요. 버지니아에서 귀국을 앞둔 태오였습니다.

Back