Related Post

Spread the word

Digg this post

Bookmark to delicious

Stumble the post

DZone This Post

DotNetKick This Post

Add to your technorati favourite

Subscribes to this post

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

50 users responded to this post

DotNetKicks.com said in August 31st, 2007 at 12:40 am    

20 Tips to Improve ASP.net Application Performance

You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

Sean Dulin said in August 31st, 2007 at 9:48 am    

You might want to clarify tip number 3. Client side validation is only good if javascript is enabled on the browser. Even if javascript is enabled, it is still very easy to get around client side validation. Also, Firefox’s client side validation does not work due to the javascript Microsoft used(.NET 1.1 perhaps fixed in 2.0 or 3.0). Maybe server side validation should only be for extremely important validation, such as checking database inputs or something along those lines? Also, as I have just learned by retooling an old out of date application, HTML objects such as input tags can be used in validation, but the server side validation does not work. They always come out as valid however the javascript will run on them in IE and actually validate as designed.

SJ said in August 31st, 2007 at 9:49 pm    

Isn’t it app_offline.htm that takes the web site offline for maintenance? I don’t think appOffline.htm does anything.

Jason said in September 1st, 2007 at 9:58 am    

As soon as you start dumping rich controls, server side validation and other foundational concepts of the asp.net framework like view state and session state what do you have left? Not much. At this point you would probably be better off with an MVC framework such as MonoRail. Microsoft really needs to step up to the plate and embrace MonoRail or do their own MVC thing (more likely) because lots of applications are better served by this type of architecture. I imagine that performance would be a lot better too because you wouldn’t have all this often unnecessary page life cycle stuff.

Andrew said in September 3rd, 2007 at 11:07 am    

I think recommending #3 would go against best practice for secure development. If you don’t use server-side validation in a lot of circumstances, you’re asking for sql injection attacks and the like.

mikeb b said in September 3rd, 2007 at 11:21 am    

Tip #3 is very bad practice – you simply cannot trust client-side validation. It’s purpose is to enhance the user experience; however, all validation *must* occur on the server or you are in essence performing no validation.

mike said in September 3rd, 2007 at 12:08 pm    

In some cases, tip #6 can result in unexpected behavior with the browser’s Back button, since the browser’s history cache is not updated with you do a Server.Transfer.

A slight problem with a list like this is that it isn’t ordered by overall impact. The difference in performance improvement between using caching and using String.Builder is probably on the order of tens of thousands, but presented in a flat list like this, they seem kinda like they might be about the same.

Also, if you don’t turn off tracing, you have more problems than just overhead, what with users seeing big ol’ page dumps in their browser. :-)

Trumpi said in September 3rd, 2007 at 1:03 pm    

I’ve got to agree with the previous commenters on number 3. Only having client side validation will result in an insecure site. At best, you will end up with data quality issues if the client browser has Javascript disabled.

Complementing server side validation with client side validation is a good idea, though, since one can reduce the number of round trips to the server. This way the client will complete a valid form before any trip to the server is made.

John Rusk said in September 3rd, 2007 at 4:16 pm    

Regarding tip 11, the cost of exceptions is generally greatly overestimated by most developers. That’s because they are very slow when a debugger is attached (e.g. Visual Studio) but are 100s or 1000s of times faster when the same code runs outside Visual Studio.

In general, exceptions should be use properly, as they were designed to be. Don’t needlessly avoid them for performance reasons.

See http://www.yoda.arachsys.com/csharp/exceptions.html

Miguel Carrasco said in September 3rd, 2007 at 4:30 pm    

Hi everyone!

I thought I would let the comments keep flowing instead of piping in. GREAT comments!

Unfortunately I find that with blog’s, I have to sometimes omit certain things due to length. This is why I’m hoping to have the new Wiki and Forums up and running in the next few days! Hope to have even better discussions there!

Miguel

Vikki said in September 4th, 2007 at 12:35 am    

Much appreciated
It really works.. !! Now I have much quicker web sites.

Thanks,
Vikki

Anders Lybecker said in September 4th, 2007 at 12:51 am    

Oh no. Not another article like this….
When writing stuff like always include a description when each item apply and not apply. Along with a well throughout description – otherwise intermediate and advanced users do not gain any new knowledge.
The content is not wrong, but seriously faulty due to lack of context.

Holger Hansen said in September 4th, 2007 at 1:06 am    

