web-dev-qa-db-fra.com

Qu'est-ce qui pourrait ralentir le chargement des pages de mon site dans ces IIS Règles de réécriture du module?

Les règles de réécriture IIS suivantes fonctionnent exactement comme je le souhaite sur mes serveurs de développement et de production sur un site Web CMS Orchard, bien que, une fois activé, ralentissent considérablement le chargement des pages du site. Ceci est facilement testé en activant/désactivant les règles afin de constater la baisse de performances qui semble s’accroître (c’est-à-dire pas une règle plus que les autres).

Comme ce sont les premières règles que j'ai jamais créées, j'imagine qu'il peut y avoir des pièges évidents, bien que mes recherches ne m'amènent à en découvrir aucun.

En d'autres termes, qu'est-ce qui pourrait causer le ralentissement des temps de chargement de ma page (... peut-être l'ordre?)

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

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

        <!--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" />
          </conditions>
          <action type="Rewrite" url="_{C:2}_index" />
        </rule>

        <!--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" />
          </conditions>
          <action type="Rewrite" url="_{C:5}_{R:1}" />
        </rule>
      </rules>
    </rewrite>
redirectsurl-rewritingperformanceoptimizationiis8
4
Livy Chope

D'après l'expérience passée, vous constaterez peut-être que le problème sera lié à la mémoire et non pas précisément aux règles de réécriture proprement dites. Ce que j’ai trouvé par le passé, même si je ne trouve la documentation nulle part, c’est que IIS dépend fortement de la mémoire système pour effectuer la réécriture des URL. Je pense que cela a quelque chose à voir avec la mise en cache des règles. Si tel est le problème, il peut s'avérer simple de fournir de la mémoire supplémentaire au serveur pour que IIS puisse l'utiliser.

Il existe également une fuite de mémoire connue liée à IIS règles de réécriture. Je me souviens de cette tâche, mais je ne peux pas placer la main sur la documentation pour le moment, bien qu'une mise à jour soit disponible. Si tel est le cas, il devrait pouvoir être corrigé en mettant à jour IIS avec la dernière version, ainsi que toutes les mises à jour, les service packs et les correctifs, dont je me souviens avoir ajouté une fonctionnalité permettant de nettoyer le cache interne. .

1
Chris Rutherfurd