Now that’s a sandwich. If you’re gonna do it, you might as well do it right.
Sweet Mother of Bacon
Mar 25
In today’s hectic world, it’s easy to forget about or just plain give up on tradition.
Refactoring performance in Visual Studio 2005 (out of the box [w/ a web project in your solution]) is poor. This seems to be primarily due to the inclusion of web project related files in refactoring. This (for me) has rendered refactoring support unusable in many instances.
Luckily you can change this behavior.
Using the output cache is super fast, so it’s nice to use when performance is a concern. And performance is often a concern around Web Service interfaces, so it’d be nice to use it there.
The easiest way to do it globaly is to hook the PostRequestHandlerExecute event in the request processing pipeline and set your cache policy values there (conditionally if necessary). However there seems to be some requirement to set the CacheDuration property on the WebMethod attribute of the method being exported via the service. I’m not sure why this is, but presumably it’s doing something to provide appropriate ‘varyby’ handling for the request body based SOAP message.
So it looks as if IIS 6.0 (or IIS 6.0 on 64 bit) on Windows XP has a different value for /w3svc/MaxConnections than does IIS 5.1 (or at least IIS 5.1 on 32 bit).
IIS 6.0 Windows XP 64 bit /w3svc/MaxConnections = 40
IIS 5.1 Windows XP 32 bit /w3svc/MaxConnections = 10