'Performance'에 해당되는 글 4건

  1. 2009.11.20 WCF 성능 향상 팁 (2)
  2. 2009.03.11 TFS 성능 향상 팁
  3. 2009.03.02 ASP.NET 서버 모델의 성능에 대한 고찰 [1] (2)
  4. 2009.03.02 ASP.NET 서버 모델의 성능에 대한 고찰 [2] (2)

WCF 성능 향상 팁

.NET/WCF 2009.11.20 08:30 |

WCF Performance Optimization Tips

.NET Framework 3.0 부터는 Enterprise Services 를 잘 구현할 수 있는 WCF(Windows Communication Foundation) 라이브러리를 제공합니다. 특히 최근 .NET Framework 3.5 SP1 에서는 서비스의 통합 뿐만 아니라 Enterprise Services Bus 를 구현하여 최상의 SOA(Services Oriented Architecture) 를 구현할 수 있는 프레임워크입니다.

그렇기 때문에 기존에 .NET 이 제공하던 XML Web Services 와 WCF 를 동일 선상에서 비교하거나 생각하는 것은 굉장히 위험할 수 있습니다. 가끔 BasicHttpBinding 이나 WSHttpBinding 등을 사용하여 IIS 에 호스팅 할 경우 성능에 대해 고민을 해 보신 분들도 계실 겁니다. 예전에 XML Web Service 로 잘 수행했던 프로젝트를 WCF 를 사용하여 만들었을 경우 서버가 자주 뻗는 경우도 있었을 것입니다.

   

Web Based Performance Optimization Tips

즉, 일반적으로 IIS 에 호스팅되는 Web Application 이나 XML Web Service 의 성능을 향상시키기 위해서는 Thread 나 Connection 을 늘려주는 방법으로 성능 튜닝을 할 수 있었습니다. ( default 는 .NET Framework 1.1 기준 )

  • Max Connection - default 2
  • Max IO Threads - default 20
  • Max Worker Threads - default 20
  • Min Free Threads - default 8
  • Min Local Request Free Threads - default 4

잘 모르시겠다구요~? MSDN 에 보시면 나옵니다. 각각 항목은 단지 권장 값이고 튜닝을 하기 위해서는 "추천 수치 * CPU 개수" 가 바로 최상의 성능을 낼 수 있는 Threads 나 Connection 이 됩니다. 사실 기본 값으로 서버 성능을 최상으로 발휘하기에는 무리가 있습니다.

   

WCF Based Performance Optimization Tips

하지만 WCF 에서는 이러한 성능 튜닝 방법은 전혀 다른 차원의 이야기 입니다. 왜냐하면 Web Application 이나 XML Web Service 와 달리 WCF 는 ASP.NET Pipeline(파이프라인) 을 거치지 않기 때문입니다.

Microsoft 의 WCF 개발 팀은 이런 부분에서 참 아이러니한 이야기를 합니다.

"DDos 공격을 방지하기 위함이다!" 라고...

틀린 이야기는 아니죠. ASP.NET HttpRuntime 환경을 그대로 WCF 환경으로 적용하기에는 WCF 프레임워크의 아키텍처와는 너무나 비호환적이기 때문인 것 같습니다. 다시 바꾸어 말하면, WCF 는 내부적인 ASP.NET 파이프라인을 타지 않습니다. 그렇기 때문에 기본 옵션의 Session 이나 Call 옵션으로 Service Host 가 락(Lock) 에 걸리는 상황이 옵니다.

MaxConcurrentSessions 는 Default 가 10 이므로, Closing 되지 않은 클라이언트의 세션이 이를 초과하게 되면 Lock 이 걸리게 됩니다. 아래는 간단한 예제이지만, Closing 을 잘해주더라도 Multi Thread 로 테스트를 해 보시면 금방 Lock 이 걸리게 할 수 도 있답니다.

namespace WcfService1Console

{

class Program

{

static void Main(string[] args)

{

for (int i = 0; i < 20; i++)

{

ServiceReference1.Service1Client client = new WcfService1Console.ServiceReference1.Service1Client();

Console.WriteLine(i + " " + client.GetData(3));

}

}

}

}

 