1. If you use sessionstate on sql server and disable it only for pages, there is still a roundtrip to the sql server to update the timestamp on the session.
2. Isn’t it Response.Flush() ?
3. I know your intentions, but still leave server validation on for security reasons.
6. Transfer has its own flaws. Somebody mentioned that before.
7. Ah! Here is server validation at last.
13. It is HttpContext, and yes its useful. You can use it e.g. to transfer an exception forward to an error page. see http://msdn2.microsoft.com/en-us/library/aa479319.aspx
15a. Compress viewstate! Its easy and brings a lot. E.g. here: http://www.codeproject.com/aspnet/ViewStateCompression.asp
19a. I like using() better, but I am on C#.

Andrei Rinea said in September 4th, 2007 at 3:44 am    

I see no one mentioned that careless use of Server.Transfer (HttpServerUtility.Transfer) screws up the SEO of the site. Search engines can get confused by this.

Ben Crinion said in September 4th, 2007 at 3:48 am    

“Also, if you don’t turn off tracing, you have more problems than just overhead, what with users seeing big ol’ page dumps in their browser. :-)

I dont think that’s strictly true, i’m sure you can turn the page output off.

Miguel Carrasco said in September 4th, 2007 at 5:01 am    

Hi all,

The new forum is now active at http://forums.realsoftwaredevelopment.com

Please make sure you join, as I would like to move great discussions like this one to the forum!

Thanks,

Miguel

Muzikayise Buthelezi said in September 4th, 2007 at 7:31 am    

Hi Guys, so far comments have been hectic. But nice simple article though. I have been using ASP.NET 2.0 (coding in VB) since the beginning of this year(2007). and i must say i was disappointed about the speed at 1st, compared to ASP but now I prefer ASP.NET way better than ASP. For 1st timers ASP.NET is fun with all the GridView Controls, Calender, FormView and ect… until you have to Demo your new Web App to a client and it take 10 seconds to load every page, Not Good. Luckily the client was quite patient. So i added things Like “If Not Page.IsPostback then…” and played with some Caching and it made some difference but it was still missing that little extra. Anyway as I was about to give up on ASP.NET and then I came across AJAX and that changed my Life, AJAX was like a Godsend, anyway my Web App is working fine now, using AJAX and partial page updates and having things like server side validation is perfect for AJAX because its so fast.. So my advise would be to integrate your current ASP.NET app with AJAX, it can make your app faster.

DavidSJA said in September 4th, 2007 at 7:55 am    

What is appoffline.htm / app_offline.htm meant to do?!

WebGyver said in September 4th, 2007 at 11:18 am    

Sure, this would speed up things and possibly improve performance:

Avoid Server-Side Validation

Then again, you might want to differentiate between a web site and a web application. If you really don’t care about the data you’re accepting (and whether somebody intercepts and maliciously tweaks the form contents), you’re in good shape.

However, if you’re managing a database with thousands (or hundreds of thousands of records), from various clients with confidential information, you might as well pour some cyanide on your cereal.

Hey, at least this article gets people thinking about ASP.NET performance enhancement possibilities!

Jason Maletsky said in September 4th, 2007 at 12:49 pm    

I think (and hope) that he is saying to not use only server side validation, but a combination. Only crazy people would rely just on the client.

Miguel Carrasco said in September 4th, 2007 at 3:59 pm    

Hi everyone! I have posted a follow up to this article, I hope you enjoy the read!

http://www.realsoftwaredevelopment.com/2007/09/aspnet-performa.html

Thanks,

Miguel

John Puddifoot said in September 5th, 2007 at 3:23 am    

Just to expand slightly on what most of the comments here are referring to on point 3 for any users that aren’t aware of the potential impact of this move.

Server side validation on data collection isn’t optional in any way. The result of removing it is exposing your website/application to errors and, in cases, hacking. As described above, many users don’t have (or allow) cilent-side scripts running within their browser – meaning in these cases, client side validation doesn’t occur. So exmaples here would be the data could easily be incorrectly entered.

