Limitation des requêtes

Article
09/24/2014

Dernière modification : jeudi 3 mars 2011

S’applique à : SharePoint Foundation 2010

Dans cet article
Vue d’ensemble de la limitation des requêtes
Initialisation du système de limitation
Critères de blocage d’une requête
Compteurs de performances enregistrés
Classifieurs de requêtes
Calculateurs de score d’intégrité

Cette rubrique décrit le système de limitation de requêtes HTTP de Microsoft SharePoint Foundation lorsque les serveurs Web frontaux deviennent trop occupés pour traiter toutes les requêtes entrantes.

Vue d’ensemble de la limitation des requêtes

SharePoint Foundation intègre un système destiné à analyser les divers compteurs de performances de Windows Server 2008 et à limiter (c’est-à-dire, bloquer) les requêtes HTTP, si l’un de ces compteurs indique qu’un serveur est trop occupé pour traiter toutes les requêtes qu’il reçoit. Le système d’analyse et de limitation peut être activé ou désactivé pour une application Web SharePoint Foundation spécifique dans l’application Administration centrale ou au moyen d’une commande PowerShell dans SharePoint Management Shell. Le système peut être modifié à travers le modèle objet SharePoint Foundation ou des applets de commande dans SharePoint Management Shell.

Conseil
Avant d’entreprendre toute programmation au niveau du modèle objet d’analyse et de limitation de SharePoint Foundation, vous devez connaître le système de compteurs de performances de Windows Server 2008, ainsi que les concepts de catégorie (également appelée objet de performance), de compteur et d’instance. Pour plus d’informations sur ces éléments et sur la création de vos propres compteurs de performances, voir les rubriques suivantes : Compteurs de performances Windows (éventuellement en anglais) et les rubriques situées sous ce nœud. Introduction à l’analyse des seuils de performance (éventuellement en anglais) et les rubriques situées sous ce nœud. PerformanceCounter

Avant d’entreprendre toute programmation au niveau du modèle objet d’analyse et de limitation de SharePoint Foundation, vous devez connaître le système de compteurs de performances de Windows Server 2008, ainsi que les concepts de catégorie (également appelée objet de performance), de compteur et d’instance. Pour plus d’informations sur ces éléments et sur la création de vos propres compteurs de performances, voir les rubriques suivantes :

Compteurs de performances Windows (éventuellement en anglais) et les rubriques situées sous ce nœud.
Introduction à l’analyse des seuils de performance (éventuellement en anglais) et les rubriques situées sous ce nœud.
PerformanceCounter

Initialisation du système de limitation

Le système de limitation est initialisé dans le cadre de l’événement BeginRequest de la première requête HTTP adressée à un processus de traitement spécifique sur un serveur Web frontal. Les requêtes adressées par la suite à ce même processus réutilisent les entités et les threads initialisés dans la première requête. Si l’application Web est réinitialisée, le système l’est également avec la première requête consécutive à la réinitialisation. Les deux principales étapes de la procédure d’initialisation sont décrites dans les sous-sections suivantes.

Création d’un inspecteur de performances

Chaque processus de traitement de chaque application Web sur chaque serveur frontal dispose de son propre inspecteur de performances, qui est initialisé à partir des informations en provenance de la propriété HttpThrottleSettings de l’application Web. L’inspecteur est constitué pour l’essentiel des éléments suivants :

Un ensemble de scores d’intégrité, un pour chaque compteur de performances analysé. Les scores sont des valeurs Int32 comprise entre 0 et 10, la valeur 0 représentant le meilleur score d’intégrité possible et la valeur 10 étant le plus faible).
Un score d’intégrité globale pour le processus, qui est également une valeur Int32 comprise entre 0 et 10.
Pour chaque compteur analysé, un ensemble de valeurs de performances brutes qui ont été lues (échantillonnées) à partir du compteur. Elles sont classées du plus ancien échantillon au plus récent.
Un thread d’inspection de l’état du serveur utilisé pour échantillonner périodiquement les valeurs de compteurs.
Un paramètre d’intervalle d’actualisation qui détermine la fréquence de rééchantillonnage des compteurs. La valeur par défaut est 5 secondes.

Lancement du thread d’inspection d’état du serveur

Le thread d’inspection de l’état du serveur est créé en même temps que l’inspecteur. Il parcourt en boucle les étapes suivantes selon un intervalle spécifié par l’intervalle d’actualisation de l’inspecteur.