WCF 서비스는 기본값이 Max Session 이 10개에 도달하면 클라이언트의 연결을 거부합니다. Session Lock 이 걸리고 이전의 세션이 끝나야 다른 Session 의 연결을 수락하게 됩니다. WCF Session 은 HTTP Session 과 다르며, 클라이언트와 서버의 인스턴트를 연결하는 인증 매커니즘과 비슷합니다. WCF 의 SessionMode 를 NotAllowed 로 동작하도록 세션 사용을 하지 않도록 설정해도 되지만, 이러한 방법으로는 클라이언트와 서버간의 연결을 보장하지 않을 뿐이지, 실제로 세션이 연결이 되지 않는 것은 아니기 때문에, 퍼포먼스 향상을 위한 좋은 방법이라고 볼 수는 없습니다.

그리하여 WCF 의 퍼포먼스를 향상시키기 위해서는 ASP.NET 과는 별도의 Throttling 환경의 조정이 필요합니다.

<behaviors>

<serviceBehaviors>

<behavior name="WcfWsHttpSvc.Service1Behavior">

<!-- 메타데이터 정보를 공개하지 않으려면 배포하기 전에 아래의 값을 false로 설정하고 위의 메타데이터 끝점을 제거하십시오. -->

<serviceMetadata httpGetEnabled="true"/>

<serviceThrottling maxConcurrentCalls="50"

maxConcurrentSessions="50"

maxConcurrentInstances="100"/>

<!-- 디버깅 목적으로 오류에서 예외 정보를 받으려면 아래의 값을 true로 설정하십시오. 예외 정보를 공개하지 않으려면 배포하기 전에 false로 설정하십시오. -->

<serviceDebug includeExceptionDetailInFaults="false"/>

</behavior>

</serviceBehaviors>

</behaviors>

그리고 다시 테스트를 해보시면 Lock 이 걸리지 않는 것을 확인할 수 있습니다.

이 옵션은 아래와 같은 튜닝하는 것이 좋다고 가이드 합니다. 단지 권장 값이기 때문에 더 높은 값을 주어도 상관은 없습니다. 특히 MaxConcurrentInstances 는 Int32.MaxValue 값을 주셔도 됩니다. WCF 어플리케이션 서버의 배치와 Load-Balancing 을 고려하여 적절하게 주시면 됩니다.

  

기본 값

권장 값

예 (4-Core)

MaxConcurrentSessions

10

기본 값 * CPUs

40

MaxConcurrentCalls

16

기본 값 * CPUs

64

MaxConcurrentInstances

26

권장 값의 MaxConcurrentSessions + MaxConcurrentCalls

104

   

'.NET > WCF' 카테고리의 다른 글

WCF 성능 향상 팁  (2) 2009.11.20
WCF 의 불친절한 ProtocolException  (0) 2009.03.07
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. Ryunad 2011.01.29 12:07 Address Modify/Delete Reply

    정말 좋은 것을 배워갑니다.
    감사합니다 ^^

  2. 신동열 2014.08.21 10:13 Address Modify/Delete Reply

    안그래도 이문제로 고민하고 있었는데 좋은글 보고 배워갑니다.

TFS 의 성능 향상 팁입니다.
 
저도 집에 금쪽 같은 Quad Core 에 빵빵한 메모리로 무장한 데스크탑이 있지만, 가상 머신에 OS 를 3개 띄우니 체감적으로 버벅 되니 데스크탑에 손이 잘 가지 않더군요. (혼자 쓰면서 별짓 다하죠. AD 까지 올려놨으니 -_-;)
 
아래의 주소에서 TFS 의 성능 향상에 관한 팁이 좀 도움이 될까 하네요.
다른건 몰라도 서버단에서 ASP.NET 의 캐싱 메모리를 올리는 방법이 젤 손쉽고 체감적이지 않을까 합니다.
 
TFS Performance Tips & Tricks
 


Posted by 땡초 POWERUMC

댓글을 달아 주세요



들어가기 앞서…
 
ASP.NET 을 책을 통해 입문하게 되면, 처음 접하게 되는 것이 바로 서버 컨트롤 입니다. 그리고 MSDN 에서도 서버 컨트롤을 남용하면 웹 사이트의 성능을 저하시킬 수 있다고 말합니다. 이러한 서버 컨트롤을 사용하여 개발하는 방법을 ASP.NET 의 서버 모델이라고 합니다. ASP.NET 의 서버 모델은 웹 개발에 있어서 정말 편리하고 복잡한 처리를 단순화 시킵니다.
 
