ASP.NET Website Slow Performance on production server

Question

My problem is that my ASP.NET website is running slower on my production server comparatively on my development server.

A page that executes in 120ms in my development environment takes 400ms to execute on the server. I've monitored the SQL server with the profiler and the query being run on the page taking 400ms on the server only takes around 50ms to finish - so I've convinced myself that my problem does not lie with the SQL server.

My development machine is an Intel I7 with 6GB RAM, the production server is a 2x AMD Quad Core with 16GB ram.

Answer 1

Have you checked that the debug=false in your web.config?

Is the server 64bit? Try to create a dedicated application pool for your application and set the application pool to run in 32bit classic mode. Makes that any difference?

Is you class pre-compiled or have you set it up to compile at runtime?

Answer 2

Set Trace="true" (<%@ Page Trace="true"...) in your page and you will get a lot of useful information at the bottom of the page when it loads in the browser. You will know exactly how much time is needed to process the request on the server. If the time is low enough, then the problem could be in the IIS settings. Compare them to the ones on your dev environment.

Answer 3

Is your SQL server on another server on production, but local on development?

Answer 4

Massive viewstate causing transmission delay?

Answer 5

Is this the only website you have on the server? 16 GBs is pretty good memory, but if there are many popular websites on that same server they could be eating up the resources and CPU time.

Other than that I can't think of any reason why your website would be slow on production than in development.

Did you check out the indexes? They're all there on the server?

Answer 6

There are some point you can consider for performance improvment of your website.

1. Set debug=false
2. Turn off Tracing unless until required
3. Turn off Session State, if not required. ASP.NET Manages session state automatically. However, in case you dont require Sessions, disabling it will help in improving the performance
4. Disable ViewState as and when not required.
5. Avoid Frequent round trips to the Database
6. Avoid Throwing Exceptions. Exceptions are a greate way to handle errors that occur in your application logic. However, throwing exceptions is a costly resource and must be avoided. Use specific exceptions and use as minimal as possible to avoid resource overhead
7. Use Caching to improve the performance of your application.
8. Use Finally Method to kill resources

Edit: measure your website performance using this website http://www.websiteoptimization.com/services/analyze/
http://www.websitepulse.com/

Answer 7

For the connection string on the production environment, are you using (local) or the machine name or the IP address?

Answer 8

You need to reduce the variables.

Try eliminating all of the differences between the two environments, then make changes one by one until you figure out what it is.

Make sure that the web.config is the same in both environments.
Make sure both environments point to the same database server on a 3rd box.
Make sure the same version of IIS is in both environments.
Make sure IIS is configured the same in both environments.
Run the same test data on both environments.
etc...

Answer 9

From reading all the suggestions, and it seemingly like nothing is working, start taking code out of your site, little by little, and see how that affects time. Remove about 10 lines of code or HTML at a time, and see if there is a huge difference.

Otherwise, it probably has to do with IIS, and sorry, I ain't no IIS guru.

Answer 10

After banging my head against the wall for a long time concerning the performance difference of my development machine and the production machine, I finally caved in to the feeling I've been having deep down that the processor actually matter a lot more than you'd think.

I changed from an AMD based solution to an Intel based solution (Xeon!), gaining .3GHz and faster disks.

I also gained a performance boost, instead of being x3 as slow as my development machine it's now down to something like x0.75 slower - obviously still not the lightning speeds that my development machine is capable of but it's getting closer.

While debugging this further I noticed that most of the performance hog (which is no surprise really) is coming from LINQ to SQL having to compile queries, what seems odd to me is that once I tried precompiling a LINQ query and running the same thing on both my machines, the development machine turned out to be faster.