I am interested in using UrlRewriter.NET and noticed in the config page for IIS 6.0 on Win2k3, that they say to map all requests through the ASP.NET ISAPI.
That's fine, but I am wondering if anyone has good or bad things to say about this performance wise? Is my web server going to be dragged down to its knees by doing this or will it be more of a small step up in server load?
My server currently has room to breathe now, so some performance hit is expected and acceptable.
According to this: http://mvolo.com/blogs/serverside/archive/2006/11/10/Stopping-hot_2D00_linking-with-IIS-and-ASP.NET.aspx ... we are talking of 30% impact of the resources used for serving images.
Update 1: It will depend on the amount of dynamic vs. static content you have. If you have enough spare capacity, you can just turn it on and follow closely the performance impact. If it starts to degrade too much you can just turn it off. After that you can proceed with confidence on doing the extension-less changes.
Wildcard mapping does have a huge impact on performance, mostly because it uses the app thread pool not for page request processing, but for all the content. Let's assume you have a usual page with at least 10 additional resources like images, css and javascript - then you're blocking other potential request by serving the static content directly from the pool. More info on asp.net IIS 6 threading can be found here.
One way to go over it (how i did it) is to unable wildcard mapping to the folders that hold the static content - after that you'll receive only valid app request as you would do in an ordinary situation.
The way to unmap the static directories is to create an application of each one of them and then do the unmapping, and after that to undo the application creating thing. You can find more details on Steve Sanderson's blog.
Maybe take a look at http://stackoverflow.com/questions/323325/iis-6-0-wildcard-mapping-benchmarks
It would appear to show what i've experienced in the wild over many years - the overhead when using the ASPNet dll is negligable. If you have enough traffic for it to be an issue, there will be a hundred things that are causing a larger bottleneck before it will be the ASPNet dll