우리가 ASP.NET 을 처음 입문하면 포스트백(Postback) 이라는 용어를 듣습니다. 왜 기존의 서밋(Submit) 이라는 용어를 쓰지 않고, 독자적인 포스트 백(Postback) 이라는 용어를 사용할까요? 궁금하지 않으십니까?
 
ASP.NET 개발자들은 왜 서버 컨트롤이 웹 사이트의 성능을 저하시키는지 잘 알고 있는 사람은 드문 것 같습니다. ASP.NET 의 서버 컨트롤을 사용하는 서버 모델은 ASP.NET 의 성능을 저하시킵니다. 왜일까요?

 
ASP.NET 서버 모델이란?
ASP.NET 의 form 에 runat=”server” 를 사용하는 단일 Form 개발 방법입니다. 단일 Form 개발 방법은 서버 컨트롤을 사용할 수 있게 하며, 이러한 컨트롤에게 자동적으로 상태 유지 기능을 제공합니다.
 
HTML Form 모델이란?
ASP.NET, ASP, PHP, JSP 과 같이 다중 Form 을 이용하여 개발하는 기본적인 웹 개발 방법입니다.
 
MS MVC Framework != HTML Form 모델
HTML Form 개발 방법을 MS MVC Framework 과 동일시 하는 경우가 있는데, HTML Form 과 MS MVC Framework( 또는 MVC) 는 전혀 관련이 없습니다. 서버 모델에서도 MS MVC Framework (또는 MVC) 를 적용할 수 있으며, 윈폼 등 다양하게 적용 가능 합니다.
 
 
서버 컨트롤이 왜 느리죠?
 
서버 컨트롤은 ASP.NET 의 이벤트 기반의 프로그래밍을 가능하도록 하기 위해 독자적인 이벤트를 제공하고, 별도의 랜더(Render) 프로세스를 가집니다. 즉, 서버 컨트롤이 화면에 표시되기 위해 Render 메서드를 재정의(Override) 하여, 화면에 표시되는 HTML 을 생성합니다. 단순한 Label 컨트롤 마져 HTML Span 으로 랜더링되고, 많이 사용하는 그리드 관련 컨트롤은 table 태그를 사용하여 랜더링 합니다.
단순히 HTML Form 모델이라면 바로 스트림에 쓴 후 클라이언트에게 전달할 수 있지만, 서버 컨트롤은 이 과정에서 개별 컨트롤을 랜더링을 하게 됩니다.
 

[그림1] 서버 모델의 랜더링 과정
 
이 랜더링 하는 과정이 새발의 피보다 적은 시간이지만 웹 서버는 결코 혼자 쓰는 서버가 아니라는 점을 명심하세요.
 
이것은 서버 컨트롤을 사용하는 서버 모델의 근본적인 원인이 되어 추후에도 지속적으로 문제가 발생하게 됩니다.
 
 
서버 컨트롤은 적절하게 사용하면 되지 않나요?
 
ASP.NET 서버 모델에서 사용하는 환경에서 적절하게 사용한다는 판단은 팀 개발 환경에서 무척이나 주관적입니다. 이러한 판단은 개발자 주관에 맡길 수 밖에 없으며, 반드시 판단의 기준을 지키리라는 보장을 할 수 없습니다. 더 중요한 것은 적절하게 사용하는게 중요한 것이 아닙니다.
 
서버 컨트롤은 화면에서 사용한 개수도 중요하지만, 서버 컨트롤이 갖는 데이터가 어떤 것인지도 중요합니다. 단 하나의 서버 컨트롤만 사용하더라도 많은 양의 뷰 스테이트(ViewState) 를 갖게 된다면 더 이상 서버 컨트롤의 개수는 중요하지 않습니다.
 
 
뷰 스테이트(ViewState) 의 양이 많으면 왜 느리죠?
 
ASP.NET 의 서버 컨트롤은 상태 유지를 위해 ViewState 를 생성합니다. 뷰 스테이트는 HTML 로 랜더링될 때 히든 필드(Hidden Field) 에 그 값을 저장하고 클라이언트로 보냅니다.
서버 컨트롤을 랜더링 하고 또 상태 유지를 위해 추가적인 개별 컨트롤에 대해 객체 직렬화 과정을 거치게 됩니다.
 

