Attention: We are retiring the IIS.NET Community Blogs. Learn more >

Perf counter behavior changes in IIS6

I thought I'd really just share some information I collected while testing perf counters during the IIS6 days.  The big changes were primarily to address the architecture and new process model that HTTP.sys and IIS provided and also to help our scalability situation.  Much of the counter behavior was already documented in the resource kit, but I thought I'd add my own flavor to this, since I helped the UE people write the docs and I think they did a great job given the difficult challenge it is to write about something as you learn it.  So this blog basically covers two items; it covers counters that have new behavior and then some registry keys you can set if you really need to scale out your server for tens of thousands of sites (rare). 

 

Counters that have updated behavior

 

Bytes Per Second and Total Bytes counters

 

In IIS5, these counters gave you the Bytes per Second:

                            "BYTES_SENT_COUNTER",

                            "BYTES_RECEIVED_COUNTER",

                            "BYTES_TOTAL_COUNTER"

 

In IIS6, they give you Bytes Total (Total sent, total received, total sent+received)

 

These counters are new in IIS6 and will return the Bytes per Second values:

            "BYTES_SENT_PER_SEC",

            "BYTES_RECEIVED_PER_SEC",

            "BYTES_TOTAL_PER_SEC"

This brings the PDH counters in line with SNMP counters that had already existed. 

 

 

IIS 6.0 counts Current Non/AnonymousUsers as Current Requests; IIS5 equates users with connections. 

This means that you’re going to notice much smaller CurrentAnonymousUsers count in IIS6 (and consequently a lower MaxAnonymousUser). The same is true for NonAnonymousUser counters.  But actually it is just more accurate.  CurrentUsers are now the # of current in-flight requests (the # of requests currently being worked on by the server).  CurrentConnections is a better counter to monitor for scalabilty and availability metrics (its behavior is unchanged).  This number will of course be much higher than the number of users for sites that support keep-alive connections. 

It’s important to remember that in IIS6 each request (not connection) is logically a user. 

 

 

In IIS 6.0 the Kernel Mode Cache causes some new behavior in counters. 

 

You may notice that these counters no longer increment when files are only being served out of the Kernel-Mode cache. 

                Total Files Sent

                Total Files Transfered

Instead, Web Service Cache\Kernel: URI Cache Hits will be incremented.  

 

Total Anonymous Users and related Anonymous User counters will be updated during cache hits.  Be aware that the Kernel mode cache does not cache requests that are authenticated so the NonAnonymousUser related counters are exactly the same as before. 

 

 

New general counter behavior

 

Several new registry keys exist to help IIS scale to many more sites:

 

The registry keys all exist under this node:

HKLM\SYSTEM\CurrentControlSet\Services\w3svc\Performance\

 

Here are some typical settings that we used in our testing (no warranties expressed or implied):

"FreshTimeForCounters",1,"REG_DWORD"

"CheckCountersEveryNMiliseconds",250,"REG_DWORD"

"NumberOfTimesToCheckCounters",8,"REG_DWORD"

 

These registry keys allows IIS to “check” on the counters less often.  As you add more sites to IIS, each site will be “asked” for counters which can be quite time consuming.  The idea here is that you want to increase the Miliseconds and FreshTime to a higher number when you have higher sites.  You'll know you might want to do this if you have a lot of extremely idle sites (on the order of more than 10 thousand), but the w3wp's are using up a lot of processor time.  Be careful here, most people won't need to mess with these registry keys. 

No Comments