I have the following IIS rewrite rules that work exactly as I wish on both my development and live servers within an Orchard CMS website, though when enabled, seriously slow the site's page loads. This is easily tested by enabling/disabling the rules to notice the performance decrease, which appears to accrue (i.e. not one rule more than others).

As these are the first rules I've ever created, I imagine there may be some obvious pitfalls, though my research hasn't lead me to discover any.

So simply put, what might be causing the slowdown in my page load times (...perhaps order?):

        <rule name="www to non-www" enabled="true" stopProcessing="true">
          <match url="(.*)" />
            <add input="{HTTP_HOST}" pattern="^www.(.*)$" />
          <action type="Redirect" url="http://{C:1}/{R:0}" redirectType="Permanent" />

        <rule name="Dont Process Any Further" enabled="true" stopProcessing="true">
          <match url="^(about-us$|contact$|copyright$|privacy$|terms$|book$|surroundings$|
                 )" />
          <!-- Match url, Line (1): user specific. Line (2): app specific -->
          <action type="None" />

        <!--When root/url requested, goto _domain_index-->
        <rule name="Rewrite - Root Hit Redirect" enabled="true">
          <match url="^$" />
          <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
            <add input="{HTTP_HOST}" pattern="^(www.)?brun.azurewebsites.net" negate="true" />
            <add input="{HTTP_HOST}" pattern="^(www.)?brun.com" negate="true" />
            <add input="{HTTP_HOST}" pattern="^(www.)?(.*).com" />
          <action type="Rewrite" url="_{C:2}_index" />

        <!--Note: the first pattern in this rule stops the *possible* above rules URL
        being rewritten again i.e _domain_index to _domain__domain_index, whilst
        also allowing 'View' links from Orchards Dashboard to work-->
        <rule name="Rewrite - /page to /_domain_page" enabled="true">
          <match url="^(.*)" />
          <conditions logicalGrouping="MatchAll" trackAllCaptures="true">
            <!--<add input="{REQUEST_URI}" pattern="/_([a-zA-Z]+)_index$" negate="true" />-->
            <add input="{REQUEST_URI}" pattern="/_([a-zA-Z]+)_([a-zA-Z]+)$" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            <add input="{HTTP_HOST}" pattern="^(www.)?brun.azurewebsites.net" negate="true" />
            <add input="{HTTP_HOST}" pattern="^(www.)?brun.com" negate="true" />
            <add input="{HTTP_HOST}" pattern="^(www.)?(.*).com" />
          <action type="Rewrite" url="_{C:5}_{R:1}" />
  • 1
    If anything is to hurt performance, it would be any of the unoptimized script files that are part of the CMS. What you might want to do is test things with webpagetest.org and get a breakdown of why a page is loading slowly. If the top-most bar in the waterfall chart isn't mostly green then the problem isn't related to rewrite rules or any scripts. It's more a server issue. – Mike -- No longer here Mar 9 '16 at 4:38
  • Have you tried disabling them one at a time and seeing if there's an obvious issue with one of the rules? The main thing I'd think is that you've got some broken script/image/css links in your page that are being rewritten to content pages when you enable those rules which may cause page blocking - check the Network tab of a browser's F12 tools to see if you're getting a number of odd requests on the page. Alternatively, locally you can enable trace logging in IIS which will report on every single part of the request and how long it takes processing rules, etc. – Zhaph - Ben Duguid Mar 15 '16 at 1:10
  • @Mike - The OP states that the performance degradation can be tested by enabling disabling rules to see the performance decrease. While it is true that unoptimized static content such as CSS and javascript can, and commonly does, cause performance issues with websites you wouldn't expect it to substantially change when the rules are on and off. – Chris Rutherfurd Jul 5 '16 at 15:01
  • @Zhaph-BenDuguid - The OP states in his question that he has tested by disabling and enabling individual rules and that it appears to be cumulative and not caused by one more than another. – Chris Rutherfurd Jul 5 '16 at 15:02

From past experience I think you may find that the issue will be memory related and not precisely related to the rewrite rules per-say. What I have found in the past, although I can't find it documented anywhere is that IIS heavily depends on the system memory to perform URL rewriting, I believe it has something to do with caching the rules. If this is the problem it may be a simple case of provisioning additional memory to the server for IIS to use.

There is also a known memory leakage to do with IIS rewrite rules which I recall but can't place my hands on the documentation at this time for, although there was an update made available for it. If this is the case it should be able to be fixed by updating IIS to the latest version along with all updates, service packs, and hotfixes, one of which I do recall added functionality to clean up the internal cache.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.