ASP.NET performance in debug mode

[Guest]

All the documentation says that leaving an ASP.NET application in debug
mode has a big performance hit. I can't detect any difference between
debug and non-debug modes. Am I missing something or is the
documentation wrong?


I've been load testing an ASP.NET website (built in VS.NET 2003 in C#).
I've used the ACT to generate heavy loads over several minutes. Debug
or no debug produces almost identical performance results.


To ensure I'm really in non-debug mode I have:
1) rebuilt the solution (for all my included C# DLLs) in "release"
mode.
2) changed to debug="false" in web.config.


Is there something else to turn off debugging and get lots more
performance from my site?

 

[Jignesh Desai]

Apart from enhancing protection and security, release mode also contributes
to the size-reduction of MSIL files
Extra NOP IL instructions are excluded.

Regards,
Jignesh Desai.

 

[cic]

Yes - I can see the non-debug offers some marginal inprovements i.e. a
couple of percent smaller DLLs and extra speed. However the
documantation says there is a big perfromance hit. Unless I'm missing
something the documentation is wrong.

This would mean that I can leave in the symbol tables so I get nice
code-bug messages. Also I can leave on debug mode to watch my live
servers - all without any significant performance hit. Both are very
useful thing to do.
As anyone else benchmarked debug mode vs. non debug mode?

 

[Scott Allen]

This biggest problem with debug mode is that pages do not timeout. If
for some reason a request gets into trouble and is just spinning and
waiting for a database query or webservice call to return, then
requests start to queue and rejected.

You can always build and deploy symbol files in release mode.

 

[bruce barker]

the performance gain of release mode vs debug mode depend on the performance
characteristics of the application. asp.net apps are usually very database
and string manipulation orientated. these will see little performance gain.
also in an asp.net app the amount of user code to framework code is usually
a small percent. however a numerial analaysis, or bitmap manipulation
application (loops with thousands of iterations) will see a greater gain.

-- bruce (sqlwork.com)


| All the documentation says that leaving an ASP.NET application in debug
| mode has a big performance hit. I can't detect any difference between
| debug and non-debug modes. Am I missing something or is the
| documentation wrong?
|
|
| I've been load testing an ASP.NET website (built in VS.NET 2003 in C#).
| I've used the ACT to generate heavy loads over several minutes. Debug
| or no debug produces almost identical performance results.
|
|
| To ensure I'm really in non-debug mode I have:
| 1) rebuilt the solution (for all my included C# DLLs) in "release"
| mode.
| 2) changed to debug="false" in web.config.
|
|
| Is there something else to turn off debugging and get lots more
| performance from my site?
|

 

[John Saunders]

All the documentation says that leaving an ASP.NET application in debug
mode has a big performance hit.

Can you point me to some documentation that says this? I don't remember ever
seeing it.

John Saunders

 

[Juan T. Llibre]

re:

Can you point me to some documentation that says this?
I don't remember ever seeing it.

http://samples.gotdotnet.com/quickstart/aspplus/doc/perftuning.aspx

15. Do not forget to disable Debug mode: The <compilation> section
in ASP.NET configuration controls whether an application is compiled
in Debug mode, or not.

Debug mode degrades performance significantly. Always remember
to disable Debug mode before you deploy a production application
or measure performance.




Juan T. Llibre
===========

 

[John Saunders]

re:

http://samples.gotdotnet.com/quickstart/aspplus/doc/perftuning.aspx

15. Do not forget to disable Debug mode: The <compilation> section
in ASP.NET configuration controls whether an application is compiled
in Debug mode, or not.

Debug mode degrades performance significantly. Always remember
to disable Debug mode before you deploy a production application
or measure performance.

Thanks. I see there's a language issue. "significantly" != "big hit" to me.

John Saunders

 

[Juan T. Llibre]

Hi, John.

There's a bit more information at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp
and it sheds a bit more light on this.

---000---
Ensure Debug Is Set to False

When debug is set to true, the following occurs:

Pages are not batch compiled.

Pages do not time out.
When a problem occurs, such as a problem with a Web service call,
the Web server may start to queue requests and stop responding.

Additional files are generated in the Temporary ASP.NET Files folder.

The System.Diagnostics.DebuggableAttribute attribute is added to
generated code. This causes the CLR to track extra information
about generated code, and it also disables certain optimizations.

Before you run performance tests and before you move your
application into production, be sure that debug is set to false
in the Web.config file and at the page level.

By default, debug is set to false at the page level. If you do need
to set this attribute during development time, it is recommended
that you set it at the Web.config file level, as follows :

<compilation debug="false" ... />

The following shows how to set debug to false at the page level.

<%@ Page debug="false" ... %>

Note A common pitfall is to set this attribute at the page level
during development and then forget to set it back when the
application is moved to production.

---000---

A good way to establish whether there's a "degradation",
or a "big hit", is to build a Debug version and a Release version
of any application and profile both with the Web Application Stress Tool :

http://support.microsoft.com/default.aspx?scid=kb;en-us;815161

Download the WAST from:
http://www.microsoft.com/downloads/...5A-062A-439E-A67D-75A89AA36495&displaylang=en

WAST does run on Windows Server 2003 *and* Windows XP,
even though they are not mentioned in that page.

The IIS Resource Kit Tools also has a neat tool called the
"Web Capacity Analysis Tool" (Version 5.2) which can also
be used to see how much of a performance hit exists in Debug
versions of ASP.NET apps, compared to Release versions.

Get it at :
http://www.microsoft.com/downloads/...ee-a71a-4c73-b628-ade629c89499&DisplayLang=en



Juan T. Llibre
===========

 

[John Saunders]

Hi, John.

There's a bit more information at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp
and it sheds a bit more light on this.

....

Thanks a lot for all of the info.

I wonder if you have any performance numbers, or if one of those articles
has any. I'm interested to know if the performance hit is as much as 5%
(once all the pages have been compiled).

John Saunders

 

[cic]

My figures show less than 5% hit. Small timings are harder to measure
but I would say about 2 to 3%. This is for an application with a lot of
processing and moderated database use i.e. the .NET code is a
reasonable chunk of the time taken to service each hit.

I know this all comes down to definitions. Agreed that "significant"
isn't neccessarily "big". However "significant" would be more than
(say) 5% timing improvement. I doubt an end user would notice less
than 5% - thefore not "significant". Please forgive my initial sloppy
use of language.

 

[cic]

Thanks for all the replies on this. I think in summary:

1) Building .NET code with debug symbol tables has a slight performance
hit (extra NOPs) but probably not enough to outway the benefits of
having good crash messages when things go wrong unless you write fully
bug free code ;-)

2) Running ASP.NET in debug="true" mode is not such a good idea in
production. The main reason is not performance as measured by normal
load testing - but in the way ASP.NET treats processes in debug mode -
the main one being no timeout on runaway requests. However - to switch
debug on for short periods when you do want to debug a live site will
not create too many problem - just remember to switch it off again
later.

Is that a fair summary?

 

[cic]

I know this all comes down to definitions. Agreed that "significant"
isn't neccessarily "big". However "significant" would be more than
2-3% timing improvement. I doubt an end user would notice 2-3% -
thefore not "significant". Please forgive my initial sloppy use of
language.