Stefan Caunter

Dearth of knowledge here, thought I’d share my experiences.
Getting a busy, complex ASP.NET app to show snappy, fast page response to users is challenging, especially if potential bottlenecks cause intermittent slowness. Varnish is ideal for this, but requires careful adjustment and tuning for best effect. In particular, avoiding 503 errors caused by IIS hangs is most important. Delivering a page eventually is preferable to a quick timeout and a user confronted with the varnish 503 page. With determination, we can eliminate that possibility and speed things up nicely for IIS administrators.
First, varnish must health check the IIS backends. You need a version of varnish that will do this. Second, varnish must retry if the backend does not answer in a timely manner. Same need, post 2.04 version necessary. Third, varnish must wait in certain cases if we have to wait for the backend. Small bit of magic to do this.
I guess the overriding issue here is that ASP.NET apps, or any app for that matter will have problems, and our responsibility as sysadmins is to make them run as well as possible. Externally, we want to be able to send clients to a fast, healthy server, and we want to serve cached content to the extent possible within a demanding freshness use case.
Back end webservers should be checked with requests that time out quickly, and need to be set to quickly take a slow box out of the pool. Check a simple ASP page, not a flat file, and keep the timing reasonable for your app and scale needs. If you know your app lags at times (for whatever reason), you should be able to tune this check so that a server with a lot of requests in its w3wp.exe application pool queue will get marked sick until it clears its problem. Add these backends into your “impatient” director. Serve most requests with this director.
You cannot avoid a slow server altogether this way. IIS might be heading to a slow time but not be marked sick, and it will get requests that will sit there. We have to avoid the dreaded 503 error at all costs, and with a fast timeout you will get them unless you restart in vcl_error. Instead of giving up, varnish tries again. You’ll get a healthy server, and (almost) never show 503 to the client, especially once the varnish cache heats up.
My technique to deal with “have to wait” scenarios (login, POST, search) is to create a “patient” pool. Same servers, but long timeout on the first_bytes_check. Send these type of requests to this director. Instead of a 503, we patiently wait for a response. Result: fast response on most pages, and correct response when patience is a normal part of user expectations.