My current client has a pair of load balanced windows 2003 servers running IIS hosting 30+ sites each configured with its own app pool. They only serve pages to approximately 85,000 internal users but we got reports of occasional slow page load times. On investigation the worker pool associated with one website was consuming lots of CPU. With a 30 second sampling average we could see peaks of 75% at busy periods of the day with a CPU queue of up to 8. Using perfmon with a much more granular sampling period we could see the reality that the CPU was regularly spiking to 100% over the same 30 second period the enterprise monitoring tools were showing. We discounted caching issues after looking at the IIS perf on counters, and a hardware upgrade was out of the question as we already had the best CPU model the server could take. We looked at scaling out by re-purposing hardware in the same environment bit this would have cost and taken a relatively long time. One of the guys knew that some of the content was ASP pages and some of them used COM components, the theory being it was this that was causing the issue i.e. maybe the components weren’t being correctly released. Looking at the pages we could see that the MSXML component was being used on public pages to apply XSLT transform on XML encapsulated data (e.g. telephone lists). While MSXML 6 was present the registry configuration for the component was incorrect – only v3 was used. By default this is the Microsoft configuration, the latest COM version is set to 3 rather than 6. However, using procmon on the spiking threads in the worker process consistently showed that COM interop and marshalling at the top of the stack. The content authors were asked to not use the COM component, so they changed to using client browser side mechanisms instead. Once deployed cpu dropped to about 15% at peak.