Obtention de l’objet SPHttpThrottleSettings dans la propriété HttpThrottleSettings de l’application Web. (Cet objet peut avoir changé depuis la dernière boucle ; par exemple, il se peut que l’intervalle d’actualisation ait été modifié ou qu’un compteur de performances supplémentaire ait été ajouté à la liste des compteurs analysés.)
Vérification que la limitation des requêtes n’a pas été désactivée depuis la dernière boucle.
Définition de l’intervalle d’actualisation de l’inspecteur avec la valeur de SPHttpThrottleSettings.RefreshInterval.
Appel de la méthode GenerateMonitors(). Cette méthode crée un objet SPSystemPerformanceCounterMonitor pour chaque compteur de performances qui doit être analysé. Les informations désignant les compteurs du serveur qui doivent être analysés sont fournies par un ensemble persistant d’objets SPPerformanceMonitorCreationData. Il en existe un pour chaque compteur qui doit être analysé. À chacun de ces objets de données de création correspond un objet SPHealthScoreCalculator enfant critique. Cet objet peut convertir une valeur de compteur de performances en un score d’intégrité compris entre 0 et 10. (Il peut également prendre le résultat d’une fonction mathématique de plusieurs valeurs de performances et la convertir en un score d’intégrité.)
Chaque moniteur échantillonne la dernière valeur du compteur qu’il analyse et la stocke dans l’ensemble de valeurs de performances brutes de l’inspecteur du compteur correspondant.
Chaque moniteur met à jour le score d’intégrité du compteur qu’il analyse. Cette étape comprend les sous-étapes suivantes :
1. Les valeurs d’échantillon peu pertinentes du fait de leur ancienneté sont supprimées du jeu de valeurs de performances brutes. Seules les valeurs n les plus récentes sont conservées, n étant la valeur de la propriété HttpThrottleSettings.NumberOfSamples.
2. Une fonction mathématique est appliquée aux valeurs restantes pour produire une moyenne pondérée des valeurs. Plus la valeur est récente, plus la pondération est importante.
3. Le moniteur utilise son calculateur de score d’intégrité pour calculer un score d’intégrité compris entre 0 et 10 pour la moyenne pondérée.
Le score d’intégrité globale du processus de traitement correspond au score le plus élevé (intégrité la plus faible) parmi les scores des moniteurs individuels.
Le niveau de limitation est défini en fonction des règles suivantes :
- Si le score d’intégrité globale du processus est inférieur à 10, il n’est pas nécessaire de limiter les requêtes. Le niveau de limitation prend alors la valeur Normal.
- Si le score d’intégrité globale est égal à 10 (valeur maximale et score d’intégrité le plus faible), mais qu’il l’est resté moins de 60 secondes, le niveau de limitation prend la valeur FirstStage. Autrement dit, certaines catégories de requêtes HTTP sont bloquées et une erreur HTTP 503 (« Service non disponible ») est envoyée au client. Cette limitation concerne uniquement les requêtes affectées à un même processus de traitement. Pour plus d’informations sur la façon dont le système détermine les catégories de requêtes à bloquer et la catégorie d’appartenance d’une requête donnée, voir Critères de blocage d’une requête plus loin dans cette rubrique.
- Si le score d’intégrité globale est égal à 10 et qu’il l’est resté pendant au moins 60 secondes, le niveau de limitation prend la valeur SecondStage. En d’autres termes, les catégories supplémentaires de requêtes sont bloquées.
Le thread d’inspection se met en attente pendant toute la durée de l’intervalle d’actualisation avant de se répéter.

Notes

Si le niveau de limitation a la valeur FirstStage ou SecondStage, la limitation continue pour le processus de traitement tant que son score d’intégrité globale n’a pas été réinitialisé à une valeur inférieure à 10 lors d’un cycle du thread d’inspection.

Critères de blocage d’une requête

Si le système d’analyse et de limitation est activé pour une application Web spécifiée, c’est au cours de l’événement PostResolveRequestCache d’une requête HTTP que le système détermine si celle-ci doit ou non être bloquée. Plus précisément, voici les étapes qui sont exécutées :

