performance boosters for an asp.net website in production server.

Question

I have an asp.net webforms application in production server and it was really slow. So i decided to get some performance tips from my fellow SO users.

I ve applied these to increase my asp.net website performance,

1. Set debug=false
   

2. Turn off Tracing
   

3. Image caching

          <caching>
           <profiles>
               <add extension=".png" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".jpg" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".gif" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
           </profiles>
       </caching>
   

Any other real performance booster do you know? Any Suggestion...

Answer 1

Not directly ASP.NET, but

1) Make sure compression is enabled within IIS.

2) If your site is cookie "heavy" host static files (images, CSS and JS) within a separate domain. Each request back to the server needs to send all site cookie information back to the server. So if your cookie usage is 10kb+ then 20 static file references within the page will result in an extra 200kb being sent back to the server in total. If you move the static files over to a domain which has no cookie requirements you remove this overhead. It is worth noting that due to a "fault" in how IE processes things, you don't get any benefit in using subdomains, IE appears to insist in sending all domain cookies to sub domains. An additional benefit to this is allowing more HTTP requests in parallel

Answer 2

A webpage can be fast only by design.

A simple option can not make your page load faster. The debug=off only eliminate the extra debugging functions and actually if you are not use them can not make many thinks.

I agree with all that Paul say, and you can found them here with more details and I have to say as extra...

You need to follow some guide and do a lot of work to make them real fast. What I follow.

1. I use (custom) cache for my database action that really boost the data loading speed, but make at the same time the code to much more and I have spend a lot of time.
2. I have use profiler to find my slow points on the page and correct them.
3. I use the Inspector on Google Chrome Browser to locate slow loading and double loading problems.
4. I have eliminate the double use/create of any variables on custom controls.
5. I use cache on client browser base on this suggestions.
6. I use webfarm and/or webgarden (more than one pool).

How to see your page speed: http://code.google.com/speed/page-speed/docs/using.html

Optimize cache: http://code.google.com/speed/page-speed/docs/caching.html

Many general topic from google can be found here: http://code.google.com/speed/articles/

About caching: http://www.mnot.net/cache_docs/

Hope this help.

Answer 3

Stop hacking your production server (that is likely to introduce functional bugs) and take a step back. Can you reproduce the performance problems in a non-production environment? If not, then do the work to try.

You should try to reproduce the problem as follows:

• Get production-grade hardware in your test environment - web and database servers etc - running the same hardware as production
• Run the same software set as production - this includes the same configuration of ASPNET and all other servicces used.
• Load production-size data (production data if possible) into your databases (remember to firewall your lab from the internet so that it cannot send mail or other things to the internet, or your users might start receiving email notifications from the test system which would be bad!)
• Create simulated traffic to the site to production level - this is potentially quite tricky but there are a lot of tools available

Now you've got a fighting chance to repro the problem in testing, you can try solutions.

Usually database-driven web sites are bottlenecked by the database, so I'd start there. The main tricks are

• Do fewer queries
• Optimise the queries you do do (fetch less data, use appropriate indexes etc)
• Change the database structure so that the queries you have to do are easier for it (clustered indexes etc, denormalise possibly)

But any change you make, try it on your test system, measure the results, and if it doesn't help, ROLL IT BACK.

In general configuration changes are likely to make only minor differences, but you can try those too.

---

If all this sounds like too much effort, try throwing hardware at the problem - developer time is much more expensive than hardware. In the time it takes you to do the above (could be months depending on the complexity of the app) you could have bought some meaty production boxes. But be sure that it's going to help.

Does your database fit in RAM? Could it possibly fit in ram? If the answers to those questions are no and yes respectively, buy more ram for the database. This is one of the cheapest ways of making your db go faster without code changes.