IIS7 URL Rewrite module - things to know

Things not immediately obvious that you should know about the IIS7 URL Rewrite module, based on our experience at $work and the results of the support call we put in to Microsoft.

• There have been different packages of version 1.1 of the module over time, all with the same name. The only way to know which one you have is to check the DLL version. The most current DLL version in the URL Rewrite 1.1 package is 7.1.490.43. It is unclear at this point if Microsoft will do the same with v2.0 of the module, as it is still a Release Candidate. We have asked if they can properly identify the packages so we’ll know when one contains a new DLL.
• URL Rewrite has a memory leak, which appears to be something related to caching URLs. The leak is very bad in v1.1 of the module, and significantly improved but seems still present in v2.0 of the module. If you use URL Rewrite with many rules on a high traffic site you will see memory usage on IIS worker processes (w3wp.exe) grow. If you are using 32-bit worker processes performance will start to degrade after passing about 3Gb in size. Until we could find a solution to the memory leak, we worked around it by forcing a recycle of the application at 2Gb allocated.
• Microsoft recommends that a work-around for the memory leak in version 1.1 of the module is to use version 2.0 of the module. Although version 2.0 is not yet released (still Release Candidate), they indicate it is supported as production code (ie, you can open support tickets about it). We have found version 2.0 does seem to still have a slower leak, but our worker processes now recycle based on our normal time windows instead of allocated memory size. We are still testing v2.0, so have not yet revisited the memory leak issue with Microsoft.
• URL Rewrite rules set at the server-level (ie, top level, not in an individual site) are copied to every worker process. This means any requests for a given site must go through all server-level and then all site-level rules you have defined, even if they don’t match any server-level rules. Keep this in mind when defining server-level rules, especially on a server handling multiple high-traffic sites.

That’s enough for now, maybe more later.