Estimer les exigences de performances et de capacité pour la gestion de contenu Web dans SharePoint Server 2010

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article contient de l’aide sur la gestion de la capacité pour les sites Microsoft SharePoint Server 2010 sur lesquels la fonctionnalité Infrastructure de publication est activée. Ce document est spécifique à SharePoint Server 2010 et les informations qu’il présente ne s’appliquent pas à SharePoint Foundation.

Cet article présente les scénarios suivants :

• Un site de publication Internet (site de présence d’une entreprise).

  Ce type de site est publié sur Internet et permet aux utilisateurs d’Internet anonymes de rechercher des informations sur une société. Les sites de ce type sont personnalisés et le contenu est étroitement contrôlé.

• Un site de publication intranet (site d’information interne).

  Ce type de site est publié en interne au sein d’une organisation. Sa principale utilisation consiste à partager des informations avec les utilisateurs authentifiés au sein de l’organisation. Les informations du site peuvent être gérées de manière étroite ou des zones peuvent être gérées de façon moins stricte.

• Un Wiki d’entreprise (référentiel de connaissances).

  Un Wiki d’entreprise est un site à batterie de serveurs unique qui croît naturellement à mesure que les collaborateurs créent des pages et les lient à des pages existantes ou futures. Les Wikis d’entreprise sont généralement publiés en interne au sein d’une organisation. Ce site permet aux personnes d’une entreprise ou d’une organisation de capturer et de partager des connaissances à l’aide d’une solution intégrée à leur environnement SharePoint et améliorée par celui-ci.

Après avoir lu ce document, vous comprendrez les concepts suivants :

• la métrique clé (débit) que vous devez optimiser pour prendre en charge de nombreuses opérations de lecture ;

• les différents goulots d’étranglement potentiels liés à un déploiement de la gestion de contenu Web SharePoint Server 2010 ;

• l’importance du cache de sortie pour l’optimisation du débit ;

• l’impact des opérations d’écriture sur l’expérience de lecture de l’utilisateur final.

Dans cet article :

• informations préalablement requises

• Détails et approche des tests

• Déploiements de la gestion de contenu Web

• Éléments à optimiser

• Résultats des tests et recommandations

• À propos des auteurs

informations préalablement requises

Avant de lire ce document, vous devez avoir assimilé les concepts clés sur lesquels repose la gestion de la capacité dans SharePoint Server 2010. La documentation suivante vous permet de vous familiariser avec l’approche recommandée pour la gestion de la capacité et fournit un contexte qui vous permet de comprendre comment utiliser efficacement les informations contenues dans ce document.

Pour plus d’informations conceptuelles sur les performances et la capacité susceptibles de faciliter la compréhension du contexte des données fournies dans cet article, voir les documents suivants :

• Gestion et dimensionnement de la capacité pour SharePoint Server 2010 (éventuellement en anglais)

• Études de cas techniques sur les performances et la capacité (SharePoint Server 2010) (éventuellement en anglais)

Détails et approche des tests

Dans chaque test, des variables susceptibles d’exister en situation réelle ont été extraites pour indiquer des recommandations spécifiques. Par conséquent, il est très important d’effectuer des tests et de suivre une procédure de surveillance dans votre propre environnement pour vérifier que la mise à l’échelle répond au volume de demandes attendu. Pour plus d’informations sur les concepts de gestion de la capacité, vous pouvez consulter Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Cet article présente les performances liées aux fonctionnalités de la collection de sites, à la fonctionnalité Infrastructure de publication de SharePoint Server et la mise en cache de sortie. Ces fonctionnalités ne sont disponibles que si la fonctionnalité Infrastructure de publication de SharePoint Server est activée. Par défaut, cette fonctionnalité est activée pour les portails de publication.

Jeu de données

Les tests ont été menés à l’aide d’un jeu de données qui partage des caractéristiques avec les déploiements réels de la gestion de contenu Web. Bien que la charge fût constante, différentes pages ont été demandées. Le tableau suivant décrit le jeu de données utilisé pour ces tests.

Jeu de données

Objet	Site de publication
Taille des bases de données de contenu	2,63 Go
Nombre de bases de données de contenu	1
Nombre de collections de sites	1
Nombre d’applications Web	1
Nombre de sites	50
Nombre de pages	20 000 pages, réparties en 20 dossiers comportant 1 000 pages chacun
Composition des pages	Pages d’article en HTML de base, avec des références vers deux images
Taille des pages	42 Ko (page non compressée) et 12 Ko (page compressée)
Images	3 000, présentant chacune une taille comprise entre 30 Ko et 1,3 Mo

Il est recommandé de configurer les services Internet (IIS) de manière à compresser systématiquement les fichiers au lieu d’utiliser le paramétrage par défaut consistant à compresser les fichiers dynamiquement. Lorsque la compression dynamique est activée, IIS compresse les pages jusqu’à ce que l’utilisation de l’UC dépasse un certain seuil, point auquel IIS arrête de compresser les pages jusqu’à ce que l’utilisation repasse sous le seuil. Pendant la réalisation des tests indiqués dans cet article, la compression était toujours activée.

Ce jeu de données de test n’a utilisé que des fonctionnalités SharePoint Server 2010 par défaut spécifiques au produit. Votre site comprend probablement des personnalisations en plus de ces fonctionnalités de base. Par conséquent, il est important de tester les performances de votre propre solution.

Configuration matérielle

Le nombre de serveurs Web dans la batterie de serveurs différait d’un test à l’autre. Toutefois, tous présentaient la même configuration matérielle. Le tableau suivant décrit la configuration matérielle des serveurs Web et des serveurs d’applications utilisés pendant ces tests.

Spécifications matérielles des serveurs d’applications et des serveurs Web

	Serveur Web