Worse than this however is the hacking element. Poorly protected scripts can be exposed to attacks such as SQL Injection (http://en.wikipedia.org/wiki/SQL_injection). It is true that Server Side validation alone will not protect you from this, and that there is a great deal of inaccurate information regarding it, however by exposing your site to unvalidated data, this is another thread. There are more problems (for instance if you allow users to send tags to the server without handling these). It’s a big old area to go into, but #3 is a definate no-no in my book.

Miguel’s second post about using both is far better. This doesn’t rely on client side code, it makes use of it if possible and both improves the responsiveness of the site to the user and reduces workload on the server (as the server will receive less unvalidated requests). It will however still receive some unvalidated requests – and this is when the Server Side checking kicks in.

Other than that, some interesting suggestions, but would benefit from further info and links to more sites for each point.

Gubatron said in September 5th, 2007 at 10:32 pm    

“Avoid server side validations”

Be ready to get your server side application to be hacked in every possible way

sadegh said in September 6th, 2007 at 12:03 pm    

very good article , thanke you.
http://www.FirstDL.com

sylv3rblade said in September 17th, 2007 at 8:22 am    

Although I’ve stopped developing in ASP, I found some of of the tips simply indispensable. ~kudos to you~

kalika prasad said in November 2nd, 2007 at 6:23 am    

hello sir ,

u have to be send many tips nd did use thanx alot for it. i like nd have taken benifit from it.

Ramesh said in November 16th, 2007 at 9:02 am    

Hai .. nice article , don’t get back by the negative feedback , its a part of a article , put something like this … so people start thinking about performance of ASP.NET and etc …

sivakumar said in November 29th, 2007 at 12:46 am    

need detailed info on tip no 4 . why datagrid controls are not good to use ?

Ally said in February 29th, 2008 at 9:25 pm    

It better to use both client-side and server-side validations because the client-side will only reduce the trips made when the user input wrong data but if the user bypasses it then server-side validations is very important.

Sathya said in March 26th, 2008 at 6:20 am    

A very good article. However, in tip 18, “Use ControlState and not ViewState for Controls”, you may probably want to add that it is not a substitute for viewstate. The underlying mechanism to persist controlstate is identical to viewstate (and consequently it has same drawbacks). ControlState should be used judiciously and only for data that needs to be persisted across postbacks irrespective of whether viewstate is enabled or not.

shan said in July 29th, 2008 at 8:04 am    

Nice article. Thank you

Kris van der Mast said in April 16th, 2009 at 7:42 am    

On tip 19: There's also an alternative by using the using keyword: http://msdn.microsoft.com/en-us/library/yh598w02….

Custom cars said in May 1st, 2009 at 6:16 am    

Gr8 job man…Such a gr8 posting these are the best 20 tips improve ASP.

Umar J said in July 1st, 2009 at 7:53 am    

you should not use client-side validation because a potential attacker can easily disable javascript and send malicious data to your web site. ALWAYS USE server validation AND client-side validation (because it is more user-friendly and users can check their data as they're writing it without waiting for the postback)

nutan said in August 21st, 2009 at 9:49 am    

All these points are very useful.
Thank You.

Ron said in September 18th, 2009 at 10:02 am    

My pages has lots of gridviews. Turning off Trace improves development speed. However, this is not enough. Typing a train a letters also has a crazy delay although significant improvement. How do I solve that?

Tom G said in December 1st, 2009 at 5:32 pm    

Bookmarked here –> http://www.codebounce.com/ASPNET

puma boots said in February 5th, 2010 at 8:22 am    

Typing a train a letters also has a crazy delay although significant improvement. How do I solve that?

steve said in March 24th, 2010 at 12:22 pm    

ASP.Net cache is said to be no.1 tip for improving ASP.NET pages. However, ASP.NET cache has many problems like scalability, data integrity, single point of failure. Details can be found here:

http://www.alachisoft.com/ncache/asp-net-cache.ht...

To avoid these issues, third-party distributed cache software must be used. There are many available like NCache. It has a free edition, too – NCache Express
http://www.alachisoft.com/download.html

I have used it, you dont need any code change at all and it will give you scalable performance even at peak load times.

Delimn said in March 26th, 2010 at 2:46 am    

.NET cache has many problems like scal

nike tn said in March 26th, 2010 at 3:04 am    

this is not enough. Typing a train a letters also has a crazy delay although significant improvement. How do I so

Gary said in April 14th, 2010 at 3:51 pm    

nice tips!

james said in April 22nd, 2010 at 12:59 pm    

@ steve

I've used the free version of Ncache for my ASP.NET application. It worked well and the performance was really boosted even when high load was put.

Data Quality S/w said in May 18th, 2010 at 10:20 am    

I think this is a great post from an expert and thank you very much for sharing this valuable information with us.

Davids said in May 21st, 2010 at 12:30 pm    

Hi,
Thank you for these very important tips for javascript:%20postComment(0);the mcse improvement of Asp.net. I hope that to follow these tips i will able to get better ranking in web development.

Louis vuitton said in June 5th, 2010 at 3:14 am    

I’m very interested in your article,

Ravi said in June 22nd, 2010 at 6:48 am    

It's very useful :)

solo said in July 11th, 2010 at 9:59 am    

I didn't realize how old this article was until I saw that searching was amazing

Amit Panchal said in July 31st, 2010 at 6:40 am    

to improve the performance of your asp.net application i have the best technique,
just have a look at this article about caching output in asp.net http://go2amitech.blogspot.com/2010/07/caching-ou...

Datta K said in August 27th, 2010 at 7:01 am    

Good one and Helpfull.

1 Pingback & Trackback On This Post
Leave Your Comments Below