ASP.net – Debug set to True
I’m guesstimating that 25% of asp.net hangs and performance issues are either solved by (or at least minimized) by setting debug to false.
This web page contains links and excerpts that explain the various problems that may result when debug=“true” (versus debug=“false”) in .config files.
As a general rule, Asp.net developers should only set debug=true in the web.config files of the low-traffic developmental environments. When the asp.net web application is moved to a high traffic server (such as a production web server or even a Q&A server where load testing is done) debug needs to be set to false.
When debug is set to true, a temporary .dll is created in the asp.net temp directory and placed basically at random in the asp.net process’ memory space every time someone hits an aspx page. This swells and fragments the memory space. This frequently will lead to OOMs (out of memory exceptions). When debug is set to false, all this changes into something far more efficient in performance and far more conservative with use of the memory space.
However, it is also possible that debug=true was just making another problem come to the surface much faster. Sometimes when we set debug to false the problem doesn’t go away but it just takes a lot longer for it to manifest its self in performance. One possible reason for this is that the pagetimeout values get changed with debug set to true. Whereas the default page timeout value might be 90 seconds when debug is set to false, the page timeout value gets changed to something like 19,600 seconds when debug is set to true. So sometimes if a problem exists, you may never see the problem as long as the pages stop trying to do what they’re doing after 90 seconds. But if the pages keep trying for 19,600 seconds, well, if nothing else the memory is not freed as quickly.
FOR ASP.net 2.0…
One good trick to know about with asp.net 2.0 is that you can set deployment retail=”true” in the 2.0 machine.config file of the web server(s) rather than setting debug to false in all the web.config files.
Location:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config
Or
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\config\machine.config
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
http://aspalliance.com/1341_The_Infamous_DebugTrue_Attribute_in_ASPNET.all
§ Problem #1 - You will see a lot more files in Temporary ASP.NET files folder with debug=true…
§ Problem #2 - Your pages will not timeout when you have debug=“true.” …
§ Problem #3 Batch compilation will be disabled even if the batch attribute is true in the <compilation> element
§ Problem #4 The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation
§ Problem #5 Scripts and images downloaded from the WebResources.axd handler (in ASP.NET 2.0 only) are not cached by the browser when debug=true
§ What do you lose with debug="false"
§ Summary
Enabling debug mode will greatly affect the performance of your ASP.NET application. Remember to disable debug mode before you deploy a release application or conduct performance measurements.
893660 Quick things to check when you experience high memory levels in ASP.NET
http://support.microsoft.com/default.aspx?scid=kb;EN-US;893660
Application set up for debugging
One reason for high memory that we see here in Support a lot is when you have debugging, tracing, or both enabled for your application. While you are developing your application, this is a necessity. By default, when you create your application in Visual Studio .NET, you will see the following attribute set in your Web.config file:
<compilation … debug="true" />
and/or
<trace enabled="true" … />
Also,
when you do a final build of your application, make sure that you do this in
"Release" mode, not "Debug" mode. Once you are in
production, this should no longer be necessary. It can really slow down your
performance and eat up your memory. Why? Well, setting this attribute means you
change a few things about how you handle your application. First, batch compile
will be disabled, even if it's specifically set in this compilation element.
What this means is that you create an assembly for every page in your
application so that you can break into it. These assemblies can be scattered
somewhat randomly across your memory space, making it more and more difficult for
you to find the contiguous space to allocate memory for when you need it.
Second, the executionTimeout attribute ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfhttpruntimesection.asp
) is set to a very high number, overriding the default of 90
seconds. This is fine when debugging, because you can't have the application
time out while you patiently step through the code to find your blunders.
However, it is a big risk in production. This means that should you have a
rogue request for whatever reason, it will hold on to a thread and continue any
detrimental behavior for days rather than just a minute and a half. Finally,
you will be creating more files in your Temporary ASP.NET files folder, and the
System.Diagnostics.DebuggableAttribute ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdiagnostics.asp
) gets added to all generated code, which can cause performance
degradation.
If you get nothing else from this article, I do hope you get this. Leaving
debugging enabled is bad . We see this all too often, and it is so easy
to change. Also, remember that this can be set at the page level, so make sure
that all of your pages are not setting this.
815157 HOW TO: Disable Debugging for ASP.NET Applications
http://support.microsoft.com/default.aspx?scid=kb;EN-US;815157
To avoid the effect on performance, it is a good idea to enable debugging only when a developer is doing interactive troubleshooting. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot a problem, it is also frequently not disabled again after the problem is resolved.
301058 How To Debug an ASP.NET Application with the Microsoft CLR Debugger
http://support.microsoft.com/default.aspx?scid=kb;EN-US;301058
When the debug attribute in the Web.config file is set to true , it generates symbolic information every time the compiler compiles your .aspx pages as well as disables code optimization. If the application is not being debugged, you should change this attribute to false .
http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx
Don’t run production ASP.NET Applications with debug=”true” enabled
One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.
Doing so causes a number of non-optimal things to happen including:
1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached
http://blogs.msdn.com/tess/archive/2006/04/13/575364.aspx
ASP.NET Memory: If your application is in production… then why is debug=true
Statement
“Ensure that the debug="false" on the <compilation> element in the web.config file of each and every ASP.NET application on the server. The default during development is "true" and it is a common mistake to allow this development time setting to find its way onto production servers during deployment. You don't need it set to true in production and it often leads to memory overhead and inefficiencies.”
What problems does leaving debug=true cause?
There are three main differences between debug=true and debug=false:
1. ASP.NET Timeouts
2. Batch compilation
3. Code optimization
When you compile in debug mode it puts in a bunch of extra
diagnostic code
that can slow performance (whether or not the PDB file is present.)
You should use release mode for what it was designed: Release versions of
your software. Debug versions should be treated as prototypes, not finished
products.
Steve C. Orr, MCSD - http://Steve.Orr.net
http://blogs.msdn.com/jamesche/
Our most common issues deal with memory problems. Memory problems come in many flavors, but one of the more common ones is the OutOfMemory exception or OOM. . . . So what causes fragmentation? In our world, one of the most common causes is having a large number of dynamic assemblies loaded into the process, and one of the most common causes of that is the infamous debug attribute in the web.config file….
Also see… Out of memory! Are you nuts!?
http://bembengarifin-tech.blogspot.com/2007/04/find-application-with-debug-set-to-true.html
Find application with debug set to true using WinDbg
Troubleshooting System.OutOfMemoryExceptions in ASP.NET
In the graphic below, the uxq1bh4_.dll is one of the many dlls that is fragmenting the memory space of an asp.net process.
