The best way for a .NET site to handle high traffic

Question

One of the sites I manage will be linked to a website with very high traffic. Therefore, in the next couple of days I plan to increase my setup to make sure that it can cope with this high traffic load. My current setup is a 32-bit machine with 4 GB of RAM, Win Server 2K8, IIS7, SQL Server 2K5 and a dedicated web server in the same country from which traffic is expected. It is equipped with a leasing connection of 2 MBPS. This server is for my website, and the database is also located on the same website (for now). The website (mainly the ERP application) has a high database interaction and has significant graphics.

What could be the best way to handle traffic around 10K-15K in such cases?

Answer 1

As I said in my comment above, make sure that your server can handle high traffic, this is a server problem associated with the application.

Here are some tips to help you improve your site’s performance:

• Use data caching and output caching . The database query results cache in HttpRuntime.Cache , especially intensive, needs to be cached, and the output of individual pages should be cached using the OutputCache attribute.
• Reduce heavy resources . Make sure you keep resources under control, such as database connections / contexts, streams, etc. Also, for your database, your efficient queries can help.
• Test it out . As Remus said, testing is incredibly important. Send a bunch of requests and see what happens!
• Audit your site . See which methods use the most resources and take the longest, and try to improve them. In addition, the Google Chrome Inspector now has an auditing feature that is likely to give you some useful tips to make your site more efficient.
• Enable GZip compression - this will help you reduce the load on the network without significantly affecting efficiency.

Good luck

Answer 2

Test it out.

Fire requests 10k-15k (per day? Per minute? Per second?) On your server, see how it behaves. Measure and then take appropriate action. This measurement of the performance of .NET applications is a bit outdated, but you still get a decent mileage from the information in it (apparently, not all are dated, it is still recommended by some even in 2010).