The wow effect...Today while going through a performance report of a IIS7 Web server I saw a strange thing: the Network Interface Bytes/sec performance line was far apart from Web Services Bytes/sec counter.
Why is this strange? Well this particular server is just used for IIS hosting, so any incoming traffic would be HTTP traffic, which would imply that the lines should match...
The first thing checked was the traffic with a network sniffer and verified if all was really HTTP traffic coming to IIS, which it checked out: the majority of the traffic was Web.
The second thing checked was the healthiness of the performance counters. I've seen situations where performance counters just gone crazy! But this wasn't the occasion.
Without any obvious closure, I came to think of a third hypothesis: was IIS not counting the traffic made to the cached traffic on the performance counter?
Then I decided to setup a small lab on my desktop to give a try on replicating the last scenario.
The ingredients to a trial
- Setup a virtual machine with Windows 2008 R2 and IIS 7.5 installed
- Install HTTP request generator on the host machine: after some browsing on the Internet I went with JMeter.
- Configure a small application with IIS Output Cache enabled: just followed the Walkthrough Guide written by Saad Laki
After that, I only had to open Performance Monitor on the virtual server and add the counters in question (and also % Processos Time)
Right on the first try (IIS Output Cache active with Kernel mode) I've got the confirmation:
The performance traffic showed the traffic on the network interface rising, while the traffic on the Web Service just dropped to flat line. On J;Meter side, the effect was a around 3 to 4 millisecond response time:
Then I've decided to test the opposite case by removing the IIS Output Cache configuration, and the result was the recovery of the Web Service Bytes/sec line along the Network Interface performance line, and also a very big penalty on the CPU processing time...
On the JMeter side, the response time just when sky-high to the 200 miliseconds...
My short conclusion
So why the Web Service Bytes/sec performance counter doesn't increment with IIS output cache on kernel mode?
To answer this, you must first know how the IIS architecture works: there is a kernel driver before the IIS user process called HTTP.SYS. This intercepts the request and redirects the request to the WWW service and this redirects to Worker Process (usually a ASP.Net worker process). Take a look on the diagram from IIS 7 architecture description taken from IIS.net site.
With the IIS output kernel cache active, a cached request goes from flow 1 to 8 without passing by the remaining components, and therefore reducing the overhead associated with a complete end-to-end request.
Since the Performance Monitor is attached to WWW service, this means that the last will not know about the requests directly responded by the HTTP.SYS driver.
So, got the mystery solved and some more knowledge about IIS Output Cache!
The following test will be testing IIS output cache with static contents and see if there is any gains on this configuration.
Hope I don't take one year to post a new entry on this blog! :-)
PS: by the way, found the tutorial to setup JMeter here.