Fun with http.sys Caching

Introduction

There are many caches available to web applications. Today I will play with the http.sys URI cache. It is a simple, fast, kernel-mode cache.

How it Works

First IIS must decide if the response can be stored in the http.sys' cache (devs: See HttpSendHttpResponse's pCachePolicy argument). There are about twenty reasons for IIS to decide something should not get in the cache (because of the cache's simple design). To find out why a specific request is not being cached, enable "Failed Request Tracing" and look for the HTTPSYS_CACHEABLE event's reason field.

Assuming the response meets the approx. twenty conditions, then IIS needs to decide if the item is "hot". Hotness can be configured using system.webServer/serverRuntime@frequentHitThreshold and frequentHitTimePeriod. A request is "hot" if it has been hit frequentHitThreshold times in the last frequentHitTimePeriod seconds. IIS only marks "hot" requests for caching.

Once IIS tells http.sys to cache, http.sys than applies some additional checks (settings), including a size limit, that defaults to 256kb. http.sys clears out entries that have not been accessed in UriScavengerPeriod (2 minutes by default).

Experiment

Using wcat, the attached wcat script and the attach content-creation script, I produced these results (using an old 1x dual-core machine):

Summary

• If you're serving megabytes/sec of static files, then you'll probably see some substantial performance improvements from http.sys caching.
• Sometimes IIS 7 Output Caching allows you to put dynamically generated responses in http.sys' cache.