[그림2] 상태 유지를 위한 뷰 스테이트(ViewState)
 
이러한 직렬화 과정이 소량의 데이터일 때 빠르다고 하더라도 데이터의 종류와 양에 따라 수십에서 수백 밀리 세컨드(Milliseconds) 가 느려집니다. 그리고 다시 한번 강조하지만 웹 서버는 혼자 쓰는 서버가 아니라는 점을 생각하면 이 과정이 누적되면 결코 짧은 시간이라고 장담할 수 없습니다.
 
 
컨트롤의 EnabledViewState 를 사용하지 않으면 되지 않나요?
 
특히 그리드 관련 컨트롤은 엄청난 양의 뷰 스테이트(ViewState) 를 생성합니다. 그리고 그리드안에 하위 컨트롤이 추가적으로 들어가있다면 거의 쥐약이나 다름없습니다. 그러므로 컨트롤에 대해 EnabledViewState 를 False 로 설정함으로써 ViewState 을 생성하지 않도록 지정할 수 있습니다.
 
하지만 이것은 근본적인 해결책이 될 수 없습니다. 그리드 컨트롤이 생성하는(기타 서버 컨트롤) HTML 은 컨트롤의 Render 메서드를 통해 HTML 코드를 생성한다고 하였습니다. 만약 tr, td 태그를 한 줄에 배치함으로써 네트워크 트래픽을 최소화 할 수 있지만 서버 컨트롤을 사용하면 이러한 HTML 코드를 직접적으로 제어할 수 없게 됩니다.
 

[그림3] 서버 컨트롤의 랜더링 코드를 제어할 수 없음
 
그리고 EnabledViewState 를 수동적으로 임의로 수정하게 되면 개발의 복잡성이 증가하고 유지 보수성이 저하됩니다. EnabledViewState 속성을 False 로 설정하면 더 이상 상태 유지 기능을 사용할 수 없기 때문에, 코드 비하인드의 로직 마저 수정되어야 합니다. 이러한 문제로 지속적인 성능 개선을 위해 여러 컨트롤에 거쳐 EnabledViewState 를 수정하게 된다면 개발의 복잡성과 유지 보수성 저하와 더불어 추가적인 리소스가 소요됩니다.
 
 
그럼 생산성을 포기하나요?
 
ASP.NET 은 이러한 상태 유지를 자동으로 처리해 줍니다. 그리고 서버 컨트롤의 이벤트 등을 사용하여 보다 빠른 생산성을 보장할 수 있다고 합니다.
 
정말일까요? 단지 이러한 이유 때문에 생산성이 향상됨을 느끼시나요?
 
서버 컨트롤의 그리드를 예로 들게 되면
 
1.     추가적인 디자인 작업이 소요됩니다.
디자이너에 의해 작업된 디자인 HTML 은 다시 한번 서버 컨트롤로 변환되어야 합니다. 차라리 디자이너에게 ASP.NET 의 서버 컨트롤 사용 방법을 알려주는 것이 편할 때도 있고, 실제로 이렇게 하기도 합니다. 하지만 디자이너에게 서버 컨트롤을 강요할 의무가 없으며, 디자이너가 서버 컨트롤을 사용하게 되면 디자이너의 원하는 디자인 작업이 힘들어 집니다.
 
특히 그리드 관련 컨트롤은 디자인된 HTML 을 그리드 관련 컨트롤로 옮기기 위해 더 머리가 아픕니다. 그리드 컨트롤이 개별적으로 랜더링 하기 때문에 1px 이 오차 나거나 디자이너가 원하는 디자인이 아닌 경우가 허다합니다.
 
2.     빌드 하기 전에 오류를 알아낼 수 없습니다.
랜더링 되는 그리드의 결과물이 조건에 따라 변경되어야 한다면, 대부분 그리드의 이벤트를 연결하여 작업합니다. 그리드에 랜더링 되는 상태 데이터를 가져오기 위해 추가적인 코드가 필요합니다.
그리고 이러한 방법은 코드를 다시 빌드하기 전에는 오류의 원인을 알 수 없기 때문에 추가적인 빌드 작업이 필요합니다.
이러한 빌드 작업은 웹 프로젝트의 어셈블리가 변경이 되며 IIS 를 리스타트 하도록 하여 웹 프로젝트 어셈블리가 다시 메모리에 적재됩니다. In-proc 세션을 사용하는 경우라면 세션마저 끊겨져 버립니다.
 