Processeurs	2 quadri-cœurs à 2,33 GHz
RAM	8 Go
Système d’exploitation	Windows Server 2008, 64 bits
Taille du lecteur SharePoint	300 Go
Nombre de cartes réseau	2
Vitesse des cartes réseau	1 gigabit
Authentification	De base Windows
Type d’équilibrage de la charge	Équilibrage de la charge matérielle
Version logicielle	SharePoint Server 2010 (version précommerciale)
Services en cours d’exécution localement	Administration centrale Courrier électronique entrant Microsoft SharePoint Foundation Application Web de Microsoft SharePoint Foundation Service Minuteur de flux de travail Microsoft SharePoint Foundation

Le tableau suivant décrit la configuration matérielle des serveurs de bases de données utilisés pendant ces tests.

Spécifications matérielles des serveurs de bases de données

	Serveur de bases de données
Processeurs	4 quadri-cœurs à 3,19 GHz
RAM	16 Go
Système d’exploitation	Windows Server 2008, 64 bits
Stockage	15 disques de 300 Go à 15 000 tr/m
Nombre de cartes réseau	2
Vitesse des cartes réseau	1 gigabit
Authentification	NTLM
Version logicielle	Microsoft SQL Server 2008

Glossaire

Ce document comprend certains termes spécialisés. Voici certains termes clés et leurs définitions :

• Demandes par seconde   Nombre de demandes reçues par une batterie de serveurs ou un serveur en une seconde. Il s’agit d’une mesure courante de la charge d’un serveur et d’une batterie de serveurs.

  Notez que les demandes diffèrent des chargements de page ; chaque page contient plusieurs composants, qui génèrent chacun une ou plusieurs demandes lors du chargement de la page. Par conséquent, un même chargement de page génère plusieurs demandes. En règle générale, les événements et les vérifications d’authentification qui utilisent des ressources insignifiantes ne sont pas pris en compte dans les mesures des demandes par seconde.

• Zone verte   Il s’agit de l’état dans lequel le serveur peut répondre à l’ensemble de critères suivant :

  • La latence côté serveur pour au moins 75 % des demandes est inférieure à 1 seconde.

  • Tous les serveurs présentent une utilisation de l’UC inférieure à 50 %.

  • Le taux d’échec est inférieur à 0,01 %.

Déploiements de la gestion de contenu Web

Deux modèles de création de contenu dans les sites de publication SharePoint sont susceptibles de déterminer le choix de la topologie de batterie de serveurs.

Dans le modèle de création sur place, une collection de sites unique est partagée par les auteurs et les visiteurs. Les auteurs peuvent créer et mettre à jour du contenu à tout moment, ce qui aboutit à des distributions variables des opérations de lecture et d’écriture pendant une journée donnée. En règle générale, de nombreuses lectures et un nombre modéré d’écritures ont lieu dans cette batterie de serveurs

Le diagramme suivant illustre le fonctionnement de la création sur place du point de vue de la topologie.

Dans le modèle de déploiement de contenu, plusieurs collections de sites prennent en charge séparément et de façon exclusive la création et la publication du contenu. Le contenu est créé et mis à jour dans l’environnement de création, puis est déployé de façon planifiée sur l’environnement de publication en vue de sa lecture par les visiteurs. La fonction essentielle de l’environnement de publication consiste à traiter les demandes de lecture, sauf lorsque du contenu est déployé à partir de l’environnement de création. La charge du serveur exercée par le déploiement de contenu peut être ajustée sur des intervalles planifiés, ce qui n’est pas le cas dans le modèle de création sur place.

Le diagramme suivant illustre le fonctionnement du déploiement de contenu du point de vue de la topologie.

Ces modèles de création de contenu s’excluent mutuellement.

Bien que les sites de publication Internet et les sites de publication intranet puissent utiliser le modèle de déploiement de contenu ou le modèle de création sur place, celui-ci convient le mieux aux Wikis d’entreprise. En règle générale, un Wiki d’entreprise présente un volume d’opérations d’écriture supérieur au volume d’opérations de lecture, car une proportion plus importante d’utilisateurs peut modifier les pages. Les pages de Wiki d’entreprise diffèrent des pages d’article de publication et présentent des caractéristiques différentes en termes de performances.

Éléments à optimiser

Cette section présente des informations sur l’optimisation de votre environnement de gestion de contenu Web. Dans le cadre de l’optimisation de l’environnement, vous devez savoir comment gérer le débit, les goulots d’étranglement et la mise en cache.

Dans cette section :

• Le débit est la métrique clé

• Goulots d'étranglement et correction

• La mise en cache peut s'avérer utile

Le débit est la métrique clé

Le débit et le temps de réponse sont les métriques les plus importantes que vous devez optimiser lorsque vous planifiez la capacité pour un déploiement de gestion de contenu Web SharePoint Server 2010. Le débit représente le nombre d’opérations qu’une batterie de serveurs peut effectuer par seconde, mesuré en demandes par seconde.

Goulots d’étranglement et correction

Un goulot d’étranglement désigne la ressource système qui, du fait de son épuisement, empêche la batterie de serveurs de traiter des demandes supplémentaires. Le diagramme suivant montre les éléments d’une batterie de serveurs et les ressources qui peuvent constituer des goulots d’étranglement et qui doivent faire l’objet d’une surveillance.

Utilisation de l’UC des serveurs Web

L’UC des serveurs Web doit être le goulot d’étranglement d’une topologie correctement ajustée, car il s’agit du composant qu’il est possible de faire évoluer le plus facilement. L’équilibrage de charge répartit les demandes entre les serveurs Web et s’assure qu’aucun serveur n’est surutilisé par rapport aux autres.

Bien que des utilisateurs supplémentaires puissent visiter le site une fois que l’UC des serveurs Web est utilisée en totalité, le temps de réponse du serveur augmente pour ces utilisateurs. Ce comportement facilite la gestion des pics dans le volume de demandes. Toutefois, le maintien de la charge au-delà de la capacité d’une batterie de serveurs aboutit à un journal de demandes en souffrance trop important par rapport au seuil des demandes en attente. À ce stade, les serveurs Web ne gèrent pas les demandes et répondent par l’erreur HTTP 503. Dans l’illustration suivante, le temps de réponse du serveur diminue dès que le seuil des demandes en attente est atteint, car seules les erreurs HTTP sont traitées.

Les modifications suivantes sont illustrées dans ce diagramme :

