ASP.NET 1.x vs. 2.0 (Performance differences)
I recently ran across a report that an application in ASP.NET 2.0 ran up to 6X slower than when built for ASP.NET 1.x. Running ACT tests on a large project (the NetAdvantage 2006 Vol. 2 samples browser), I noticed that there were only 1/2 of the requests/second being served up in the CLR2 version of the project. This really baffled me, so I immediately started tearing pieces out of the page to isolate the problem. Even with an empty page, there was still a noticable performance problem. Finally I reconstructed the page. To my astonishment the performance was back to normal numbers, and now was aligned with the 1.x application.
Now, I'm not really sure what made me decide to re-create the page, but I'm glad I did. The real mystery was how two pages with the exact same ASPX and cs could perform so different! That's when I noticed a very subtle difference. The original page had an associated .resx file which the new page did not. Deleting this resx file actually fixed the problem. I'm still struggling to explain these results, especially since I haven't been able to reproduce these results in a more controlled environment. Have any of you run across similar findings?
So back to the customer's report. Not only was I unable to reproduce a performance difference to the scale that the customer had seen, but the customer also wasn't using any resx files. I was at a loss, as was support. Luckily the customer was able to identify the problem. It turns out that debugging was enabled in the web.config for the application in question.
In ASP.NET 2.0 debugging is turned on via the web.config, even if you are building in
Release mode. This is much different than the model used for ASP.NET 1.x where the project configuration was all that mattered. Any of you moving from 1.x to 2.0 please remember to keep this in mind, it will save your hours of headaches later on. An application built in debug mode can be devastating on performance. Check out
Scott Gu's blog on this exact topic. There's an excellent tip on how to modify the machine.config on your production server to ensure that an application never runs as debug.