ASP.NET 의 서버 컨트롤 생산성 향상은 단편적이고 제한적인 경우에만 체감적으로 느낄 수 있으며, 상태 유지 또한 HTML Form 에서 그리 복잡한 작업은 아닙니다.
 
아래의 링크에 HTML Form 모델에서의 상태 관리 방법에 대한 글을 보시기 바랍니다.
 
 
그럼 성능 개선 방법은 없나요?
 
있습니다. 웹 사이트 최적화 기법을 통해 사용자의 최종 응답 속도를 향상시킬 수 있습니다. 만약 현재 운영하는 사이트의 성능이 문제가 된다면 다양한 튜닝 포인트를 통해 사용자의 응답 속도를 향상시킬 수 있습니다. 실제 이러한 개선 방안은 많은 서비스 또는 포털이나 도메인(Domain) 에서도 즐겨 사용하는 방법입니다.
 
하지만 이러한 방법은 서버 모델을 최적화하는 관점으로서 HTML Form 모델과 다시 비교하게 되면 더 나은 성능을 보장할 수 없고 근본적인 ASP.NET 의 성능과는 무관합니다.
 

[그림4] ASP.NET 서버 모델의 최적화 한계
 
이러한 최적화 기법을 통해 기존의 성능을 향상시킬 수 있지만, ASP.NET 의 성능 문제는 여전히 해결할 수 없습니다.
 
 
응답 속도가 향상 되었는데 또 뭐가 문제죠?
 
ASP.NET 의 서버 컨트롤은 사용의 편의성과 함께 자동적으로 상태 유지할 수 있는 크나큰 장점이 있습니다. 이러한 문제는 결국 뷰 스테이트(ViewState) 문제이고, 최적화 기법을 통해 기존 성능을 향상할 수 있습니다.
 
하지만 ASP.NET 의 상태 유지는 굉장히 위험한 요소를 가지고 있습니다. 이것은 ASP.NET 의 서버 모델은 단일 Form 밖에 사용할 수 없기 때문에 나타나는 현상입니다. 즉, 포스트 백(Postback) 이 원래 상태로 돌린다는 의미로써 이런 포스트 백(Postback) 처리를 하기 위해 상상할 수 없는 만행을 ASP.NET 이 저지르고 있습니다. 

ASP.NET 의 서버 모델과 HTML Form 모델의 랜더링된 HTML 코드는 상이하게 다릅니다.
 

[그림5] 서버 모델과 HTML Form 모델의 HTML 코드 비교
 
 
자! 뭐가 문제인 것 같나요?
 
서버 모델은 포스트 백(Postback)이 발생할 때마다 form 내에 존재하는 모든 요소를 다시 서버로 전송합니다. 즉, ViewState 가 전송되고 다양한 HTML 태그의 name 속성이 설정된 모든 요소들이 서버로 전송됩니다. ( 대부분의 서버 컨트롤의 명령이 처리되는 컨트롤은 name 속성이 포함됩니다 )
 
