ASP.NET Website Slow Performance on Production Server

My problem is that my ASP.NET site is slower on my production server compared to my development server.

A page running in 120ms in my development environment takes 400ms to execute on the server. I was tracking SQL Server with a profiler, and a query executed on a page with 400ms on the server only takes about 50ms, so I made sure my problem was not SQL Server related.

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

+2


source to share


9 replies


There are some things you can consider to improve the performance of your site.

  • Set debug = false
  • Disable tracing unless required
  • Disable session state if not required. ASP.NET Manages session state automatically. However, if you don't require sessions, disabling it will help improve performance.
  • Disable ViewState as and when not required.
  • Avoid frequent business trips to the database
  • Avoid throw exceptions. Exceptions are the most common way to handle errors thrown in your application logic. However, throwing exceptions is an expensive resource and should be avoided. Use specific exceptions and use as little as possible to avoid resource overhead.
  • Use Caching to improve the performance of your application.
  • Use finally method to dispose of resources


Edit: Measure your site's performance with this website http://www.websiteoptimization.com/services/analyze/
http://www.websitepulse.com/

+16


source


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

Is the server 64 bit? Try creating a dedicated application pool for your application and configure the application pool to run in 32-bit classic mode. Does it make any difference?



Is your class precompiled or is it configured to compile at runtime?

+5


source


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

+2


source


Is your SQL server on a different server in production, but local in development?

+1


source


From reading all the suggestions and nothing seems to be working, gradually enter the code from your site and see how it affects the timing. Remove about 10 lines of code or HTML at a time and see if there is a huge difference.

Otherwise, it probably has something to do with IIS and unfortunately I am not an IIS guru.

+1


source


Massive view causing transmission delay?

0


source


Is this the only website you have on the server? 16 GB is not bad memory, but if there are many popular sites on the same server, they can consume resources and CPU time.

Also, I can't think of any reason why your site will be slower in production than development.

Have you checked the indices? Are they all on the server?

0


source


You need to shrink the variables.

Try to eliminate any differences between the two environments and then make changes one by one until you figure out what it is.

Make sure the web.config is the same in both environments.
Make sure both environments point to the same database server on the third 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 in both environments.
etc...

0


source


After banging my head against the wall for a long time about the difference in performance between my development machine and the production machine, I finally got away from the feeling that I had deeply that the processor really matters much more than you think.

I changed from an AMD-based solution to an Intel-based solution (Xeon!) With 3.3 GHz and faster drives.

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

At the time we debugged this I noticed that most of the hog performance (not surprisingly) comes from LINQ to SQL to compile the queries, which strikes me as odd is that when I tried to precompile the LINQ query and run same thing on both my machines, development machine turned out to be faster.

0


source







All Articles