IIS 7.5 extremely slow, intermittently no response

asp.netiis-7performance

I have a problem with our web server. It's running about 35 ASP.NET (mostly 4.0) sites using Windows Server 2008 R2 with IIS 7.5. It's patched as of mid-January this year.

Symptoms:

  • Intermittently extremely slow performance
  • Some requests seem to never be processed, resulting in ViewState errors
  • General sluggishness when navigating sites, browsers spinning waiting for a response

Some facts about the server that may matter:

  • It's running in a virtual machine on a very powerful, underutilized server
  • 12 GB RAM, 4 virtual CPUs

Some facts about our ASP.NET sites that may matter:

  • In low frequency, we synchronously send email from the site
  • Some requests are synchronously long-running because we create PDFs and reports on the fly. These requests may take more than 30 seconds to complete.
  • Each site is in its own application pool, 1 worker process (no web garden), recycle at midnight

Some performance counter facts:

  • ASP.NET performance counters show between 10 and 50 requests/sec
  • W3WP process performance counters show per process 10 to 45 threads, 1,000 handles. The total handle count is between 30,000 and 40,000 (fluctuating).
  • CPU usage is between 0 and 10 percent most of the time; may spike to 30 percent during long running request (PDF or report generation).

I'm really stumped as to why we get such bad performance. I'm suspecting it has to do with some thread pool/handle limit – I read that having around 40,000 handles dramatically reduces server performance etc. but I don't know how to get this under control.

Generally it's clear that something is preventing IIS from unlocking the power of the VM… the CPUs are mostly idle with very low usage. Any help?

Best Answer

40,000 handles? Look elsewhere, my fresh-booted laptop's sitting at 56,000 while I read this website. The documents you're looking at might be from the 90s!

The symptoms you've described are consistent with a networking problem.

If it's more than a little reproducible, I'd grab a simultaneous network capture from the server and a client. If it's not, I'd grab one from the server alone, and look for indications of connectivity problems (basically: retransmits).

Related Topic