즉, 화면의 변경 전의 상태를 ViewState 에 기록하고, 변경 내용을 처리하기 위해 name 속성이 들어간 요소를 전송합니다. 즉, 변경 전, 변경 후 처리를 위해 엄청난 양의 데이터를 서버로 POST 로 전송합니다. 그리고 이러한 ViewState 를 다시 객체로 변경하기 위해 역직렬화 과정을 거치게 됩니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 고래상어 2016.05.27 09:51 Address Modify/Delete Reply

    우연히 보게 되었고 참으로 흥미롭게 읽었습니다.^^
    ASP.NET 개발자인데 부정적인 내용이 많아서 나름의 의견을 적어보았습니다.

    ASP.NET의 패러다임은 웹개발을 CS처럼 하는 것입니다.
    이 편리함이라는 장점을 위해 서버 및 네트웍 자원을 더 많이 사용해야 하는 단점이 있습니다.
    이는 아담의 갈비뼈로 이브를 얻은 것에 비유하고 싶습니다.

    만일 성능이나 트래픽 때문에 ASP.NET이 문제라면 그 기능을 안쓸 수도 있습니다.
    서버태그와 뷰스테이트를 배제하고 기존 ASP나 java servlet과 유사한 구조로 개발하는 것이죠.
    물론 이렇게 해도 java servlet이 성능면에서 더 좋긴 합니다만 넘어가도 될 수준일 듯 하네요.

    결론적으로 ASP.NET 구조는 실패작이 아니라고 말하고 싶습니다.
    편의성과 신속한 개발을 원한다면 ASP.NET을, 성능이 중요한 대규모 사이트 개발이라면 java를 선택하면 것 같습니다.

  2. Pluginn 2018.01.11 16:28 Address Modify/Delete Reply

    잘읽었습니다. 저는 오히려 공감합니다.

    닷넷이 첨나오고 열정적을 공부했던사람으로서,,,

    말씀대로 서버모델 HTML모델, viewstate 등 사용가능하며, 선택 또한 가능합니다..

    문제는.... MS 가 첨부터 서버모델 방식을 너무 지향했다는거죠,
    기존에 HTML 모델 방식보다 닷넷의 서버모델을 따라라...

    HTML 모델방식에 익숙한 개발자로써는, 새로울수도있지만 , 상당히 불편했쬬,,

    또 한 윗글대로 좋을께 하나도 없습니다.


    서버모델방식이, 개발 생산성에서.. 빠르고 , 쉽고 뭐든 좋타고 떠들던 MS 결국 어떻게 되었나요?

    아니다 싶으니, 그냥 급하게 빨리만들어야하는,, 유저 접근 커넥션이 제한적인,,,,
    그래도 백단 만들기에는 편하다,,
    백단을 모두 서버 컨트롤로 만들기 시작했죠,, 왜? 그냥 서버 컨트롤 넣고 더블클릭해서,,,

    코드 넣으면되니까요.. 그러다보니 디테일하게 화면을 구성하기가 복잡해짐,,
    디테일하게 지원하기위해서는 서버 컨트롤에 무한한 속성을들 버전 올리때마다 MS 는 추가해야겟죠

    아니면 서버컨트롤 + 잡기술로 접목 = 결국 코딩이 지저분해짐
    (이는 웹이 CS 프로그램 처럼 서버 단 기술로만 이루어진게 아니기때문이죠_

    비하인드에서 자바스트립을 출력하기위해 서버단 스파게트 코드? 를 만들게 되고,,,
    클라이언트 단에서는. (물론 화면만 깨지지 않으면 되긴하지만) 소스 보기하면 개판이고,,,

    서버단에서 SCRITP ,CSS 지원하려니 MS도 머리터졌겟죠
    지금 결국 각 파트별로 전문적인 프레임워크(정확히는 프레임워크가 아니죠) 장착해서 쓰는듯 하네요

    MS 는 뭐든, 쉽고 ,편하고 , 좋게 만들려고합니다..
    (나쁘게 말하면 본인들이 만든 테두리안에서 편리함을 맛보면 나갈수 없게..)

    기존에 CS 들은가능했으리라 봅니다,
    하지만 웹은 다르죠 엄청 나게 바뀌는 패러다임들을... 따라가려면 버전업을 1년에 2번은 해야할듯,,,

    업그레이드 하면,, 하위호환은 안되며,
    Jquery 를 능가하는 script 프레임워크 node.js 능가하는 서버스크립 ajax 도 잡아야하고
    flash도 다 넣어야하고,,앱 개발도 가능하고,


    MS 서술대로 쓰면 asp.net 은 실패가 맞고요,,

    .net 에.. 나름 본인이 필요한거 빼고 넣고 해서. 쓰면.. 성공이 맞구요,,


 
서버와 클라이언트는 어떤 과정이 반복되나요?
 
ASP.NET 의 서버 모델은 아래의 그럼처럼 반복적인 추가 작업을 하게 됩니다.

[그림6] 서버 모델 프로세스
 
HTML Form 모델은 여러 개의 Form 의 구간을 두어 단지 필요한 데이터만 서버로 전송합니다.
아래 그림처럼 말이죠.

[그림7] HTML Form 모델 프로세스
 
이러한 뷰 스테이트(ViewState) 는 HTTP 파일 업로드가 되듯이 POST 로 서버로 업로드 됩니다. 즉 이 뷰 스테이트(ViewState) 양이 커지게 되면 web.config 에서 요청 데이터 사이즈의 크기를 조절해 주어야 하는 상황까지 벌어집니다.
 
<httpRuntime maxRequestLength="업로드 사이즈" />
 
그리고 우리나라의 인터넷 인프라가 아무리 발달하였다고 하여도 그것은 전적으로 다운로드 속도입니다. 대부분의 경우는 업로드 속도는 다운로드 속도에 못 미치며, 다운로드 속도의 절반도 못 미치는 경우가 대부분입니다.
 
그렇다고 업로드 속도가 해결된다고 모든 것이 해결되는 것은 아닙니다. 서버의 자원은 한정적입니다. 서버의 직/역직렬화 과정 등은 전송된 데이터의 양 만큼의 메모리 자원을 요구하게 됩니다. 즉, 알게 모르게 웹 서버는 스트레스를 받고 있으며 추가적인 코스트(Cost) 가 발생하기도 합니다.
 
이러한 면에서 HTML Form 모델은 기존 ASP.NET 서버 모델에 비해 하나의 서버에서 수십에서 수백 명의 사용자의 접속을 더 허용할 수 있습니다.
 
 
그럼 ASP 와 다를 바가 없는데요? 차라리 ASP 가 빠르겠네요.
 
ASP 와 ASP.NET 은 내부적으로 전혀 다른 구조입니다. 그리고 ASP.NET 은 ASP 의 인터프리터 방식과 비교할 때 더 나은 성능을 낼 수 있습니다.
 
ASP.NET 은 .NET Framework 과 C#(VB.NET 등) 으로 언어적 측면과 프레임워크가 제공하는 기능으로 생산성의 향상을 기대할 수 있습니다. 그리고 ASP.NET 파이프라인(Pipeline) 의 향상된 아키텍처와 보안적 측면에서 기존 ASP 에 비해 향상된 보안 기능을 제공합니다. 그리고 컴파일 언어 측면에서 성능 향상과 한번 컴파일된 어셈블리는 어셈블리 캐시에 적재되어 인터프리터 언어인 ASP, PHP 등에 비해 월등히 빠른 성능을 기대할 수 있습니다.
 

[그림8] ASP.NET 실행 모델
 
즉, ASP.NET 이 제공하는 인프라는 기존 ASP 등과 비교할 때 보다 향상된 아키텍처와 언어적 측면, 보안적 측면, 성능적 측면 등의 이점을 누릴 수 있습니다.
 
ASP.NET 의 서버 컨트롤을 사용하는 서버 모델은 변칙적인 웹 개발 방법에 불과합니다. 즉, 단일 Form 개발 방법을 통해 서버 컨트롤과 상태 유지의 장점 등으로 개발 생산성의 관점에서 시작되었습니다. ASP.NET 서버 모델의 단일 Form 방식은 성능 자체를 최적화할 방법이 없습니다.
 
즉, ASP.NET 을 사용하는 서버 모델은 HTML Form 모델의 성능을 따라갈 수 없습니다. 서버 컨트롤을 남용하는 특정 사람들에 의해 ASP.NET 이 느리다는 편견이 확산된 것이 안타까울 뿐입니다.
 
 
그럼 서버 컨트롤을 쓰지 않는 것이 결론인가요?
 
반드시 그렇게 하지 않아도 됩니다. ASP.NET 의 서버 모델은 HTML Form 방식의 개발 방법보다 여러 가지 처리에 대한 고민을 보다 단순화 할 수 있습니다. 그렇기 때문에 ASP.NET 을 입문하는데 ASP 에 비해 오히려 난이도가 쉽다고 생각합니다. 그리고 다양한 고객 또는 사용자의 요구 사항을 충족하기 위해서는 3-party 제품을 통해 복잡하고 많은 리소스가 투입되는 작업을 서버 컨트롤 하나로 단순화 시킬 수 있습니다.
 
가끔 이런 사람들을 봅니다.
 
서버 컨트롤 사용 못하게 하는 프로젝트도 있나요? 차라리 ASP 로 개발하자고 하세요”
 
서버 컨트롤은 ASP.NET 의 서버 모델이 제공하는 단지 보너스 정도라고 생각합니다. 서버 컨트롤이 ASP.NET 의 전부이며, 서버 컨트롤을 사용하지 않는 것은 ASP.NET 개발이 아니라고 단언하면 안됩니다. 말했듯이 ASP.NET 의 서버 모델이 기본적인 웹 개발과 비교하면 변칙적인 방법에 불과합니다.
 
ASP.NET 을 서버 모델과 HTML Form 모델로 개발하였을 때, 절대 ASP.NET 서버 모델의 개발 방법은 HTML Form 모델로 개발하는 성능의 꽁무니도 못 따라옵니다. 혹시 이견이 있다면 실무 프로젝트에서 같은 사이트를 양측 모두 적용해 보셨나요? 요즘 이런 개그가 있죠. “안 해보셨으면 말을 하지 마세요!”
 
개발하는 프로젝트의 성격과 사용자는 유저에 따라 두 개발 방식의 적절한 선택이 필요하고 두 모델에 대한 이해가 필요합니다. 그리고 ASP.NET 을 바라보는 올바른 안목이 필요합니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 천이백 2015.01.28 19:11 Address Modify/Delete Reply

    구글링하다가 우연히 들어오게 되어서 글을 남깁니다. 이 글을 보고 답변을 다실 지는 모르겠지만
    ASP.NET의 서버 모델은 변칙적인 방법에 불과하다는 생각이 지금도 유효하신 건가요?
    ASP.NET에 대한 평가를 하려면 PHP나 JSP 또는 ASP와 비교를 해야지 html 과 비교하는 것 자체가 제가 보기엔 어불성설인 것 같네요.
    http://www.wrensoft.com/zoom/benchmarks.html
    위의 벤치마크에서도 나와 있지만 asp.net은 성능상에도 다른 서버 프로그래밍과 비교해서 뒤처지지 않는 것으로 나오네요. MS의 많은 천재 개발자들이 편법을 이용해서 프로그래밍 언어를 개발할 리도 없다고 생각하고요.
    그리고 또 한가지 국내 최대 쇼핑몰 중의 하나인 지마켓이나 옥션이 모두 asp.net 기반으로 돌아가는 쇼핑몰입니다. 이런 대형 쇼핑몰에서 아무런 문제없이 사용하고 있는 asp.net이 서버 측 성능상의 문제로 트래픽 때문에 서버가 중지된 적이 있다는 소리는 아직 한번도 안들어 본 것 같습니다만....
    웹 개발을 하는 사람이 옥션이나 지마켓보다 훨씬 더 큰 대규모의 사이트를 개발하고 있다면 모를까,단지 서버측의 부하가 좀 생긴다고 해서 여러 장점을 가진 서버 기술을 사용하지 못할 이유는 전혀 없는 것 같습니다.
    그리고 데이터베이스와 연동하는 서버측 기술도 MS에서 제공하는 것이 데이터가 계속 주고 받아야 하는 서버에 상당히 부담을 주는 연동 기술도 있지만 dataset 과 같이 서버의 자원을 가져온 다음에 연결을 끊어 주는 다양한 기술들이 있는데 이런 것만 적절히 사용해도 현재의 컴퓨터 환경에서는 그리 큰 문제가 될 것이라고는 전혀 생각이 안 듭니다.

    • 땡초 POWERUMC 2015.01.29 12:23 신고 Address Modify/Delete

      내용을 모두 이해하시지 못하신 것 같아 재차 설명을 드립니다.

      네트워크 오버헤드를 설명하기 위해 ASP.NET 이 랜더링하는 HTML 의 양을 설명한 것입니다.

      그리고 ASP.NET 을 사용하는 것은 성능 문제가 아니라, ASP.NET + 서버 컨트롤을 사용한 경우 성능 문제를 야기한다는 것입니다.
      이유는 물론 글에 설명되어 있습니다.

      그리고 옥션과 지마켓이 ASP.NET 웹 개발 프레임워크를 쓰는 것이지, ASP.NET + 서버컨트롤 방식을 사용하지는 않습니다.
      ASP.NET + 웹폼 방식으로 개발하면 기대하는 성능을 얻을 수 있습니다.
      최근 유행하는 ASP.NET MVC 도 웹폼 방식이고요.