Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique décrit différentes propriétés dans différentes zones de l’architecture WINDOWS Communication Foundation (WCF) qui fonctionnent pour contrôler la consommation des ressources et affecter les métriques de performances.
Propriétés qui limitent la consommation de ressources dans WCF
Windows Communication Foundation (WCF) applique des contraintes sur certains types de processus à des fins de sécurité ou de performances. Ces contraintes se présentent sous deux formes principales : les quotas et les limitations. Les quotas sont des limites qui, lorsqu’elles sont atteintes ou dépassées, déclenchent une exception immédiate à un moment donné dans le système. Les accélérateurs sont des limites qui ne provoquent pas immédiatement la levée d’une exception. Au lieu de cela, lorsqu’un seuil de régulation est atteint, le traitement continue, mais dans les limites définies par cette valeur de seuil. Ce traitement limité peut déclencher une exception ailleurs, mais cela dépend de l’application.
Outre la distinction entre les quotas et les limitations, certaines propriétés contraignantes se trouvent au niveau de la sérialisation, certaines au niveau du transport et certaines au niveau de l’application. Par exemple, le quota TransportBindingElement.MaxReceivedMessageSize, qui est implémenté par tous les éléments de liaison de transport fournis par le système, est défini sur 65 536 octets par défaut pour empêcher les clients malveillants d’engager des attaques par déni de service contre un service en provoquant une consommation excessive de mémoire. (En règle générale, vous pouvez augmenter les performances en réduisant cette valeur.)
Un exemple de quota de sérialisation est la propriété DataContractSerializer.MaxItemsInObjectGraph, qui spécifie le nombre maximal d'objets qu'un sérialiseur peut sérialiser ou désérialiser lors d'un appel unique de méthode ReadObject. Un exemple d'accélérateur au niveau de l'application est la propriété ServiceThrottle.MaxConcurrentSessions qui, par défaut, restreint le nombre de connexions de canal de session simultanées à 10. (Contrairement aux quotas, si cette valeur de limitation est atteinte, l’application continue de traiter, mais n’accepte aucun nouveau canal sessionful, ce qui signifie que les nouveaux clients ne peuvent pas se connecter tant que l’un des autres canaux avec session n’est pas terminé.)
Ces contrôles sont conçus pour fournir une atténuation prête à l’emploi contre certains types d’attaques ou pour améliorer les métriques de performances telles que l’empreinte mémoire, le temps de démarrage, etc. Toutefois, selon l’application, ces contrôles peuvent entraver les performances de l’application de service ou empêcher l’application de fonctionner du tout. Par exemple, une application conçue pour diffuser en continu la vidéo peut facilement dépasser la propriété par défaut TransportBindingElement.MaxReceivedMessageSize . Cette rubrique fournit une vue d’ensemble des différents contrôles appliqués aux applications à tous les niveaux de WCF, décrit différentes façons d’obtenir plus d’informations sur le fait qu’un paramètre entrave votre application et décrit les façons de corriger différents problèmes. La plupart des accélérateurs et certains quotas sont disponibles au niveau de l'application, même lorsque la propriété de base est une contrainte de sérialisation ou de transport. Par exemple, vous pouvez définir la DataContractSerializer.MaxItemsInObjectGraph propriété à l’aide de la ServiceBehaviorAttribute.MaxItemsInObjectGraph propriété sur la classe de service.
Remarque
Si vous rencontrez un problème particulier, vous devez d’abord lire le guide de démarrage rapide de résolution des problèmes WCF pour déterminer si votre problème (et une solution) y figure.
Les propriétés qui limitent les processus de sérialisation sont répertoriées dans Considérations de sécurité pour les données. Les propriétés qui limitent la consommation de ressources liées aux transports sont répertoriées dans quotas de transport. Les propriétés qui limitent la consommation de ressources au niveau de la couche application sont les membres de la ServiceThrottle classe.
Détection des problèmes d’application et de performances liés aux paramètres de quota
Les valeurs par défaut des valeurs précédentes ont été choisies pour activer les fonctionnalités d’application de base sur un large éventail de types d’applications tout en fournissant une protection de base contre les problèmes de sécurité courants. Toutefois, différentes conceptions d’application peuvent dépasser un ou plusieurs paramètres de limitation, bien que l’application soit autrement sécurisée et fonctionne comme conçu. Dans ces cas, vous devez identifier les valeurs de seuil qui sont franchies et à quel niveau, et décider des mesures appropriées pour augmenter le débit de l'application.
En général, lors de l'écriture de l'application et de son débogage, vous affectez à la propriété ServiceDebugBehavior.IncludeExceptionDetailInFaults la valeur true dans le fichier de configuration ou par programme. Cela stipule à WCF de retourner les traces de la pile d’exception du service à l’application cliente pour les afficher. Cette fonctionnalité signale la plupart des exceptions au niveau de l’application de manière à afficher les paramètres de quota impliqués, si c'est le problème.
Certaines exceptions se produisent au moment de l’exécution sous la visibilité de la couche Application et ne sont pas retournées à l’aide de ce mécanisme, et elles peuvent ne pas être gérées par une implémentation personnalisée System.ServiceModel.Dispatcher.IErrorHandler . Si vous êtes dans un environnement de développement comme Microsoft Visual Studio, la plupart de ces exceptions sont affichées automatiquement. Toutefois, certaines exceptions peuvent être masquées par des paramètres d’environnement de développement tels que Just My Code Visual Studio.
Quelles que soient les fonctionnalités de votre environnement de développement, vous pouvez utiliser des fonctionnalités de suivi WCF et de journalisation des messages pour déboguer toutes les exceptions et optimiser les performances de vos applications. Pour plus d’informations, consultez Utilisation du suivi pour résoudre les problèmes de votre application.
Problèmes de performances et XmlSerializer
Services et applications clientes qui utilisent des types de données sérialisables à l'aide du XmlSerializer génèrent et compilent du code de sérialisation pour ces types de données à l'exécution, ce qui peut entraîner des performances de démarrage lentes.
Remarque
Le code de sérialisation prégénéré peut être utilisé uniquement dans les applications clientes et non dans les services.
L’outil Utilitaire de métadonnées ServiceModel (Svcutil.exe) peut améliorer les performances de démarrage pour ces applications en générant le code de sérialisation nécessaire à partir des assemblys compilés pour l’application. Pour plus d’informations, consultez Guide pratique pour améliorer le temps de démarrage des applications clientes WCF à l’aide du xmlSerializer.
Problèmes de performances lors de l’hébergement de services WCF sous ASP.NET
Lorsqu’un service WCF est hébergé sous IIS et ASP.NET, les paramètres de configuration d’IIS et de ASP.NET peuvent affecter le débit et l’empreinte mémoire du service WCF. Pour plus d’informations sur les performances ASP.NET, consultez Amélioration des performances ASP.NET. Un paramètre qui peut avoir des conséquences inattendues est MinWorkerThreads, qui est une propriété du ProcessModelSection. Si votre application a un nombre fixe ou petit de clients, la définition de la valeur MinWorkerThreads 2 peut fournir une augmentation du débit sur une machine multiprocesseur qui a une utilisation du processeur proche de 100%. Cette augmentation des performances offre un coût : elle entraîne également une augmentation de l’utilisation de la mémoire, ce qui peut réduire la scalabilité.