Geek Answers Handbook

Bottleneck in ASP.NET Bottleneck

The classic ASP.NET application is the AppSrv + MS SQL database. Both servers are 8-core heavy lifts, 20 GB of RAM. When testing the load, the throughput goes somewhere up to 400 virtual users (according to LoadRunner), when the processor takes up about 30%, the database server idles mostly - the response time increases sharply to the point of immunity.

The usual suspects, such as Max Pool, which have been exhausted, and the restriction of communication with the ASP.NET set are not errors: Max Pool is set to 200 and about 80 connections are used; conn limit is set to 0.

I ran code with ANTS, and it showed that blocking threads does not make a significant contribution.

Ideas are very welcome!

+4
source share
7 answers

Does the host use an application pool?

You tried to increase the number to 5-10 in

An Application Pool -> Performance -> Web Garden -> Max Number of worker processes
0
source

When no CPUs are closed and pages tend to not respond, my first guess is database locks. One thread can hold the rest if it does not release the lock on the table, which leads to unresponsive pages when you use the db server at idle.

Can you use the sql monitoring tool to verify that the database is used correctly on the machine and see if all users receive their data correctly?

One more thing; What information can you use when using memory?

+1
source

Add the registration to your application with the appropriate unique request identifier so that you can effectively track how much time each page load operation takes. For example, registration before and after each database call will indicate whether the database call lasts or not.

As others have suggested, adding logging / profiling on the database side will show if it is inhibited (or similar).

+1
source

We recently tuned our web application using the following IIS performance tuning , which turned out to be very successful.

Two settings defined on the server have been changed:

Using working set memory . Servers running Windows Server ™ 2003 are configured by default to give preference to the file system cache over the working set when allocating memory. Microsoft does this because Windows benefits from having a large file system cache. Because IIS runs on top of the Windows operating system, it also benefits from having a large file system cache. However, if your server is a dedicated IIS server, you can see better performance if you instead transfer the priority to the working set. The reason for this is that preference is given to the file system cache, often used code for writing to virtual memory. The next time this information is needed, something else needs to be transferred to virtual memory, and previously downloaded information must be read into physical memory before it can be used. This results in very slow processing.

Network bandwidth . By default, servers running Windows Server 2003 are configured to give preference to the file system cache over the working sets of processes when allocating memory (through the server property Maximum increase in throughput for file sharing). Although IIS 6.0-based servers benefit from the large file system cache, giving preference to the file system cache often causes the IIS 6.0 page code to be written to disk, resulting in long processing delays. To avoid these processing delays, set server properties to maximize data throughput for network applications.

The following services are not required on a dedicated web server:

  • Alert
  • Clipbook
  • Computer browser
  • DHCP Client
  • DHCP server
  • Fax service
  • File replication
  • Infrared monitor
  • Internet Sharing
  • Messenger
  • NetMeeting Remote Desktop Sharing
  • Network DDE
  • Network DDE DSDM
  • NWLink NetBIOS
  • NWLink IPX / SPX
  • Print spooler
  • Netbios TCP / IP Support
  • Telephony
  • Telnet
  • Uninterruptible power system
+1
source

The problem is probably in your machine.config .

You should check the following configuration options:

  • maxconnection
  • maxIoThreads
  • maxWorkerThreads
  • minFreeThreads
  • minLocalRequestFreeThreads

For a brief description: Tuning IIS 6.0 for performance

There are some differences between ASP.NET 1.1 and ASP.NET 2.0

ASP.NET 1.1

Recommendations about some practical values ​​that you can find in:

The default values ​​are minimum for any practical use and should be corrected as proposed in the related articles.

ASP.NET 2.0

The parameters are moved to the processModel section, and the parameters are automatically configured. In addition to automatic configuration, you can manually set the parameter values, so you should check if:

  • processModel enabled
  • autoConfig set to true
    or Options
  • set to the correct values

Verification Details: ASP.Net 2.0 processModel

+1
source

Also check network saturation. Make sure that you do not maximize the network connection between your test download machine and the web server. Also, if you are returning a lot of heavy text / binary data between your web server and the database server, check this network connection.

0
source

It may be a long shot, but you can try running your code with Patterns and Practices Checker to see if it finds any low hanging fruits.

0
source

More articles:


All Articles