1. Le temps de réponse augmente lorsque l’utilisation de l’UC des serveurs Web approche 100 %.

2. Dès que le seuil des demandes en attente est dépassé, le traitement des demandes supplémentaires se traduit par la génération d’erreurs.

Autres goulots d’étranglement

Si l’UC des serveurs Web n’est pas le goulot d’étranglement, les éléments suivants à analyser comme étant susceptibles de comporter des goulots d’étranglement sont la topologie de la batterie de serveurs, la configuration de la batterie de serveurs ou le contenu des pages fournies. Certains goulots d’étranglement potentiels dans ces éléments sont les suivants :

1. Réseau   Dans les situations de débit élevé, le réseau peut être saturé entre le serveur Web et le serveur de bases de données ou entre le serveur Web et les utilisateurs finaux. Pour éviter cette situation, configurez les serveurs Web de telle sorte qu’ils utilisent des cartes réseau de 2 gigabits.

2. UC du serveur de bases de données   Si l’UC du serveur de bases de données devient le goulot d’étranglement, l’ajout de serveurs Web à la batterie de serveurs ne peut pas augmenter le débit maximal que la batterie de serveurs peut prendre en charge. Un goulot d’étranglement affectant l’UC du serveur de base de données, mais pas les UC des serveurs Web, peut refléter deux situations :

   1. Des paramètres de cache mal optimisés ou des pages très lentes, notamment celles qui ne sont pas placées dans le cache de sortie. Cela se caractérise par une utilisation élevée de l’UC du serveur de bases de données, mais par un débit faible ou moyen et par une utilisation faible ou moyenne des serveurs Web.

   2. Le serveur de bases de données a peut-être atteint le niveau de capacité maximal pour le débit requis pour la batterie de serveurs. Cela se caractérise par une utilisation élevée de l’UC des serveurs Web et du serveur de bases de données lorsque le débit est élevé.

La mise en cache peut s’avérer utile

SharePoint Server 2010 utilise trois types de mise en cache. L’objectif commun de ces caches est d’améliorer l’efficacité en réduisant les appels à la base de données pour des données fréquemment demandées. Les demandes ultérieures d’une page peuvent être traitées à partir du cache du serveur Web, ce qui aboutit à une diminution significative de l’utilisation des ressources des serveurs Web et des serveurs de bases de données.

Les trois types de mise en cache sont les suivants :

• Cache de sortie   Ce cache stocke le contenu des pages demandées dans la mémoire du serveur Web. Pour plus d’informations sur le cache de sortie, voir Mise en cache de sortie et profils de cache (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x40C).

• Cache d’objets   Ce cache stocke des objets SharePoint, tels que des métadonnées d’élément de liste et Web, dans la mémoire du serveur Web. Pour plus d’informations sur le cache d’objets, voir Cache d’objets (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x40C).

• Cache disque pour les objets BLOB (Binary Large Object)   Ce cache stocke sur disque des fichiers image, son, vidéo et d’autres fichiers binaires volumineux. Pour plus d’informations sur le cache BLOB, voir Mise en cache sur disque pour les objets BLOB (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x40C).

Chacun de ces caches est important pour maintenir un débit élevé. Toutefois, la mise en cache de sortie a l’impact le plus important et est abordée en détail tout au long de cet article.

Résultats des tests et recommandations

Cette section présente des domaines spécifiques qui ont été testés et fournit des recommandations établies à l’issue de ces tests.

Dans cette section :

• Impact de l’activation du cache de sortie

• Utilisateurs anonymes et utilisateurs authentifiés

• Caractéristiques des opérations de lecture et d'écriture dans le cadre d'une montée en puissance parallèle

• Mises en garde concernant le cache de sortie

• Impact du volume de lectures sur l'UC et le temps de réponse

• Impact des opérations d'écriture sur le débit

• Impact du déploiement de contenu

• Impact de la capture instantanée de base de données pendant l'exportation à l'aide du déploiement de contenu

• Caractéristiques du contenu

Impact de l’activation du cache de sortie

Le cache de sortie est une fonctionnalité très utile pour optimiser une solution SharePoint Server 2010 pour de nombreuses opérations de lecture.

Dans le cadre de ces tests, afin que soit déterminé le taux de demandes par seconde maximal, le nombre d’utilisateurs actifs effectuant des demandes sur la batterie de serveurs a été augmenté jusqu’à ce que l’utilisation de l’UC du serveur de bases de données ou des serveurs Web ait atteint le niveau de 100 % et soit devenue un goulot d’étranglement. Le test a été mené sur des topologies de batterie de serveurs 1x1 (1 serveur Web et 1 serveur de bases de données), 2x1, 4x1 et 8x1 pour montrer l’impact de la montée en puissance parallèle des serveurs Web suivant différents taux d’accès au cache de sortie.

Taux d’accès au cache de sortie

Le taux d’accès au cache de sortie mesure les accès par rapport aux échecs d’accès au cache de sortie.

• Un accès au cache se produit lorsque le cache reçoit une demande pour des données d’objet qui sont déjà stockées dans le cache.

• Un échec d’accès au cache se produit lorsqu’une demande est reçue pour des données d’objet qui ne sont pas stockées dans le cache. Lorsqu’un échec d’accès au cache se produit, le cache essaie de stocker les données d’objet demandé afin que les demandes ultérieures pour ces données aboutissent à un accès au cache.

Une demande de page peut aboutir à un échec d’accès au cache pour plusieurs raisons.

• Les pages sont configurées pour ne pas utiliser le cache de sortie.

• Il s’agit de pages personnalisées, par exemple, de pages dont les données sont spécifiques à l’utilisateur actuel.

• Le délai de premier accès par clé de variante de cache de sortie a expiré.

• Le délai de premier accès après la mise en cache de contenu a expiré.

Le diagramme suivant montre l’effet de la mise en cache de sortie sur le débit maximal dans les batteries de serveurs comportant entre un et quatre serveurs Web et un serveur de bases de données.

