Meilleures pratiques pour l'hébergement dans Internet Information Services

Article
05/10/2023

Cette rubrique décrit certaines des meilleures pratiques pour l’hébergement de services Windows Communication Foundation (WCF).

Implémentation des services WCF comme DLL

L’implémentation d’un service WCF comme DLL déployée dans le répertoire \bin d’une application web vous permet de réutiliser le service en dehors du modèle d’application web, par exemple, dans un environnement de test dans lequel les services IIS (Internet Information Services) ne sont pas déployés.

Hôtes de service dans les applications hébergées par IIS

N’utilisez pas les API auto-hébergées impératives pour créer de nouveaux hôtes de service qui écoutent les transports de réseau non pris en charge en mode natif par l’environnement d’hébergement IIS (par exemple, IIS 6.0 pour héberger les services TCP, étant donné que la communication TCP n’est pas prise en charge en mode natif sur IIS 6.0). Cette approche n’est pas recommandée. Les hôtes de service créés de manière impérative ne sont pas connus dans l'environnement d'hébergement IIS. Le point critique est que le traitement effectué par les services créés de manière impérative n'est pas pris en charge par les services IIS lorsqu'il détermine si le pool d'applications d'hébergement est inactif. Le résultat est que les applications qui possèdent ce type d'hôtes de service ont un environnement d'hébergement IIS qui élimine systématiquement les processus d'hôte IIS.

URI et points de terminaison hébergés par IIS

Les points de terminaison pour un service hébergé par IIS doivent être configurés à l'aide d'URI relatifs, pas d'adresses absolues. De cette manière, vous êtes certain que l'adresse du point de terminaison se situe dans le jeu des adresses URI qui appartiennent à l'application d'hébergement et que l'activation basée sur message se produit comme prévu.

Gestion des états et recyclage de processus

L'environnement d'hébergement IIS est optimisé pour les services qui ne maintiennent pas l'état local en mémoire. Les services IIS recyclent le processus hôte en réponse à divers événements externes et internes, ce qui peut entraîner la perte de tout état volatil stocké exclusivement dans la mémoire. Les services hébergés dans IIS doivent stocker leur état en dehors du processus (par exemple, dans une base de données) ou dans un cache en mémoire qui peut être recréé facilement si un événement de recyclage d'application se produit.

Notes

Les protocoles utilisés par WCF pour la fiabilité et la sécurité au niveau de la couche de message font appel à l’état en mémoire volatile. Les sessions fiables et les sessions de sécurité WCF peuvent se terminer de façon inattendue en raison du recyclage d’application. Les applications hébergées par IIS qui utilisent ces protocoles doivent soit dépendre d’un autre élément que la clé de session fournie par WCF pour corréler l’état au niveau de la couche application (par exemple, une construction au niveau de la couche application ou un en-tête de corrélation personnalisé), soit désactiver le recyclage de processus IIS pour l’application hébergée.

Optimisation des performances dans les scénarios de couche intermédiaire

Pour des performances optimales dans un scénario de couche intermédiaire (un service qui appelle d’autres services en réponse à des messages entrants), instanciez le client du service WCF au service distant une fois et réutilisez-le dans plusieurs requêtes entrantes. L’instanciation des clients du service WCF est une opération coûteuse par rapport à un appel de service sur une instance cliente préexistante, et les scénarios de couche intermédiaire offrent des gains de performances distincts en mettant en cache des clients distants sur les demandes. Les clients du service WCF sont thread-safe ; par conséquent, il n’est pas nécessaire de synchroniser l’accès à un client sur plusieurs threads.

Les scénarios de couche intermédiaire produisent également des gains de performance en utilisant les API asynchrones générées par l'option svcutil /a. L’option /a entraîne la génération par l’outil Service Model Metadata Utility (Svcutil.exe) de méthodes BeginXXX/EndXXX pour chaque opération de service, ce qui permet d’effectuer des appels potentiellement longs aux services distants sur les threads d’arrière-plan.

WCF dans des scénarios multi-résidents ou multi-nommés

