Speed Up Your Site! 8 ASP.NET Performance Tips

Notice: This is a discussion thread for comments about the SitePoint article, Speed Up Your Site! 8 ASP.NET Performance Tips.


nice just what i needed.

I wonder how gzip compresses whitespace.?.?

currently when i fetch an article i strip whitespace before adding it to the page. Can this be done globally to the page?

maybe extending/inheriting from HtmlTextWriter writer and overriding the write method? then in the master page override the render and pass your htmltextwriter with base.render(mywriter);

i haven’t tried this yet but that might work.

just sharing my thoughts… let me know if there is another approach to the whitespace problem.

In my thoughts, the best way to increase the performance of an ASP.NET app is the use of third party distributed caching solution. Due to its stand alone and in-process nature, ast.net cache is only good for small web farms. But in a larger web garden, it may ends up with some scalability and reliability issues. So in this case a distributed caching product like NCache can be a good option.

wonderful article! as ASP.NET app has to deal with 10000’s of requests at the same time, it may ends up with some performance issues specially at peak load times. apart from some other solutions, the use of a third party distributed caching solution can also be a good option. caching products like NCache and Velocity are doing pretty well job in this niche.

Re: “Compressing the View State”

The article suggests deriving a CompressedViewStatePage from the standard System.Web.UI.Page class. I think this is bad advice, for several reasons.

  1. Deriving a new class from the standard Page is a “one-time remedy”. Other developers may use the same technique for their problems. But .NET only allows single inheritance, so the solutions will be imcompatible with eachothers. As such basing your development on a Page deriviative is a drastic measure which should not be used when there are alternatives.

  2. You lose tool support. VS generates pages which by default derives from System.Web.UI.Page. You will have to remember to change this each and every time you created new page. Or you will have to create a new page template for visual studio and use this instead of the default “webform”.

  3. Most importantly, there is already a standard solution built into ASP.NET for doing exactly this. ASP.NET comes with a “persisters” for hidden field (the default) and session. It is trivial to develop e.g. a file-based persister.

You are mostly correct (as usual) but:

  1. You lose tool support. VS generates pages which by default derives from System.Web.UI.Page. You will have to remember to change this each and every time you created new page. Or you will have to create a new page template for visual studio and use this instead of the default “webform”.

Not exactly. You can specify a base page class in the configuration file in 2.0.

I would also argue that just about every non trivial project will end up using a specified base page class (or set of classes) to handle some glue functionality.

Hmm. That never worked for me (tried some time ago). IIRC that config setting merely controls which class pages without codebehind should derive from.

I’m wary of subclassing the Page class, as it is a “one shot” solution. Once you’ve done that you can’t use the same solution for a related or analogous problem. I.e. subclassing the Page class does not scale architecturally.

Good point on the config setting; I can’t recall it working for me either.

If properly planned, having an “application base page” works very well in many cases. The main kicker is that it is the one place where you can bridge between your logic layer, the HttpRuntime and controls.

Unfortunately, alot of people try and throw alot of application logic into the MasterPage as it seems to be convenient, but that is far easier to break than using base page classes.

I don’t quite get how the PageStatePersister property works. Is there some sort of tutorial? Admittedly, I’m very tired so I’m not operating at full capacity, but a friendly walkthrough would be helpful. Thanks!

http://aspnet.4guysfromrolla.com/articles/011707-1.aspx#postadlink

One thing not mentioned is memory preasure on a webserver. Most servers host 100’s of websites & if yours is not one of the most popular then your code will not be in memory.
A popular method to get around this is to ping your web site. This will keep the site in the servers memory and keep your site responsive. I use a free service called Site Stalker. They also collect stats on how often your site has outages and average response times. I’ve been using the it to measure the improvements I make in my site (output cache turned out to reduce my load times from 2.2 seconds to .2 seconds).
-Will