Le tableau suivant répertorie les impacts du taux d’accès au cache de sortie sur les topologies de batterie de serveurs comportant entre un et quatre serveurs Web et un serveur de bases de données.

Impacts du taux d’accès au cache de sortie sur différentes topologies de batterie de serveurs

Taux d’accès au cache de sortie	Mesure	1x1	2x1	4x1
100 %	Taux de demandes par seconde maximal Utilisation de l’UC par SQL Server	3 463 0 %	7 331 0 %	11 032 0 %
95 %	Taux de demandes par seconde maximal Utilisation de l’UC par SQL Server	2 137 5,93 %	3 945 12,00 %	5 937 21,80 %
90 %	Taux de demandes par seconde maximal Utilisation de l’UC par SQL Server	1 518 7,12 %	2 864 14,40 %	4 518 28,00 %
50 %	Taux de demandes par seconde maximal Utilisation de l’UC par SQL Server	459 9,86 %	913 19,50 %	1 596 42,00 %
0 %	Taux de demandes par seconde maximal Utilisation de l’UC par SQL Server	172 9,53 %	339 19,00 %	638 36,30 %

Conclusions et recommandations pour l’impact de l’activation du cache de sortie

Des taux élevés d’accès au cache de sortie entraînent des augmentations significatives du taux de demandes par seconde maximal. Par conséquent, il est recommandé d’activer la mise en cache de sortie pour optimiser votre solution de publication SharePoint Server 2010. Vous pouvez configurer le cache de sortie dans la page Paramètres du cache de sortie pour la collection de sites. Pour plus d’informations, voir Améliorer le rendu des pages en configurant la mise en cache de sortie (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x40C) sur le site Web Office.Microsoft.com.

Dans les tests au cours desquels la mise en cache de sortie était activée, la première demande qui aboutissait à la mise en cache d’une page était exclue ; en d’autres termes, un certain pourcentage de pages est déjà stocké dans le cache. Lorsqu’un utilisateur demande pour la première fois une page qui n’est pas mise en cache, la page est ajoutée au cache. Si le cache a atteint ou approche le niveau de capacité maximal, il tronque les dernières données demandées.

Le taux d’accès au cache de 0 % simule dans un environnement la brève période au cours de laquelle le cache de sortie activé est rempli après avoir été vidé. Par exemple, cela s’observe chaque jour dans un environnement réel lors du recyclage du pool d’applications. Il est important d’appliquer à votre configuration matérielle une montée en puissance par unité ou parallèle correcte afin de faire face à la situation dans laquelle le taux d’accès au cache est de 0 % pendant la brève période entre le recyclage du pool d’applications et la demande et la mise en cache suivantes de pages. En outre, le taux d’accès au cache de 0 % simule un environnement dans lequel la mise en cache de sortie n’est pas activée.

Utilisateurs anonymes et utilisateurs authentifiés

Le test précédent suppose que toutes les demandes adressées au site sont réalisées par des lecteurs anonymes. Toutefois, dans votre site, une partie ou la totalité des utilisateurs peuvent être authentifiées. Un site de publication intranet d’entreprise et un contenu accessible uniquement aux membres d’un site Internet sont des exemples de scénarios de lecture authentifiée.

Grâce aux profils de cache de sortie, vous pouvez définir pour les utilisateurs authentifiés et pour les utilisateurs anonymes des comportements du cache de sortie spécifiques.

Profils de cache

Les profils de cache regroupent des paramètres que vous pouvez appliquer aux pages, aux éléments de page, aux types de contenu et aux niveaux d’échelle dans un déploiement de site. Un profil de cache définit les types de comportement de cache suivants :

• la durée de conservation des éléments dans le cache ;

• la stratégie de filtrage de sécurité ;

• l’expiration des paramètres, tels que la durée et les modifications ;

• les variantes du contenu mis en cache, par exemple, en fonction de l’autorisation utilisateur, des droits d’utilisateur et d’autres variables personnalisées.

Toute modification apportée à un profil de cache a un impact immédiat sur la totalité du contenu concerné sur le site. Vous pouvez définir différents profils de cache pour les utilisateurs anonymes et pour les utilisateurs authentifiés.

Pour les utilisateurs anonymes et pour les utilisateurs authentifiés ont été respectivement utilisés le profil de cache de sortie Internet public (purement anonyme) et le profil de cache de sortie Extranet (site publié).

Le graphique suivant montre l’impact du débit authentifié sur l’utilisation de l’UC du serveur de bases de données.

Le mode d’authentification utilisé était l’authentification de base Windows. Bien qu’il ne soit pas recommandé d’utiliser l’authentification de base Windows pour les sites Internet, cette méthode d’authentification a été sélectionnée afin que soit illustré un traitement minimal imposé par l’authentification. La taille de ce traitement varie en fonction du mécanisme d’authentification que vous utilisez. Lorsque vous testez votre déploiement, veillez à prendre en compte l’impact de votre mécanisme d’authentification. Pour plus d’informations sur les mécanismes authentifications pris en charge par SharePoint Server 2010, voir Planifier des méthodes d’authentification (SharePoint Server 2010).

Conclusions et recommandations pour les utilisateurs anonymes et les utilisateurs authentifiés

Les utilisateurs authentifiés connaissent des taux de demandes par seconde inférieurs et s’exposent à une moindre nécessité d’une montée en puissance parallèle, car le travail supplémentaire de validation des informations d’identification exerce une charge sur le serveur de bases de données. Comme l’ont montré les résultats des tests, le taux de demandes par seconde maximal observé lorsque les utilisateurs sont authentifiés est sensiblement inférieur à celui constaté dans le cas d’une batterie de serveurs avec accès anonyme.

Caractéristiques des opérations de lecture et d’écriture dans le cadre d’une montée en puissance parallèle

Nos tests ont été conçus de manière à enregistrer des écritures par heure. Dans cet article, une écriture représente la création et l’archivage d’une nouvelle page de publication ou la modification et l’archivage d’une page de publication existante.

Pour les tests suivants, des lecteurs ont été ajoutés au système jusqu’à ce que l’utilisation de l’UC des serveurs Web ait atteint approximativement 80-90 %, puis des opérations d’écriture ont été réalisées dans l’environnement à l’aide d’un délai artificiel. Le nombre total d’écritures par heure pour le test a été approximativement de 500. Nous avons utilisé un taux d’accès au cache de sortie de 90 % pour tous les tests. Nous avons réalisé le même test sur une batterie de serveurs 1x1, 2x1 et 4x1 et avons observé l’utilisation de l’UC de SQL Server et des serveurs Web en plus du débit de lecture globale pour chaque configuration. En outre, nous avons testé une configuration de lecture seule anonyme en guise de ligne de base et nous avons également testé une configuration avec des lecteurs authentifiés en utilisant l’authentification de base Windows.

Bien que l’UC des serveurs Web fût utilisée à hauteur de 100 % pendant les tests avec montée en puissance parallèle et lecture seule, nous avons maintenu l’utilisation de l’UC des serveurs Web entre 80 et 90 % pour les tests avec montée en puissance parallèle et opérations d’écriture. Nous avons opéré ainsi afin de laisser une marge de manœuvre pour une utilisation supplémentaire de l’UC pendant une activité d’écriture.

Le graphique suivant montre le taux global de demandes de lecture par seconde observé pendant chaque test. Le taux de demandes de lecture par seconde devient linéaire lorsque des serveurs Web sont ajoutés, même pendant une activité d’écriture. Toutefois, le taux de demandes par seconde affiche une perte lorsque des écritures sont incorporées.

L’utilisation de l’UC du serveur de bases de données a augmenté à mesure que le nombre de serveurs Web s’accroissait. Le graphique suivant montre la tendance de croissance de l’utilisation de l’UC de SQL Server dans les différentes configurations. Comme indiqué dans la section Utilisateurs anonymes et utilisateurs authentifiés plus haut dans cet article, l’authentification a une incidence sur l’utilisation de l’UC du serveur de bases de données et cela devient plus prononcé lorsqu’une activité d’écriture est ajoutée (ce qui a également un impact sur l’utilisation de l’UC du serveur de bases de données).

L’extrapolation de la tendance de l’utilisation de SQL Server montre que SQL Server devient le goulot d’étranglement lorsque la configuration compte six serveurs Web traitant des demandes de lecture authentifiées. Toutefois, dans le cas des lectures anonymes, la montée en puissance parallèle au profit d’un nombre plus élevé de serveurs Web est réalisable.

Il est important de garder à l’esprit que des facteurs supplémentaires dans un déploiement typique ont une incidence sur la charge exercée sur le serveur de bases de données et qu’il est important de tenir compte de ces facteurs lors de la planification de la capacité. Pour plus d’informations sur la détermination d’une zone verte pour une utilisation typique de l’UC du serveur de bases de données, voir Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Conclusions et recommandations pour les caractéristiques des opérations de lecture et d’écriture dans le cadre d’une montée en puissance parallèle

Nos données montrent que la montée en puissance parallèle du nombre de serveurs Web est une stratégie efficace pour augmenter le débit si le serveur de bases de données ne devient pas le goulot d’étranglement. En moyenne, la combinaison de tests de lectures anonymes avec écritures authentifiées a engendré une augmentation de 52 % de l’utilisation de l’UC des serveurs Web par rapport à une combinaison de tests de lectures anonymes sans écritures. En outre, les lectures authentifiées engendrent une charge supplémentaire significative sur SQL Server, car chaque demande entraîne des vérifications d’authentification supplémentaires, ce qui requiert un aller-retour vers SQL Server.

Le graphique suivant montre l’impact du débit sur l’utilisation de l’UC du serveur de bases de données.

Mises en garde concernant le cache de sortie

Si la seule préoccupation concernant la planification de la capacité était d’optimiser le taux de demandes par seconde, ces tests indiqueraient que le taux d’accès au cache optimal est de 100 %. Toutefois, il peut s’avérer impossible ou non souhaitable d’activer la mise en cache de sortie de tout ou partie des pages en raison des contraintes liées à la mémoire ou au caractère actuel des données.

Caractère actuel des données

Les données issues du cache de sortie risquent de ne pas contenir les mises à jour récemment apportées au contenu d’origine. Dans la source du déploiement de contenu ou, dans le cas des auteurs authentifiés, dans un scénario de création en production, il est possible que les auteurs souhaitent que les modifications les plus récentes apportées au contenu soient visibles immédiatement.

Cela est généralement facilité par la définition de la propriété Durée dans le profil de cache, qui spécifie la durée de conservation d’une page dans le cache de sortie avant son expiration. Lorsqu’une page expire, elle est supprimée du cache et une demande ultérieure aboutit à un échec d’accès au cache qui actualise le contenu de la page.

En outre, la propriété de profil de cache Rechercher les modifications peut être définie de manière à ce que le serveur compare l’heure de mise en cache d’une page et l’heure de la dernière modification du contenu d’une collection de sites. Une demande d’une page pour laquelle les horodatages ne correspondent pas entraîne une invalidation de cache pour toutes les pages de la collection de sites. Étant donné que la propriété Rechercher les modifications a une incidence sur toutes les pages d’une collection de sites, il est recommandé de n’activer cette option que dans le cadre d’une solution de création sur place authentifiée rarement mise à jour et fondamentalement statique. La combinaison de cette option avec une longue durée permet de fournir toutes les pages à partir du cache jusqu’à ce qu’une mise à jour du site soit réalisée.

Par défaut, la propriété Rechercher les modifications n’est pas activée. Cela signifie que le serveur Web fournit des données à partir du cache de sortie en réponse aux demandes d’une page qui n’a pas encore expiré, que la page ASPX d’origine sous-jacente ait été modifiée ou non.

Dans ce test, mené sur une batterie de serveurs 1x1, toutes les variables sont les mêmes que dans les tests présentés dans la section Caractéristiques des opérations de lecture et d'écriture dans le cadre d'une montée en puissance parallèle, à l’exception de la propriété Rechercher les modifications. Lorsque la propriété Rechercher les modifications est activée, le cache est vidé plus souvent, ce qui aboutit à une diminution du taux d’accès au cache de sortie.

Le graphique suivant montre l’impact de la propriété Rechercher les modifications sur le débit.

Il est déconseillé d’utiliser la propriété de profil de cache de sortie Rechercher les modifications, sauf dans des cas spécifiques. Un site qui utilise le modèle de création sur place et dont le contenu est rarement modifié peut tirer parti de ce paramètre dans le cas d’une configuration associant des utilisateurs authentifiés et une durée de mise en cache longue, mais il est fort probable que les autres types de sites connaissent une dégradation du taux de demandes par seconde.

Il est possible que des impératifs justifient que le contenu présentant un caractère urgent soit publié instantanément ou plus rapidement que ne le permettent les paramètres par défaut. Dans ce cas, vous devez diminuer la durée ou activer la mise en cache de sortie.

Conclusions et recommandations pour les mises en garde concernant le cache de sortie

La mise en cache de sortie ne résout pas tous les problèmes liés à la gestion de la capacité. Il existe certaines situations dans lesquelles la mise en cache de sortie est inadaptée et dont vous devez tenir compte lorsque vous activez le cache de sortie et configurez des profils de cache de sortie.

Impact du volume de lectures sur l’UC et le temps de réponse

Ce test a été mené sur une batterie de serveurs 1x1 avec accès anonyme et activation de la mise en cache de sortie.

Le graphique suivant montre l’impact du volume de lectures sur l’UC et le temps de réponse.

Conclusions et recommandations pour l’impact du volume de lectures sur l’UC et le temps de réponse

Comme indiqué dans la section Goulots d'étranglement et correction, le temps de réponse serveur demeure généralement constant jusqu’à ce que le serveur Web reçoive un volume de demandes suffisant pour que la totalité de son UC soit utilisée. Lorsque l’UC du serveur Web est entièrement utilisée, le temps de réponse augmente de manière significative. Toutefois, la batterie de serveurs est toujours en mesure de gérer un volume de demandes supplémentaire.

Impact des opérations d’écriture sur le débit

Le rapport entre les opérations de création et les opérations de modification est réparti de façon égale sur la durée des tests. Les valeurs d’écritures par heure ont été testées jusqu’à approximativement 500 opérations, car la création ou la modification de plus de 500 pages par heure reflète le fonctionnement de très peu de déploiements SharePoint. Le test n’a pas couvert les processus automatisés, tels que le déploiement de contenu, abordé dans la section Impact du déploiement de contenu. Ces opérations de création et de modification peuvent aboutir à plusieurs opérations SQL Server. Par conséquent, il est important de garder à l’esprit que les écritures mesurées dans ces tests ne sont pas réalisées au niveau de SQL Server, mais qu’elles sont plutôt représentatives d’une opération d’écriture du point de vue d’un utilisateur. Tous les tests de taux de demandes par seconde par rapport aux écritures par heure ont été menés sur une batterie de serveurs 1x1.

Nous avons d’abord ajouté des opérations de lecture au test jusqu’à ce que l’utilisation de l’UC du serveur Web se situe entre 60 et 80 % afin de laisser une mémoire tampon pour les pics de trafic, et nous avons conservé ce niveau d’utilisation moyen sur toute la durée du test. Ensuite, nous avons introduit des écritures à l’aide d’un délai artificiel pour contrôler le nombre d’opérations d’écriture. Toutefois, des pics d’utilisation accrue de l’UC de SQL Server et du serveur Web se sont produits pendant les écritures. Pour certains taux d’accès au cache, certains de ces pics ont dépassé le seuil d’un fonctionnement ordinaire, comme le montre le graphique suivant, sans que la moyenne s’écarte toutefois de la plage du fonctionnement ordinaire.

Comme le montre le graphique précédent, le débit présente une légère réduction lorsque des écritures sont ajoutées à l’environnement. Le graphique montre l’évolution du débit entre un scénario de lecture seule et un scénario combinant des opérations de lecture et approximativement 500 écritures par heure. Deux points de données ont été enregistrés pour chaque taux d’accès au cache de sortie. Par conséquent, la relation entre les points de données n’est pas nécessairement linéaire.

La réduction du pourcentage est d’autant plus prononcée que le taux d’accès au cache est faible, comme le montre le graphique suivant. Le taux global de demandes de lecture par seconde demeure étroitement lié au taux d’accès au cache, indépendamment des écritures.

Le graphique suivant montre que l’ajout d’écritures au système n’a pas entraîné une augmentation sensible de l’utilisation de l’UC du serveur de bases de données. Notez que l’axe vertical représente, en pourcentage, la capacité de l’UC sur une échelle allant de 0 à 10.

Une charge supplémentaire sur SQL Server a naturellement été observée pendant les opérations d’écriture. Toutefois, l’augmentation la plus importante s’élève à 2,06 %, ce qui est insignifiant. L’utilisation moyenne de l’UC du serveur de bases de données est demeurée inférieure à 10 % pendant tous les tests. Ce test a été réalisé sur une batterie de serveurs 1x1. L’utilisation de l’UC du serveur de bases de données augmente lorsque le nombre de serveurs Web fait l’objet d’une montée en puissance parallèle. Cet aspect est abordé plus en détail dans la section Caractéristiques des opérations de lecture et d'écriture dans le cadre d'une montée en puissance parallèle.

L’utilisation de l’UC du serveur Web a également été mesurée pendant les tests. Le graphique suivant montre que l’utilisation moyenne de l’UC du serveur Web est demeurée dans la plage 60-80 % tout au long de la durée des tests, même lorsque le nombre d’écritures par heure approchait la valeur 500.

Toutefois, l’utilisation de l’UC mesurée réelle connaît des pics lorsque les écritures se produisent, comme le montre le graphique suivant. En général, ces pics de l’UC ne représentent pas un problème. L’objectif de la zone verte est de permettre à l’UC d’absorber certains pics de charge du processeur. En outre, lorsque des serveurs Web sont ajoutés, l’impact des pics est réparti sur ces serveurs, ce qui réduit l’incidence produite sur chaque UC de serveur Web. Toutefois, vous devez avoir conscience que les pics de ce type sont normaux dans un déploiement réel ; l’activité d’écriture n’est pas distribuée de manière uniforme, bien que cela se produise généralement de façon sporadique.

Un taux d’accès au cache de 90 % est très faible pour un déploiement typique. La plupart des déploiements SharePoint Server 2010 avec de nombreuses opérations de lecture présentent un taux d’accès au cache de sortie supérieur ou égal à 95 %.

Conclusions et recommandations pour l’impact des opérations d’écriture sur le débit

Les données présentées indiquent que les opérations d’écriture n’affectent pas de manière significative le débit global du système pour les lecteurs. Vous devez prendre acte du fait que l’activité d’écriture peut entraîner des pics d’utilisation de l’UC et vous devez planifier votre configuration typique en conséquence. Une stratégie pour niveler ces pics consiste à réaliser une montée en puissance parallèle de manière à ce que la configuration comporte plusieurs serveurs Web. Cela présente deux avantages :

• La charge d’écriture est répartie sur plusieurs serveurs Web, ce qui atténue les pics globaux.

• Le taux de demandes de lecture par seconde augmente, notamment lorsque les taux d’accès au cache de sortie sont élevés.

Impact du déploiement de contenu

Au lieu d’utiliser le modèle de création sur place, dans lequel la modification et la lecture sont effectuées dans un même environnement, une autre solution consiste à scinder l’environnement unique en deux environnements distincts — un environnement de création et un environnement de production — et à utiliser le déploiement de contenu pour copier du contenu depuis l’environnement de création vers l’environnement de production.

Dans cette configuration, l’environnement de production peut se caractériser par une activité d’écriture réduite, voire nulle, sauf lorsque le déploiement de contenu importe du contenu. Pour ces tests, des lectures ont été ajoutées jusqu’à ce que l’utilisation de l’UC des serveurs Web ait atteint la plage 70-80 %. Ensuite, le travail de déploiement de contenu a exporté 10 sites comportant 500 pages chacun depuis la collection de sites de création sous la forme d’un package et a importé ce package dans la collection de sites de publication. La taille du package déployé est supérieure à la taille généralement observée dans les environnements réels afin que l’extension de la durée du travail de déploiement de contenu permette de voir les résultats des tests. Pour plus d’informations sur les caractéristiques du contenu déployé, voir la section Jeu de données.

Une fois l’exportation terminée, nous avons importé le contenu dans une collection de sites distinct, opération au cours de laquelle nous avons mesuré la charge du serveur d’applications et de SQL Server, en plus du débit. Le test d’importation a été mené pour plusieurs taux d’accès au cache de sortie différents.

L’observation essentielle est que l’importation n’a qu’un impact mineur sur le taux de demandes de lecture par seconde global, comme le montre le graphique suivant. En outre, nous avons constaté que l’importation n’a eu aucun impact significatif sur l’utilisation de l’UC des serveurs Web, comme le montrent les tableaux suivants, quel que soit le taux d’accès au cache. Toutefois, l’impact a été plus notable sur l’UC de SQL Server, comme le montre le graphique suivant. Cela est normal, car le serveur de bases de données connaît une charge supplémentaire lorsqu’il reçoit du contenu. Toutefois, l’utilisation de l’UC de SQL Server est demeurée inférieure à 12 % pour tous les taux d’accès au cache testés, même pendant l’importation.

Les tableaux suivants indiquent l’impact sur l’utilisation de l’UC des serveurs Web et du serveur de bases de données de l’importation à l’aide du déploiement de contenu.

Impact sur l’utilisation de l’UC des serveurs Web de l’importation à l’aide du déploiement de contenu

Accès au cache	100 %	99 %	98 %	95 %	90 %	50 %	0 %
Ligne de base	72,32 %	73,26 %	71,28 %	73,53 %	71,79 %	68,05 %	63,97 %
Avec importation	70,93 %	74,45 %	69,56 %	74,12 %	70,95 %	67,93 %	63,94 %

Impact sur l’utilisation de l’UC du serveur de bases de données de l’importation à l’aide du déploiement de contenu

Accès au cache	100 %	99 %	98 %	95 %	90 %	50 %	0 %
Ligne de base	1,19 %	1,64 %	2,01 %	3,00 %	3,73 %	5,40 %	6,82 %
Avec importation	6,03 %	6,82 %	6,97 %	7,96 %	8,52 %	10,29 %	10,56 %

Conclusions et recommandations pour l’impact du déploiement de contenu

Les résultats de nos tests montrent que la réalisation des opérations de déploiement de contenu pendant des opérations de site ordinaires ne pose pas de problèmes significatifs en ce qui concerne les performances. Ces résultats indiquent qu’il n’est pas absolument nécessaire de déployer du contenu pendant des périodes de faible trafic pour réduire au minimum l’impact de l’opération sur les performances globales et que les heures de déploiement peuvent être établies essentiellement en fonction des besoins de l’entreprise plutôt que de contraintes liées aux performances.

Impact de la capture instantanée de base de données pendant l’exportation à l’aide du déploiement de contenu

Dans SharePoint Server 2010, le déploiement de contenu peut être configuré de manière à créer une capture instantanée de la base de données de contenu source avant d’exporter du contenu à partir de celle-ci. Cela a pour effet de protéger le processus d’exportation de toute activité de création susceptible de se produire pendant l’exportation. Toutefois, une capture instantanée peut avoir une incidence sur les performances d’écriture du serveur de bases de données, car elle agit comme un multiplicateur pour les écritures. Par exemple, si vous disposez de deux captures instantanées d’une base de données source et que vous effectuez des opérations d’écriture sur celle-ci, le serveur de bases de données copie les données existantes sur chaque capture instantanée, puis écrit les nouvelles données dans la base de données source. Cela signifie qu’une seule écriture dans la base de données source implique en réalité trois écritures : une dans la base de données source et une autre pour chaque capture instantanée de base de données.