Vous pouvez déployer des services WCF dans une batterie de serveurs Web IIS où un ensemble d’ordinateurs partage un nom externe commun (tel que http://www.contoso.com) mais sont adressés individuellement par des noms d’hôte différents (par exemple, http://www.contoso.com peut diriger le trafic vers deux ordinateurs différents nommés http://machine1.internal.contoso.com et http://machine2.internal.contoso.com). Ce scénario de déploiement est complètement pris en charge par WCF, mais requiert une configuration spéciale du site web IIS qui héberge des services WCF pour afficher le nom d’hôte correct (externe) dans les métadonnées du service (Web Services Description Language).

Pour garantir que le nom d’hôte correct apparaisse dans les métadonnées du service générées par WCF, configurez l’identité par défaut pour le site web IIS qui héberge des services WCF afin d’utiliser un nom d’hôte explicite. Par exemple, des ordinateurs résidant dans la ferme www.contoso.com doivent utiliser une liaison de site IIS *:80:www.contoso.com pour HTTP et *:443:www.contoso.com pour HTTPS.

Vous pouvez configurer des liaisons de site web IIS en utilisant le composant logiciel enfichable IIS Microsoft Management Console (MMC).

Les pools d'applications qui s'exécutent dans des contextes d'utilisateur différents remplacent des assemblys d'autres comptes dans le dossier temporaire

Pour garantir que les pools d’applications qui s’exécutent dans les contextes d’utilisateur différents ne peuvent pas remplacer d’assemblys d’autres comptes dans le dossier des fichiers ASP.NET temporaire, utilisez des identités et des dossiers temporaires différents pour des applications différentes. Par exemple, si vous avez deux applications virtuelles /Application1 et / Application2, vous pouvez créer deux pools d'applications, A et B, avec deux identités différentes. Le pool d'applications A peut s'exécuter sous une identité d'utilisateur (user1), et le pool d'applications B peut s'exécuter sous une autre identité d'utilisateur (user2), et configurer /Application1 pour utiliser A et /Application2 pour utiliser B.

Dans Web.config, vous pouvez configurer le dossier temporaire à l’aide de <system.web/compilation/@tempFolder>. Pour /Application1, cela peut être « c:\tempForUser1 », et pour application2, « c:\tempForUser2 ». Accordez l’autorisation en écriture correspondante à ces dossiers pour les deux identités.

Dès lors, user2 ne peut pas modifier le dossier de génération du code pour /application2 (sous c:\tempForUser1).

Activation du traitement asynchrone

Par défaut, les messages envoyés à un service WCF hébergé sous IIS 6.0 et versions antérieures sont traités de façon synchrone. ASP.NET effectue des appels dans WCF sur son propre thread (le thread de travail ASP.NET) et WCF utilise un autre thread pour traiter la demande. WCF met en attente le thread de travail ASP.NET jusqu'à la fin du traitement. Cela conduit au traitement synchrone des demandes. Le traitement des demandes de manière asynchrone permet une plus grande évolutivité car il réduit le nombre de threads requis pour traiter une demande. WCF ne met pas le thread ASP.NET en attente pendant le traitement de la demande. L’utilisation d’un comportement asynchrone n’est pas recommandée pour les ordinateurs exécutant IIS 6.0 car il n’existe aucun moyen de limiter les demandes entrantes qui exposent le serveur aux attaques par déni de service (DOS). Depuis IIS 7.0, une limitation des demandes simultanées a été mise en place : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Grâce à cette nouvelle limitation, l'utilisation du traitement asynchrone peut s'effectuer en toute sécurité. Par défaut dans IIS 7.0, le gestionnaire asynchrone et le module sont inscrits. Si cette option a été désactivée, vous pouvez activer manuellement le traitement asynchrone des demandes dans le fichier Web.config de votre application. Les paramètres que vous utilisez dépendent de votre paramètre aspNetCompatibilityEnabled. Si aspNetCompatibilityEnabled a la valeur false, configurez System.ServiceModel.Activation.ServiceHttpModule comme illustré dans l'extrait de configuration suivant.

<system.serviceModel>  
    <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
  </system.serviceModel>  
  <system.webServer>  
    <modules>  
      <remove name="ServiceModel"/>  
      <add name="ServiceModel"
           preCondition="integratedMode,runtimeVersionv2.0"
           type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>  
    </modules>  
    </system.webServer>

Si aspNetCompatibilityEnabled a la valeur true, configurez System.ServiceModel.Activation.ServiceHttpHandlerFactory comme illustré dans l'extrait de configuration suivant.

<system.serviceModel>  
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  </system.serviceModel>  
  <system.webServer>  
    <handlers>  
          <clear/>  
          <add name="TestAsyncHttpHandler"
               path="*.svc"
               verb="*"
               type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
               />  
    </handlers>
  </system.webServer>

Partager via