Methods of .NET self-annihilation part 2: IIS ping


Last post I discussed why Frequent Web Application restarts are bad. This is an issue that can cause you pain trying to get the application back up running again:

Death by IIS Ping

IIS’ built-in health monitoring is quite simple, but despite it having the word “ping” in its name, it has nothing to do with the network/ICMP type ping that we are used to.

Instead, what it does is that it queues a “ping” work item into the thread pool of the monitored application pool, and waits for it to be executed. Now consider the case where the application has restarted for whatever reason during peak hours and your users are lining up long waiting to get the first pages from the freshly started application. The IIS ping health check has to wait in the same line and if it doesn’t get its check executed within the time span, the application pool is deemed unhealthy and restarted. This doesn’t make the situation any better even by a tiny bit unfortunately, and you may be stuck having a seemingly never-starting process.

For every application, there’s a threshold where the inflow of new requests are low enough to allow the IIS ping check to be executed within the time frame given. This explains why you will be able to get the application up and running if you block incoming requests in the firewall for the duration of the startup, and then let the load back on.

Or, just disable IIS ping.


Leave a Reply

Your email address will not be published. Required fields are marked *