ASP.Net: Config파일에 debug="true"를 지정하면...

  • Article

ASP.Net을 이용해서 많은 개발자 분들이 멋진응용프로그램 개발을 완료하고 테스트를 거쳐서 서비스를 시작하게 됩니다.

그중 일부 몇몇 사이트는 이후 얼마 지나지 않아 사용자가 늘면서 서비스 속도가 떨어지고 메모리 사용량이 늘어나더니 결국 OutOfMemoryException이 발생하거나 서비스 속도가 현저하게 떨어지는 등 많은 문제가 발생하게 되는 경우가 생기게 됩니다.

이때 가장 먼저 ASP.Net Config 파일에서 <compilation debug=”true”/> 가 있는지 확인해 보시기 바랍니다. 위와 같은 문제가 발생하지 않으려면 (물론 100% 이 설정에 의해서 발생하는 것은 아닙니다만) 반드시 "false"로 설정해 주셔야 합니다.

 

원래 ASP.Net 응용프로그램의 디버깅을 도와주기 위해서 사용되는 이플래그가 설정 되면 다음과 같은 부분에 영향을 미칩니다.

1. ASP.Net Timeout : 디버깅중 소스라인을 따라가면서 변수 값을 추적하는데 웹페이지가 타임아웃이 된다면 디버깅이 불가능 하겠지요. 이를 위해서 debug="true"로 설정이 되면 타임아웃 설정이 작동을 하지 않습니다.

하지만 이 설정이 실제 서비스 중인 사이트에 설정이 된다면 서비스 중 발생하는 문제가 있더라도 서비스 지연 현상만 관측이 될 수 있습니다. 문제의 원인 분석을 어렵게만드는 원인이 될 수 있겠습니다.

2. Batch Compilation : debug="true" 설정이 된 상태에서 ASP.Net 페이지에 대한 요청이 일어나게 되면 Bactch Compile이 일어나지 않습니다.

Batch Compile이 enable 되면 (즉, debug="false"이면) ASP.Net은 웹 페이지가 위치한 응용프로그램 폴더내의 대부분의 ASPX, ASCX등을 Bacth로 컴파일하고 하나의 Assembly DLL을 생성 한 후 Temporary ASP.Net Files 폴더에 복사를 하게 됩니다. 하지만, Batch Compile이 disable 되면 각각의 페이지 요청에 대해서 별도의 Assembly DLL을 생성하게 됩니다.

언듯 생각하기에 무슨 문제가 없어보입니다만 실제 이들 Assembly들이 Process상에 로드되게 되면 이를 관리하기 위한 (특히, 디버깅을 위한) 부수적인 정보들이 같이 생성되게 됩니다. 여기에 많이 페이지 숫자가 많은 응용프로그램의 경우는 이들 Assembly로딩에 의해서 Virtual Memory가 조각화(Fragmentation) 되는문제가 생기게 됩니다. 이는 결국 OutOfMemryException이라는 치명적인 결론에 이르게 됩니다.

3. Code Optimization : 이 문제는 .Net Framework 이전의 (Pascal, Fortran이나 C/C++와 같은) Unmanaged Language에서도 중요하게 생각되던 부분 입니다. 결국 생성되는 코드는 성능을 위해서 최적화 된 코드가 아니니 실제 작동시 충분한 속도를 낼 수 없다는 것이지요.

 

Code Optimization은 포기 하더라도 실제 작동 중인 시스템의 성능이나 안정성(응용프로그램이 충분히 안정적이라는 가정하에)을 위해서 시스템 레벨에서 관련 설정을 debug="false"와 같은 효력이 나타나도록 변경할 수 있는 방법이 ASP.Net 2.0에서는 제공 되고 있습니다. Machine.config에 아래 내용을 추가하시면 됩니다. 

<configuration>

    <system.web>

          <deployment retail=”true”/>

    </system.web>

</configuration>

 

위의 내용을 아래의 블로그 기사들의 내용을 번역(내지는 오역?)한 것 입니다. 좀 더 정확하고 자세한 내용을 원하시면 아래의 블로그 기사를 참고하세요.

 

 ASP.NET Memory: If your application is in production… then why is debug=true

 https://blogs.msdn.com/tess/archive/2006/04/13/575364.aspx

Don’t run production ASP.NET Applications with debug=”true” enabled

https://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx