HOWTO: Measure Effectiveness of the HTTP.SYS Kernel Mode Response Cache with IIS 6

  • Article

Hmm... ever since I wrote the referenced blog entry about HTTP.SYS Kernel Response cache and IIS 6.0, I have gotten questions about one thing that I forgot to mention - how to determine the effectiveness of the Kernel Response Cache. Here goes...

Question:

David,

To begin, I happened to come across your blogs on msdn regarding kernel caching https://blogs.msdn.com/david.wang/archive/2005/07/07/HOWTO_Use_Kernel_Response_Cache_with_IIS_6.aspx . It is excellent, but it also gave rise to another question for me:

Do you have a blog or are you planning to blog the details of how to measure the Kernel Cache performance using the Performance Counters for Web Service Cache? I am trying to figure out how I can analyze the performance of non-SP1 systems for window 2003 using perfmon.. Any existing docs/content you can think of would be much appreciated.

Please let me know,

Answer:

The "official" way to determine the effectiveness of the Kernel Response Cache involves PerfMon (aka Performance Monitor). The counters you want to watch are under the "Web Service Cache" Performance Object, and the most useful ones for the Kernel Response Cache are:

  • Kernel: URI Cache Hits
  • Kernel: URI Cache Misses

In short, the "Kernel: URI Cache Hits" counter increments every time a request is served from the cache... and "Kernel: URI Cache Misses" measures the other obvious event.

How do these two counters relate to the Cache Insertion policies I mention in this blog entry?

  • For the IIS Static File Handler, it means that you need to make two requests to the same URL within the ActivityPeriod timespan which pass the HTTP.SYS Cacheability criteria to insert the response into the cache, and the third and subsequent response comes from the cache until flushed via the Cache Eviction policies.

    You end up seeing "Kernel: URI Cache Misses" increment twice and "Kernel: URI Cache Hits" increment once for each subsequent request thereafter.

    For example, I make three requests within ActivityPeriod to /pagerror.gif and I see two misses initially and one hit on the third request..

  • For the HSE_REQ_VECTOR_SEND approach, you only need to make the request which causes the ISAPI to invoke HSE_REQ_VECTOR_SEND in the right manner as described in the earlier blog entry, and any subsequent requests with properties that end up matching the value of UNICODE_CACHE_URL of the original cached request will come from the cache until flushed via the Cache Eviction policies.

    You end up seeing "Kernel: URI Cache Misses" increment once on the first request, and "Kernel: URI Cache Hits" increment once for each matching subsequent request.

An "unofficial" way that I use to prove to myself that the perf counter actually works and that the response actually came from the kernel response cache, is to attach a debugger onto the w3wp.exe which should service the request in user mode and debugbreak into it. This ensures that this w3wp.exe cannot service the request... so if the response is truly cached in the kernel response cache, the request will succeed and the cache hit counter increments... while if the response was not really cached, the request will simply hang since w3wp.exe is broken into and cannot service the request.

//David