L’objet de réponse HTTP est initialisé et un en-tête qui contient le score d’intégrité globale du processus de traitement lui est ajouté.
Le niveau de limitation du processus est vérifié pour déterminer s’il correspond à FirstStage ou SecondStage. S’il n’est égal à aucune des deux valeurs, le processus n’est pas en mode limitation et les étapes restantes sont ignorées.
Si le processus est en mode limitation, la requête est testée par chaque classifieur de limitation de l’application Web. Les classifieurs de limitation sont des objets persistants qui sont stockés dans la propriété HttpThrottleSettings.ThrottleClassifiers. De fait, chaque classifieur de limitation est une définition d’une catégorie de requête HTTP. Vous pouvez utiliser n’importe quelle combinaison de caractéristiques de requêtes HTTP pour définir une catégorie, y compris l’extension de nom de fichier de la ressource demandée, les valeurs de certains en-têtes, l’agent utilisateur et la méthode HTTP (par exemple, « GET » ou « POST »). Le classifieur a une propriété ThrottleLevel qui précise si les requêtes qui appartiennent à la catégorie sont limitées au niveau FirstStage, SecondStage ou pas du tout. La requête est bloquée ou non en fonction des règles suivantes :
- Si le processus de traitement a un niveau de limitation FirstStage, toutes les requêtes des catégories ayant un niveau de limitation FirstStageet les requêtes qui n’appartiennent à aucune des catégories définies sont bloquées.
- Si le processus de traitement a un niveau de limitation SecondStage, les requêtes des catégories ayant un niveau de limitation SecondStage sont également bloquées, en plus de celles qui sont bloquées lorsque le processus de travail a un niveau de limitation FirstStage.

Notes

Les requêtes qui ne correspondent à aucun classifieur étant bloquées en mode de limitation FirstStage, vous devez créer par programme un objet classifieur pour un type de requête que vous ne voulez pas bloquer avant la deuxième phase et construire l’objet avec un ThrottleLevel de niveau SecondStage. De même, si un type de requête ne doit jamais être bloqué, vous devez construire un objet classifieur avec un ThrottleLevel de niveau Never. Pour plus d’informations sur les objets classifieur, voir Classifieurs de requêtes plus loin dans cette rubrique.

Une erreur HTTP 503 est envoyée au client lorsqu’une requête est bloquée.

Notes

Si une requête appartient à plusieurs catégories et que ces catégories n’ont pas le même niveau de limitation, elle est limitée en fonction de la catégorie limitée de façon la plus stricte. Par exemple, si une requête appartient à une catégorie limitée au niveau FirstStage et à une catégorie limitée seulement si le niveau SecondStage est atteint, elle sera limitée au premier stade.

Compteurs de performances enregistrés

Lors de la première installation de SharePoint Foundation, il se peut que certains compteurs de performances soient enregistrés automatiquement avec l’application Web initiale « SharePoint – 80 » ” pour les besoins de suivi du système d’analyse et de limitation. Vous pouvez ajouter ou supprimer des compteurs dans le système soit par programme, soit par le biais d’une applet de commande dans SharePoint Management Shell. Pour obtenir une liste des compteurs enregistrés pour une application Web donnée, utilisez l’applet de commande suivante dans SharePoint Management Shell:

Get-SPWebApplicationHttpThrottlingMonitor –identity http://<Web application URL>

Le tableau suivant dresse une liste de compteurs courants qu’un administrateur SharePoint Foundation peut souhaiter analyser pour une application Web.

Catégorie de performances	Compteur	Nom d’instance (s’il en existe plusieurs)
Mémoire	Mégaoctets disponibles	Ce compteur ne possède qu’une seule instance.
ASP.NET	Requêtes en attente	Ce compteur ne possède qu’une seule instance.
ASP.NET	Durée d’attente de la requête	Ce compteur ne possède qu’une seule instance.
Processeur	Interruptions/s	_Total

Pour plus d’informations sur l’enregistrement et l’annulation d’enregistrement par programme d’un compteur de performances pour une application Web, voir Procédure : inscrire un compteur de performance ou annuler l’inscription.

Classifieurs de requêtes