Pour déterminer l’impact d’une capture instantanée sur l’environnement de création, nous avons mesuré le taux de demandes d’écriture par seconde, le temps de réponse et l’utilisation de l’UC des serveurs Web, du serveur de bases de données et du serveur d’applications pendant une opération d’exportation parallèlement à laquelle avait lieu une activité d’écriture. Les tableaux suivants indiquent les résultats.

Impact des captures instantanées de base de données pendant le déploiement de contenu

Métrique	4 écritures par heure, sans captures instantanées	4 écritures par heure, avec captures instantanées
Taux de demandes d’écriture par seconde	0,2	0,16
Temps de réponse	0,13	0,15
Pourcentage d’utilisation de l’UC des serveurs Web	0,42 %	0,27 %
Pourcentage d’utilisation de l’UC du serveur d’applications	8,67 %	8,98 %
Pourcentage d’utilisation de l’UC du serveur de bases de données	3,34 %	2,41 %

Impact des captures instantanées de base de données pendant le déploiement de contenu

Métrique	8 écritures par heure, sans captures instantanées	8 écritures par heure, avec captures instantanées
Taux de demandes d’écriture par seconde	0,44	0,44
Temps de réponse	0,13	0,13
Pourcentage d’utilisation de l’UC des serveurs Web	0,61 %	0,73 %
Pourcentage d’utilisation de l’UC du serveur d’applications	14,6 %	12 %
Pourcentage d’utilisation de l’UC du serveur de bases de données	7,04 %	7,86 %

Conclusions et recommandations pour l’impact de la capture instantanée de base de données pendant l’exportation à l’aide du déploiement de contenu

Les résultats de nos tests n’ont montré aucun impact significatif des captures instantanées de base de données sur les différents points de données mesurés. La totalité de l’écart enregistré tombait dans la marge d’erreur. Cela confirme qu’il est possible d’utiliser des captures instantanées de base de données sans que cela pose de problème particulier du point de vue des performances.

Caractéristiques du contenu

Les tests ont été menés sur un jeu de données unique créé pour répondre à un ensemble spécifique de questions. Votre jeu de données sera différent et évoluera au fil du temps. Cette section s’attache à déterminer dans quelle mesure les caractéristiques du contenu, telles que le nombre de pages dans la bibliothèque de pages et les fonctionnalités incluses dans les pages, peuvent fournir des indications qui facilitent la prise de décisions quant à la gestion de la capacité.

Nombre de pages

Le taux de demandes par seconde maximal suivant de nombreuses tailles de bibliothèque de page a été testé. Ce test a été mené dans une topologie 4x1 avec désactivation de la mise en cache de sortie et accès anonyme. La taille de toutes les pages était de 42 Ko (page non compressée) et 12 Ko (page compressée). Le tableau suivant montre les résultats du test.

Impact du nombre de pages de bibliothèque sur le taux de demandes par seconde

Nombre de pages	3	1 000	20 000
Taux de demandes par seconde maximal	860	801	790

L’augmentation du nombre de pages jusqu’à 20 000 n’a pas eu d’impact significatif sur le taux de demandes par seconde maximal.

Champ de liste de choix à plusieurs valeurs

Un champ de liste de choix à plusieurs valeurs est une colonne dans une liste qui référence un ou plusieurs éléments appartenant à une autre liste, à l’image de colonnes utilisant des métadonnées gérées d’entreprise. Ces champs sont généralement utilisés comme mots clés de recherche pour une page et ne sont pas nécessairement restitués. Dans certains cas, tels que les Wikis d’entreprise, il est opportun de restituer ces valeurs de champ dans le contenu des pages. Par exemple, les pages peuvent être classées en différentes catégories lorsqu’elles sont créées (telles que Nouvelles internationales, Reportage à caractère social et Sports sur un site de News) et la page maître comprend un espace réservé qui indique à l’utilisateur les catégories qui ont été associées à la page à l’aide de balises.

Les champs de liste de choix à plusieurs valeurs entraînent l’extraction d’une plus grande quantité de données chaque fois qu’une page est demandée. Par conséquent, la présence de nombreux champs de liste de choix à plusieurs valeurs sur une page peut avoir une incidence sur les performances.

Le graphique suivant montre l’impact des champs de liste de choix à plusieurs valeurs sur le débit.

Le graphique suivant montre l’impact des champs de liste de choix à plusieurs valeurs sur l’utilisation des ressources de la batterie de serveurs.

Le taux de demandes par seconde maximal diminue à mesure que le nombre de champs de liste de choix à plusieurs valeurs augmente, en raison de l’impact sur le réseau entre le serveur Web et le serveur de bases de données.

Impact de la création de rapports d’utilisation

La création de rapports d’utilisation est un service qui permet aux administrateurs de surveiller les statistiques relatives à l’utilisation de leurs sites. Pour plus d’informations sur la création de rapports d’utilisation, voir Configurer la collecte des données d’utilisation et d’intégrité (SharePoint Server 2010).

Nous avons testé l’impact des travaux du minuteur de création de rapports d’utilisation sur le taux de demandes par seconde maximal dans une batterie de serveurs 1x1. Le tableau suivant indique les résultats.

Impact de la journalisation de l’utilisation sur les performances (taux de demandes par seconde)

	Base de données d’utilisation activée	Base de données d’utilisation désactivée	Différence
Cache de sortie activé	3 459	3 463	4
Cache de sortie désactivé	629	638	9

Les résultats montrent que l’activation de la journalisation de l’utilisation n’a pas d’impact significatif sur le taux de demandes par seconde dans un scénario de lecture seule.

À propos des auteurs

Joshua Stickler est responsable de programme pour SharePoint Server 2010 au sein de Microsoft.

Tyler Butler est responsable de programme pour SharePoint Server 2010 au sein de Microsoft.

Zhi Liu est ingénieur de développement et de test de logiciels pour SharePoint Server 2010 au sein de Microsoft.

Cheuk Dong est ingénieur de développement et de test de logiciels pour SharePoint Server 2010 au sein de Microsoft.

Philippe Flamm est ingénieur de développement et de test de logiciels pour SharePoint Server 2010 au sein de Microsoft.