Un classifieur de requêtes HTTP est un objet d’une classe dérivée de SPRequestThrottleClassifier. Ces objets persistent dans la base de données de configuration en tant que valeur de la propriété HttpThrottleSettings.ThrottleClassifiers. Il existe des classes dérivées de SPRequestThrottleClassifier dans le modèle objet. Les propriétés de ces classes étant en lecture seule, vous ne pouvez pas modifier un objet classifieur de requêtes existant. Toutefois, vous pouvez ajouter au magasin de nouveaux objets classifieur avec des valeurs de propriétés différentes, puis supprimer les anciens objets classifieur. Les classes sont verrouillées, mais vous pouvez créer de nouveaux objets pour chacune des classes et vous pouvez faire dériver vos propres classes classifieur de SPRequestThrottleClassifier. Le tableau suivant présente les classes et le type de catégorie de requête que chacune peut utiliser à des fins de définition. Il présente également le niveau de limitation par défaut auquel les requêtes correspondantes sont limitées tant qu’un niveau différent n’est pas spécifié lors de la création de l’objet classifieur.

Type	Catégorie	Niveau de limitation par défaut
SPHttpFileExtensionThrottleClassifier	Demandes de ressources avec une extension de nom de fichier spécifiée	FirstStage
SPHttpHeaderThrottleClassifier	Requêtes qui contiennent un en-tête spécifié	FirstStage
SPHttpUserAgentAndMethodClassifier	Requêtes avec un agent utilisateur spécifié ou qui utilisent un méthode HTTP spécifiée	Never
SPSearchCrawlingRequestClassifier	Requêtes issues de robots de recherche	FirstStage

Notes

Par défaut, les requêtes qui ne correspondent à aucun classifieur sont bloquées au premier stade par le système. Vous devez donc créer de façon spécifique un objet classifieur ayant un niveau de limitation de Never pour les requêtes qui doivent être exemptées de limitation.

Pour plus d’informations sur l’enregistrement et l’annulation d’enregistrement par programme des objets classifieur de requêtes, voir Procédure : créer et inscrire ou désinscrire un classifieur de requête. Pour plus d’informations sur la création d’une catégorie de classifieur, voir Procédure : créer un classifieur de requête.

Calculateurs de score d’intégrité

Un calculateur de score d’intégrité transforme une valeur brute de compteur de performances (ou le résultat d’une fonction appliquée à plusieurs valeurs brutes) en score d’intégrité compris entre 0 et 10, où 0 représente l’état d’intégrité le plus élevé du compteur et 10 l’intégrité la plus faible. Un calculateur est un objet d’une classe dérivée de SPHealthScoreCalculator. Il existe déjà une classe analogue dans le modèle objet : SPBucketHealthScoreCalculator. Un objet de cette classe divise la plage de valeurs possibles d’un compteur en sous-plages appelées « compartiments ». L’objet dispose d’une méthode CalculateScore(Double) qui affecte un score d’intégrité à une valeur en fonction du compartiment dans lequel se situe la valeur. Seules les valeurs situées dans le compartiment d’intégrité la plus faible reçoivent le score d’intégrité le plus faible (10).

Les compartiments (c’est-à-dire, les limites de sous-plages) sont définis lors de la construction de l’objet SPBucketHealthScoreCalculator et peuvent être modifiés à l’aide de la méthode SetScoreBuckets([]).

Important

Lorsque vous définissez les compartiments à transmettre à un objet SPBucketHealthScoreCalculator, tenez compte des points suivants :

Ils sont codés en dur dans SharePoint Foundation pour limiter les requêtes uniquement dans le cas où la moyenne pondérée d’au moins un compteur analysé obtient le plus mauvais score possible (10).
L’objet SPBucketHealthScoreCalculator est verrouillé et son CalculateScore(Double) affecte la valeur 10 uniquement aux scores contenus dans le compartiment d’intégrité la plus faible.

Par conséquent, s’il est essentiel que la limitation soit activée lorsque la moyenne pondérée d’un compteur donné atteint une certaine valeur, veillez à définir les compartiments de sorte que cette valeur se situe dans le compartiment d’intégrité la plus faible.

Si vous voulez un calculateur de type compartiment dont la méthode CalculateScore(Double) se comporte différemment ou si vous avez besoin d’un calculateur de score d’intégrité qui n’utilise pas du tout de système de compartiment, faites dériver une nouvelle classe de SPHealthScoreCalculator et implémentez la méthode CalculateScore(Double), selon les besoins.

Un objet calculateur de score d’intégrité persiste dans la base de données de configuration en tant que propriété d’un objet SPPerformanceMonitorCreationData.

Pour plus d’informations sur la création de calculateurs de score d’intégrité et sur la façon de les affecter à des objets de données de création de moniteur, voir Procédure : créer, modifier et changer un calculateur de score d’intégrité de style compartiment.