Estimer les performances et les capacités pour la gestion de contenu web (SharePoint Server 2013)

 

**Sapplique à :**SharePoint Server 2013

**Dernière rubrique modifiée :**2017-08-25

Résumé : Découvrez comment déterminer le nombre et les types d’ordinateurs dont vous avez besoin pour publier du contenu et gérer le contenu web dans SharePoint Server 2013.

Les entreprises utilisent souvent des SharePoint Server 2013 pour publier du contenu que l’accès des utilisateurs anonymes sur un site Internet ou authentifiés l’accès sur un site intranet. Cet article contient les données de capacité et de performances pour vous aider à planifier le nombre d’ordinateurs à utiliser et les types d’ordinateurs qui sont nécessaires pour publier du contenu et gestion du contenu web dans SharePoint Server 2013.

Dans cet article :

• Introduction

• Informations préalables

• Publication intersites avec navigation gérée

• Publication avec création sur place

Publication SharePoint comprend différents types de sites et méthodes associées qui sont disponibles pour chaque site de publication. Les fonctionnalités de publication de SharePoint Server 2013 sont conçues pour aider à créer une marque, intranet, sites Internet et extranet. Pour plus d’informations sur la publication de SharePoint Server 2013, consultez Vue d’ensemble de la publication sur les sites Internet, intranet et extranet dans SharePoint Server.

Introduction

Cet article traite des scénarios suivants :

• Site Internet

  Fournit des informations aux clients, partenaires, investisseurs et employés potentiels. Ce type de site permet aux utilisateurs Internet anonymes de trouver des informations sur une entreprise. En général, ces sites sont personnalisés et la société contrôle étroitement le contenu.

• Site Internet d’entreprise

  Assure la promotion des produits et services qu’une société propose à ses clients. Ces sites peuvent afficher un catalogue des produits proposés par la société.

• Site intranet

  Une entreprise publie ce type de site en interne au sein d’une organisation. Ces sites permettent le partage d’informations pour les utilisateurs authentifiés et les sociétés gèrent étroitement le site pour en restreindre l’accès ou l’ouvrent à tous les utilisateurs internes.

• Site extranet

  Fournit un accès à un contenu ciblé pour des employés, des partenaires et des clients distants. Ces sites peuvent donner accès à des bases de connaissances utilisant du contenu créé marqué par des métadonnées pour le classement des articles. Les utilisateurs peuvent rechercher ou naviguer vers des informations spécifiques, telles que des articles sur la résolution des problèmes et de support technique.

La publication entre collections de sites et le composant WebPart de recherche de contenu permettent de réutiliser le contenu dans des collections de sites dans ces scénarios. Ces fonctions et fonctionnalités ont une incidence sur la manière de planifier la capacité. Pour plus d’informations, voir Vue d’ensemble de la publication intersites dans SharePoint Server.

Notes

La publication entre collections de sites est appelée publication intersites dans cet article.

Navigation gérée dans SharePoint Server 2013 fournit pilotée par classification de navigation pour un site de publication. Pour plus d’informations, consultez Vue d’ensemble de la navigation gérée dans SharePoint Server.

Les données de capacité et de performances figurant dans cet article se présentent en deux parties. La première partie correspond à la nouvelle méthode de publication intersites et la navigation gérée. La seconde partie utilise le modèle avec création sur place.

Notes

Les scénarios abordés dans cet article peuvent être mis en place à la fois par la publication intersites et par les sites avec création sur place. Les fonctionnalités de navigation gérée et de publication intersites ne dépendent pas l’une de l’autre et peuvent être utilisées de façon indépendante.

Les deux mesures clés suivantes sont abordées dans les modèles utilisés dans cet article :

• Débit

  Nombre de pages consultées par seconde que le site peut supporter

• Temps de réponse du serveur

  Temps nécessaire au serveur pour traiter une requête. Ce délai a un impact sur le délai d’affichage de la page sur l’écran de l’utilisateur. Les temps de réponse du serveur fournis dans ce document sont les 95è et 50è centiles. Ces valeurs signifient, respectivement, que 95 % et 50 % des requêtes sont plus rapides que la valeur fournie. Ces valeurs sont mesurées à l’aide de la « Durée » enregistrée dans la base de données d’utilisation SharePoint pour une requête donnée.

• Actualisation du contenu

  Le temps nécessaire pour que la mise à jour d’un élément soit répercutée dans les résultats de recherche est une considération importante à prendre en compte lorsque vous utilisez des scénarios de publication intersites.

Les scénarios présentés dans cet article utilisent les deux états suivants :

• Zone verte

  Utilisation des serveurs inférieure à 60 %. Cette zone doit être la zone cible pour la plupart du temps d’exécution des serveurs.

• Zone rouge

  Utilisation des serveurs proche du maximum. Il s’agit d’un état où le site SharePoint doit gérer une charge plus élevée que d’habitude. Lorsque le serveur est en zone rouge, le temps de réponse du serveur commence à augmenter car celui-ci tente de répondre à toutes les requêtes entrantes.

Informations préalables

Avant de lire cet article, assurez-vous que vous comprenez les concepts essentiels de la gestion de la capacité SharePoint Server 2013. Les articles suivants vous aident à en savoir plus sur l’approche recommandée pour la gestion de la capacité et de fournir le contexte pour vous aider à comprendre comment utiliser de manière efficace les informations dans cet article.

De nouvelles fonctionnalités supplémentaires ayant une incidence sur les scénarios de publication d’un point de vue fonctionnel n’apparaissent pas dans cet article. Ces scénarios comprennent les canaux des appareils, l’optimisation SEO, les modèles d’affichage et les règles de requête. En outre, la fonctionnalité et la configuration d’un site de publication intersites ne sont pas décrites en détail dans cet article. Pour plus d’informations, voir Planifier la publication intersites dans SharePoint Server et Configurer les solutions de gestion de contenu web de SharePoint Server.

Pour obtenir plus d’informations sur la capacité et les performances et ainsi mieux comprendre les données fournies dans cet article, voir Planifier les performances de planification dans Microsoft SharePoint Server 2013.

Publication intersites avec navigation gérée

Cette section fournit nos données de tests pour deux domaines : la publication intersites avec des utilisateurs anonymes et la publication avec création sur place.

Publication intersites avec utilisateurs anonymes

Les résultats des tests présentés dans cette section sont basés sur un modèle de site de publication intersites de base en vue de fournir des instructions de planification de la capacité. Lorsque vous planifiez un déploiement SharePoint pour que des utilisateurs anonymes accèdent à un site web, utilisez ces instructions et ajustez vos spécifications de déploiement en conséquence.

Le scénario utilisé lors de nos tests utilise la fonctionnalité de publication intersites. Il fournit du contenu dans plusieurs collections de sites désignées comme catalogues, puis ce contenu est analysé par l’application de service de recherche SharePoint. Les composants WebPart qui utilisent la technologie de recherche, par exemple, le composant WebPart de recherche de contenu et le composant WebPart de réutilisation d’un élément de catalogue, affichent du contenu sur les pages d’un autre site. Pour plus d’informations, voir Vue d’ensemble de la publication intersites dans SharePoint Server.

Les caractéristiques suivantes ont été utilisées dans le site de modèles qui a été créé pour tester la publication intersites :

• Le site web de publication comprend environ 5 millions de pages ou d’éléments.

• Les éléments sont associés à environ 1 000 catégories.

• Le contenu se trouve dans d’autres collections de sites dans un ou plusieurs catalogues.

• Le site web utilise la navigation gérée qui est liée aux catégories auxquelles les éléments sont associés.

• Pour la topologie de déploiement de référence décrite plus loin dans cette liste, en moyenne 80 pages sont consultées par seconde sur le site. En période de pointe, le nombre de pages consultées par seconde peut atteindre 100. Pour accroître cette valeur de débit, ajoutez des ordinateurs à la topologie. Pour réduire cette valeur de débit, supprimez des ordinateurs de la topologie.

• Le robot de recherche exécute des analyses continues pendant 1 minute et cinq mises à jour par seconde sont effectuées vers le catalogue.

• Le site web présente les modèles de page et de trafic suivants :

  • La page d’accueil avec trois composants WebPart de recherche de contenu et un composant WebPart de panneau d’affinement reçoit 15 % du trafic.

  • Les pages de catégorie avec trois composants WebPart de recherche du contenu, un composant WebPart de panneau d’affinement de taxonomie et un composant WebPart de panneau d’affinement reçoivent 45 % du trafic.

  • Les pages d’élément de catalogue avec un composant WebPart de réutilisation d’un élément de catalogue et deux composants WebPart de recherche de contenu reçoivent 40 % du trafic.

• Chaque composant WebPart de recherche de contenu et de réutilisation d’un élément de catalogue émet une requête synchrone.

• Les pages d’élément de catalogue n’utilisent pas le cache de résultats de recherche anonyme car ils ne reçoivent que peu de trafic.

• Le cache BLOB (Binary Large Object) est activé sur la batterie de serveurs pour les ordinateurs qui sont exécutés en tant que serveurs web frontaux.

La topologie de serveurs que nous avons utilisée pour tester ce scénario est présentée dans le diagramme suivant :

Figure 1 : Topologie de serveurs de laboratoire de test

• un ordinateur qui héberge SQL Server avec toutes les bases de données utilisées par SharePoint

• un ordinateur qui héberge les applications de service SharePoint, le service de cache distribué et les rôles de traitement de l’analyse de recherche et d’administration de la recherche

• un ordinateur qui héberge les rôles de robot de recherche et de traitement de contenu (CPC)

• trois ordinateurs qui hébergent des nœuds d’index de recherche avec traitement des requêtes et qui sont utilisés en tant que serveurs web frontaux

Notes

Pour ce test, les ordinateurs sont des ordinateurs physiques qui exécutent Windows Server 2008 R2. Reportez-vous à la planification de la capacité de recherche et à Planification de la capacité pour SharePoint Server 2013 pour obtenir des conseils sur l’utilisation des ordinateurs virtuels et de Windows Server 2012.

Important

La configuration pour notre topologie de laboratoire de test est optimisée pour les scénarios de publication basée sur la recherche. Cette configuration est différente des types de collaboration des déploiements SharePoint. Par exemple, notre configuration utilise des serveurs web frontaux en tant que serveurs d’index de recherche pour obtenir les meilleures performances.
Dans notre topologie de laboratoire de test, il est apparu que l’ordinateur qui héberge le serveur d’applications était sous-exploité. Par conséquent, nous avons placé le service de cache distribué sur ce serveur d’applications plutôt que sur un serveur dédié. Vous pouvez choisir d’héberger le service de cache distribué sur un serveur dédié dans votre environnement. Pour obtenir les meilleures performances, nous vous recommandons de ne pas héberger le service de cache distribué sur un serveur web frontal qui a le rôle de serveur d’index de recherche.

Rapports de laboratoire de test

Nous avons utilisé la topologie de la figure 1 pour notre laboratoire de test avec des ordinateurs physiques et un test de charge Visual Studio Team System (VSTS). Pour plus d’informations, voir Visual Studio Team System. Les caractéristiques techniques des ordinateurs de test figurent dans les tableaux suivants :

Notes

Nous n’avons pas utilisé la mise en cache du navigateur ou les requêtes dépendantes, telles que des images ou des fichiers JavaScript, dans nos tests VSTS. Le nombre de requêtes dépendantes peut varier considérablement en fonction de la personnalisation de votre site de publication
Les pages que nous avons utilisées dans nos tests ont exécuté près de 50 requêtes pour les types de requêtes de temps de chargement de page 1 (PLT1) (cache du navigateur vide) et environ 3 requêtes pour les types de requêtes PLT2 (requêtes ultérieures avec des résultats provenant du cache du navigateur). En règle générale, le cache BLOB SharePoint traite des requêtes pour ces éléments et n’a pas d’impact significatif sur les valeurs de performance.

Composants serveur	Serveurs exécutant SharePoint Server
Processeurs	Processeurs Intel Xeon @2,27 GHz (2 processeurs, 8 cœurs au total, 16 threads au total)
Mémoire RAM	24 Go
Système d’exploitation	Windows Server 2008 R2 Enterprise SP1, 64 bits
Taille du lecteur SharePoint	200 Go sur disque interne
Stockage utilisé pour l’index de recherche	78 Go sur une baie de disques externe (2 x Dell PERC H700 SCSI)
Nombre de cartes réseau	2
Vitesse des cartes réseau	1 gigabit
Authentification	Aucune - Anonyme
Version logicielle	SharePoint Server 2013

Composants serveur	Serveurs de base de données
Processeurs	Processeurs Intel Xeon L5520 @2,27 GHz (2 processeurs, 8 cœurs au total, 16 threads au total)
Mémoire RAM	24 Go
Système d’exploitation	Windows Server 2008 R2 Enterprise SP1, 64 bits
Baie de disques	2 x Dell H700 SCSI
Nombre de cartes réseau	2
Vitesse des cartes réseau	1 gigabit
Authentification	NTLM
Version logicielle	Microsoft SQL Server 2008 R2 SP1

Voici les résultats d’une analyse de 10 minutes :

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS (simulation d’utilisateurs simultanés) :	60	100
50è centile du temps de réponse du serveur* :	219 ms	302 ms
95è centile du temps de réponse du serveur* :	412 ms	635 ms
Nombre de pages consultées par seconde :	78	98

Il s’agit d’un scénario de publication intersites qui affiche du contenu à partir de l’index de recherche. Il peut être intéressant d’examiner le nombre de requêtes traitées par les serveurs hébergeant des requêtes de recherche, ainsi que le nombre de requêtes traitées par le cache de résultats anonymes. Dans ce modèle, le cache de résultats anonymes traite environ 60 % des requêtes. Le cache de résultats anonymes est abordé plus loin dans cet article.

Fonctionnalités testées	Zone verte	Zone rouge
Nombre total de requêtes par seconde :	235	294
Requêtes traitées à partir du cache de résultats anonyme :	145	182
Requêtes traitées à partir de la recherche :	90	112

Les valeurs d’utilisation maximale de la mémoire et moyenne du processeur pour ces ordinateurs pendant l’exécution des tests sont les suivantes :

Fonctionnalités testées	Zone verte	Zone rouge
Utilisation moyenne du processeur (nœuds d’index de recherche par serveur web frontal)	59 %	80 %
Utilisation moyenne du processeur (serveur d’applications, y compris le cache distribué)	8 %	9 %
Utilisation moyenne du processeur (nœuds CPC de recherche)	5 %	5 %
Utilisation moyenne du processeur (SQL Server)	Non mesurée	Non mesurée
Utilisation maximale de la mémoire (nœuds d’index de recherche par serveur web frontal)	7,5 Go	7,5 Go
Utilisation maximale de la mémoire (serveur d’applications, y compris le cache distribué)	10,1 Go	10 Go
Utilisation maximale de la mémoire (nœuds CPC de recherche)	6,5 Go	6,5 Go

L’utilisation de la mémoire peut varier légèrement car plusieurs travaux du minuteur sont exécutés sur le serveur lors d’une utilisation normale. Les nœuds de serveur web frontal/d’index utilisaient 12 Go de mémoire après une série de tests de deux semaines exécutée avec une charge soutenue.

Comment les composants WebPart de recherche affichent du contenu sur des pages de publication intersites

Si une page de publication contient un composant WebPart de recherche, tel que le composant WebPart de recherche de contenu, le navigateur commence à traiter la page avant que la requête de recherche soit terminée. Cela permet d’améliorer la latence perçue de la page. Une fois la requête de recherche terminée, les résultats complets de la recherche sont envoyés au navigateur et la connexion au navigateur est fermée. Les utilisateurs peuvent penser que les résultats de la recherche sont chargés de façon asynchrone, mais les requêtes sont toujours émises par le serveur lorsque la page fait l’objet d’une requête.

Il existe un mode asynchrone distinct pour le composant WebPart de recherche de contenu, dans lequel les requêtes sont émises par le navigateur après le chargement d’une page.

Effet des modifications de charge sur votre site de publication intersites

Nous avons fait varier le nombre d’utilisateurs VSTS (semblable au nombre d’utilisateurs simultanés qui accèdent au site) utilisés dans le test de charge. Le graphique suivant indique que le temps de réponse du serveur augmente à mesure que la charge augmente et qu’il existe une augmentation incrémentielle du nombre de pages traitées par seconde. Il est recommandé de maintenir le temps de réponse du serveur en dessous de 750 ms pour s’assurer que les utilisateurs bénéficient d’une expérience réactive avec le déploiement SharePoint.

Figure 2 : Graphique représentant le débit et le temps de réponse du serveur avec différentes charges

Mise à l’échelle votre site de publication intersites

S’il est prévu que le déploiement SharePoint reçoive plus ou moins de trafic que le cas de référence décrit auparavant, vous devrez peut-être modifier le nombre d’ordinateurs exécutés avec le rôle de serveur web frontal et d’index sur la batterie de serveurs pour gérer ce trafic. Le graphique suivant présente les résultats de la mise à l’échelle du même site de publication intersites qui possède différents modèles de charge et un nombre variable d’ordinateurs utilisés en tant que serveurs web frontaux avec des nœuds d’index, en commençant avec un seul ordinateur dans le rôle de serveur web frontal avec des nœuds d’index et en montant jusqu’à six ordinateurs :

Figure 3 : Mise à l’échelle de votre déploiement

Dans chacune des configurations, la charge a été ajustée pour que les valeurs de temps de réponse du serveur soient similaires aux valeurs de référence indiquées dans la section précédente.

En raison de l’augmentation du nombre d’ordinateurs, la topologie commence à devenir trop complexe pour les avantages qu’elle apporte. Chaque ordinateur supplémentaire fournit un débit inférieur par rapport aux ordinateurs qui se trouvent déjà dans l’environnement. Ces chiffres sont indiqués pour illustrer le modèle pour la mise à l’échelle. Les performances réelles varient en fonction du type de déploiement SharePoint.

Instructions pour la planification de votre site

Pour la plupart de nos tests de performances, nous utilisons le déploiement décrit dans les sections précédentes. Les instructions figurant dans la liste suivante sont destinées à vous aider à prendre les décisions de planification de capacité appropriées si vos déploiements sont différents de ceux utilisés dans notre laboratoire de test.

• Généralement, plus le nombre d’éléments dans l’index de recherche est important, plus la latence est élevée. Chaque partition d’index peut contenir jusqu’à 10 millions d’éléments. En règle générale, les sites web ont rarement plus de 10 millions d’éléments à afficher. Par conséquent, ils n’ont besoin que d’une partition comme dans la topologie décrite auparavant. Vous pouvez utiliser plus de partitions d’index soit pour héberger plus de 10 millions d’éléments, soit pour avoir des partitions d’index plus rapides, plus petites et en plus grand nombre. Si vous prévoyez d’utiliser plusieurs partitions d’index, voir Mettre à l’échelle la recherche pour les sites Internet dans SharePoint Server pour dimensionner correctement votre topologie de recherche.

• Chaque contrôle ou composant WebPart ajouté à une page (ou à une mise en page) ajoute une charge supplémentaire qui pèse sur le temps de réponse du serveur pour la page.

• Évitez d’utiliser plus de cinq contenu de WebParts recherche synchrone ou élément de catalogue réutiliser des WebParts sur une page. Lors du traitement d’une demande pour une page, SharePoint Server 2013 s’exécute jusqu'à cinq requêtes en parallèle et renvoie les résultats. Si plus de cinq requêtes sont sur une page, SharePoint Server 2013 exécute les cinq premières requêtes avant de commencer à exécuter l’ensemble suivant de cinq requêtes. Si les pages nécessitent plus de cinq de WebParts recherche contenu ou élément de catalogue réutiliser des WebParts, vous pourriez exécuter les WebParts de recherche contenu supplémentaire en mode asynchrone ou utiliser des règles de requête et de blocs de résultat.

• Les composants WebPart de recherche de contenu et les composants WebPart de réutilisation d’un élément de catalogue disposent d’un mode asynchrone. S’il est utilisé, la requête associée au composant WebPart est exécutée après le chargement de la page par le navigateur. Utilisez ce mode pour les requêtes lentes afin que le reste de la page apparaisse plus rapidement sur l’écran des utilisateurs. Dans tous les autres cas, nous vous recommandons d’utiliser des requêtes synchrones pour obtenir les meilleurs temps de chargement de page.

• Un composant WebPart de panneau d’affinement qui possède un grand nombre d’affinements entraîne l’augmentation du temps de traitement d’une requête. Vous pouvez modifier le nombre d’affinements à afficher pour une propriété gérée. Pour plus d’informations, voir Configurer des raffineurs et navigation à facettes dans SharePoint Server.

• Si vous utilisez le composant WebPart de panneau d’affinement de taxonomie et que vous avez une importante hiérarchie de nœuds de navigation, le temps de traitement de requête augmente. Nous vous recommandons de ne pas utiliser le composant WebPart de panneau d’affinement de taxonomie dans une page qui comprend plus de 200 nœuds de navigation en dessous d’elle dans la hiérarchie. Un nombre important de nœuds de navigation peut entraîner le ralentissement des temps de réponse du serveur et la réduction du débit.

• Si vous devez concevoir un déploiement SharePoint pour une haute disponibilité, vous devez ajouter les éléments suivants :

  • Un ordinateur supplémentaire exécuté avec les applications de service dans des rôles de cache distribué si l’ordinateur existant n’est pas disponible

  • Des ordinateurs supplémentaires pour supporter la charge en cas d’indisponibilité d’un ou de plusieurs serveurs web frontaux avec nœuds d’index

  • Un ordinateur supplémentaire dans les rôles CPC pour s’assurer que les mises à jour sont toujours répercutées dans votre site si l’ordinateur qui a le rôle CPC n’est pas disponible

  • Une topologie SQL Server qui continue à traiter les requêtes de base de données si l’un des serveurs de base de données n’est pas disponible

Vitesse d’analyse de recherche et actualisation du contenu

Nous avons également réalisé des tests pour le processus qui permet de mettre à jour le contenu du catalogue en cours de publication. Nous avons ensuite calculé le temps écoulé avant l’apparition d’un élément mis à jour sur le site de publication. Lors de nos expériences, nous avons réalisé cinq mises à jour de catalogue par seconde et défini une durée d’une minute pour les analyses continues du catalogue. Le temps moyen observé d’apparition des modifications sur le site de publication était d’environ deux minutes. Le temps minimum était d’à peine moins d’une minute et le temps maximal de trois minutes. Aucune variation significative de ces valeurs n’a été observée lors de l’augmentation du nombre d’ordinateurs exécutés avec le rôle CPC.

Toutefois, pour l’analyse complète du catalogue, une augmentation du nombre d’ordinateurs exécutés avec le rôle CPC a permis d’augmenter le nombre d’éléments traités par seconde. Le graphique suivant montre la relation entre les éléments traités par seconde et le nombre d’ordinateurs de la batterie avec le rôle CPC. Ces données de tests ont été obtenues avec un déploiement SharePoint différent de celui utilisé dans les tests de référence. Les résultats s’appliquent aux déploiements SharePoint car l’ajout de nœuds CPC entraîne une réduction des temps d’analyse complète.

Figure 4 : Effet des ordinateurs de traitement de contenu (CPC) sur une analyse complète

Par conséquent, si des analyses complètes plus rapides sont nécessaires pour vos catalogues, vous pouvez augmenter le nombre d’ordinateurs utilisant le rôle CPC dans votre déploiement.

Charge sur l’application de service de métadonnées gérées

Nos tests montrent que les scénarios de publication impliquant des sites qui utilisent la navigation gérée ne disposent pas d’exigences significatives pour la mémoire ou le processeur sur l’application de service de métadonnées gérées. Pour un déploiement comme celui décrit auparavant, l’application de service de métadonnées gérées peut être exécutée sur un ordinateur qui exécute d’autres applications de service SharePoint. La fonctionnalité de navigation gérée se connecte une fois à l’application de service lors de la réception de la première requête d’un site. Les requêtes ultérieures utilisent les valeurs mises en cache par les serveurs web frontaux. Par conséquent, il n’y a pas de charge sur l’application de service de métadonnées gérées lorsque les serveurs web frontaux traitent les requêtes.

Cache de résultats de recherche anonyme

Le cache de résultats de recherche anonyme stocke les résultats d’une requête, les données d’affinement pour la requête et les tables de résultats supplémentaires qui sont renvoyés à partir du service de cache distribué SharePoint. Chaque entrée de cache dépend des paramètres d’une requête, tels que l’ordre de tri des résultats, les affinements demandés et les règles de reclassement dynamique. Le cache a une incidence sur toutes les requêtes gérées par une application web, y compris les requêtes des composants WebPart de recherche et les requêtes des clients CSOM. Pour plus d’informations, voir Vue d’ensemble de l’architecture de recherche dans SharePoint Server et Mettre à l’échelle la recherche pour les sites Internet dans SharePoint Server.

Ce cache n’est pas utilisé pour les requêtes authentifiées pour des raisons de sécurité.

Pour obtenir de meilleurs résultats, il est recommandé de configurer le service de cache distribué pour qu’il s’exécute uniquement sur l’ordinateur qui exécute les applications de service SharePoint. Le service de cache distribué ne doit pas être exécuté sur les ordinateurs qui se trouvent dans les rôles de serveur web frontaux.

Par défaut, le cache de résultats de recherche anonyme actualise les éléments toutes les 15 minutes. Vous pouvez utiliser Microsoft PowerShell pour configurer la durée de cache sur l’application web où le cache est configuré :

$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache> 
$webapp.Update()

Pour que les résultats de recherche soient actualisés plus souvent que la configuration par défaut, diminuez la valeur. Cette action augmente le nombre de requêtes que le service de recherche devra traiter.

Nous vous recommandons de toujours utiliser le cache sur les pages de publication qui reçoivent un trafic intense, par exemple, la page d’accueil et les pages de catégorie d’un site qui utilisent des composants WebPart de recherche. La mise en cache pour les pages d’élément de catalogue est déconseillée. En effet, une page d’élément de catalogue individuelle est consultée beaucoup moins souvent qu’une page d’accueil et, par conséquent, le stockage de l’élément dans le cache peut ne pas s’avérer véritablement utile.

Lors de la désactivation du cache de résultats de recherche anonyme dans notre environnement de test qui a les mêmes modèles de charge, le temps de réponse du serveur a considérablement augmenté et le débit, c’est-à-dire le nombre de pages consultées par seconde, a diminué. Voici un graphique illustrant cette relation :

Figure 5 : Effet du cache de résultats de recherche anonyme

Par défaut, les composants WebPart de recherche de contenu sont configurés pour utiliser le cache de résultats de recherche anonyme. Les composants WebPart de réutilisation d’un élément de catalogue, utilisés sur les pages d’élément de catalogue, ne sont pas configurés pour l’utiliser car ces pages présentent généralement des modèles d’accès peu intenses.

Pour configurer le comportement de mise en cache d’un composant WebPart individuel afin qu’il utilise (ou qu’il n’utilise pas) le cache de résultats de recherche anonyme, définissez la valeur de la sous-propriété « TryCache » dans la propriété DataProviderJSON du composant WebPart. Si la valeur est « true », la requête utilise le cache. Si la valeur est « false », la requête n’utilise pas le cache pour les requêtes de recherche anonyme.

Effet du cache de sortie

La mise en cache de sortie est un moyen efficace pour réduire la charge sur les SharePoint Server 2013 dans les scénarios de publication. Pour plus d’informations sur le fonctionnement du Cache de sortie dans cet article, reportez-vous à la section mise en cache de sortie et de profils de Cache.

Pour un déploiement SharePoint, la mise en cache de sortie peut permettre de réduire la charge sur les bases de données de contenu SharePoint et l’application de service de recherche. Voici quelques exemples de situations :

• Vous recevez beaucoup de trafic sur certaines pages.

• Vous recevez beaucoup de trafic sur les bases de données de contenu SharePoint.

• Le niveau d’utilisation des processeurs des ordinateurs qui traitent les requêtes de recherche est élevé.

Nous vous recommandons d’utiliser la mise en cache de sortie pour les pages très populaires de votre site, telles que la page d’accueil ou les pages de catégorie de niveau supérieur du site et certaines pages d’élément qui reçoivent beaucoup de trafic.

Important

SharePoint Server 2013 est un problème connu lorsque le contenu de WebParts recherche également contient des pages ayant la sortie mise en cache. Pour éviter ce problème dans votre déploiement, vous devez installer mise à jour de SharePoint Server 2013 : le 12 mars 2013,.

Le graphique suivant présente quelques résultats de notre environnement de test dans lequel la mise en cache de sortie a été utilisée sur la page d’accueil et sur les pages de catégorie qui reçoivent 60 % du trafic du site.

Figure 6 : Effet de la mise en cache de sortie pour la page d’accueil et les pages de catégorie

Notes

Les composants WebPart de recherche de contenu peuvent être exécutés en mode asynchrone. La mise en cache de sortie ne s’applique pas à la charge provenant des composants WebPart de recherche de contenu asynchrones.

Traitement d’analyse de l’utilisation

Pour disposer d’informations concernant l’analytique d’utilisation prêt à l’emploi, SharePoint Server 2013 traite les informations contenues dans la base de données d’utilisation. Dans notre topologie Analytique de traitement se produit sur le nœud qui contient le nœud Administration de la recherche, service de Cache distribué et autres applications de service. Pour plus d’informations, consultez Vue d’ensemble du traitement de l’analyse dans SharePoint Server

Nous avons pris certaines mesures de temps de traitement en utilisant le site de publication de site à site que nous avons utilisé dans nos tests antérieures d’analytique. Nous avons mesuré le temps que SharePoint Server 2013 nécessaire pour traiter une grande quantité d’événements click sur les pages du site. Ces résultats sont à partir d’un site de publication de site à site, ils s’appliquent également aux sites qui utilisent la méthode de publication d’auteur en place.

Pour les tests de traitement d’analyse de l’utilisation, les clics fictifs suivants ont été générés, chaque jour pendant une semaine :

• 27,5 millions de clics répartis sur 3 millions d’éléments de liste et entre 400 000 utilisateurs.

  La distribution de Zipf a été utilisée de sorte à affecter plus d’événements à certains éléments et utilisateurs et moins à d’autres.

Au total, 7,5 millions de clics ont été générés par jour ; un scénario simulant plusieurs modèles de trafic générés par plusieurs utilisateurs pour le site.

Nous avons lancé les séries d’analyses à sept reprises pour simuler une semaine de trafic. Nous avons exécuté le travail d’analyse de l’utilisation chaque jour pour les données accumulées sur six jours. Puis, nous avons mesuré le temps pris par le septième jour. Le septième jour est le jour qui prend le plus de temps à traiter car les éléments de la semaine complète sont traités et le graphique des relations est mis à jour. Le temps d’exécution et l’utilisation du disque du jour 8 sont semblables à celles du jour 1.

Le traitement d’analyse n’a pas eu d’incidence significative sur l’ordinateur sur lequel il était exécuté. Les requêtes ont continué à être traitées et l’actualisation du contenu a été maintenue sur le site basé sur la recherche.

Les résultats sont résumés dans le tableau suivant :

Jour des tests	Mise à jour du graphique des relations	Temps d’exécution (heures)	Utilisation totale maximale du disque	Utilisation maximale du disque pour l’analyse d’utilisation
Jour 1	Non	02:35		2,65 Go
Jour 2	Non	02:43
Jour 3	Non	03:23
Jour 4	Non	04:39
Jour 5	Non	06:08
Jour 6	Non	07:35
Jour 7	Oui	08:29	82,4 Go	4 Go

Le graphique suivant affiche le nombre d’heures d’exécution en fonction des jours :

Figure 7 : Nombre d’heures d’exécution par jour

Publication intersites avec utilisateurs authentifiés

Publication de SharePoint est utilisée couramment sur les sites intranet. À l’aide de SharePoint Server 2013, ces sites peuvent également être alimentés par publication de cross-site. Les sections suivantes montrent certaines distinctions importantes à considérer lorsque vous planifiez pour un site de publication intersite utilise les utilisateurs authentifiés. Autres que les exceptions mentionnées dans les sections suivantes, les règles qui s’appliquent aux sites accessibles de manière anonyme s’appliquent toujours à des sites authentifiés l’accès.

Absence de cache des résultats de recherche anonyme

Comme mentionné plus haut à la section Cache de résultats de recherche anonyme, ce cache s’applique uniquement aux utilisateurs qui accèdent au site SharePoint de façon anonyme. Comparé aux sites consultés de façon anonyme qui utilisent le cache de résultats de recherche anonyme, la capacité de débit des sites demandant l’authentification des utilisateurs est considérablement plus faible. En général, les sites intranet reçoivent rarement des charges aussi élevées que celles mentionnées à la section précédente (jusqu’à 100 pages consultées/seconde). Toutefois, il s’agit d’une distinction importante à prendre en compte.

L’utilisation du cache de sortie peut en partie compenser l’absence de cache de résultats de recherche anonyme pour ces scénarios. Pour les sites de publication intersites pour lesquels on s’attend à ce que plusieurs pages soient consultées par seconde, envisagez d’activer le cache de sortie.

Important

L’activation d’un paramètre des composants WebPart de recherche de contenu permet de les exécuter en mode asynchrone. Le cache de sortie ne s’applique pas à la charge provenant des composants WebPart de recherche de contenu asynchrones.

Index de recherche plus important

Selon la taille de l’entreprise qui déploie SharePoint Server 2013, déploiements intranet pour SharePoint Server 2013 indexe en général plus grand nombre de documents. Cela signifie que la topologie de recherche requise pour indexer ces documents sera différente par rapport à la topologie décrite dans la section précédente. Reportez-vous à la Planifier la recherche dans SharePoint Server à la taille appropriée pour votre déploiement SharePoint.

Publication avec création sur place

Cette section fournit des conseils et des résultats qui utilisent SharePoint Server 2013, mais elle ne détaille pas les différentes fonctionnalités qui affectent la planification de la capacité. Pour plus d’informations dans ce domaine, consultez Planification de la gestion de contenu web dans SharePoint Server.

Publication avec création sur place et utilisateurs anonymes

Pour nos tests, nous avons utilisé un site web présentant les caractéristiques suivantes :

• Il contient près de 20 000 pages d’articles réparties en 20 dossiers de 1 000 pages chacun dans 50 sites dans une collection de sites unique.

• Le site utilise la navigation structurée.

• De manière générale, sur le site, au minimum 50 à 100 pages sont consultées par seconde.

• Les modèles de trafic présentent la combinaison de pages suivante :

  • 20 pages contenant un composant WebPart de requête de contenu unique qui émet des requêtes de bases de données de contenu de différentes étendues (20 % du trafic)

  • 30 pages comprenant plusieurs composants WebPart de requête de contenu qui émettent des requêtes de bases de données de contenu de différentes étendues (30 % du trafic)

  • 1 600 articles avec 40 Ko de texte et deux images (réception de 50 % du trafic)

Le diagramme suivant présente la topologie de serveur recommandée :

Figure 8 : Topologie de test de publication avec création sur place

• 1 ordinateur hébergeant SQL Server

• 1 ordinateur hébergeant des applications de service SharePoint en tant que serveur web frontal

Résultats de laboratoire de test

Nous avons utilisé la topologie présentée dans le diagramme précédent dans notre laboratoire de test en prenant des ordinateurs physiques et un test de charge Visual Studio Team System.

Le tableau suivant présente les caractéristiques techniques utilisées dans les ordinateurs testés :

Composants serveur	Serveurs SharePoint
Processeurs	Processeurs Intel Xeon @2,33GHz (2 processeurs, 8 cœurs au total, 8 threads au total)
Mémoire RAM	24 Go
Système d’exploitation	Windows Server 2008 R2 Enterprise, 64 bits
Nombre de cartes réseau	2
Vitesse des cartes réseau	1 Gbit/s
Authentification	Aucune - Anonyme
Type d’équilibrage de charge	Équilibrage de la charge logicielle Windows
Version logicielle	SharePoint Server 2013

Composants serveur	Serveur de base de données
Processeurs	Processeurs Intel Xeon MP7130M @2,79 GHz (2 processeurs, 8 cœurs au total, 16 threads au total)
Mémoire RAM	16 Go
Système d’exploitation	Windows Server 2008 R2 Enterprise, 64 bits
Baie de disques	2 x Dell PERC 5/E
Nombre de cartes réseau	1
Vitesse des cartes réseau	1 gigabit ou Gbit/s
Authentification	NTLM
Version logicielle	Microsoft SQL Server 2008 R2 SP1

Le tableau suivant illustre les résultats d’une analyse de 10 minutes :

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS :	5	15
50è centile du temps de réponse du serveur :	69 ms	112 ms
95è centile du temps de réponse du serveur :	92 ms	221 ms
Nombre de pages consultées par seconde :	57	93
Utilisation moyenne du processeur (serveur d’applications et serveur web frontal)	55	97
Utilisation moyenne du processeur (SQL Server)	7	9
Utilisation maximale de la mémoire (serveur d’applications et serveur web frontal)	8,9 Go	8,9 Go

Effet du cache de sortie

La mise en cache de sortie est un moyen efficace pour réduire la charge sur les SharePoint Server 2013 dans les scénarios de publication. Pour plus d’informations, consultez Planifier la mise en cache et les performances dans SharePoint Server.

Le tableau suivant présente nos résultats pour une analyse de 10 minutes avec le cache de sortie activé et un taux d’accès de 90 % :

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS :	5	15
50è centile du temps de réponse du serveur :	2 ms	2 ms
95è centile du temps de réponse du serveur :	74 ms	88 ms
Nombre de pages consultées par seconde :	190	418
Utilisation moyenne du processeur (serveur d’applications et serveur web frontal)	58	85
Utilisation moyenne du processeur (SQL Server)	5	7
Utilisation maximale de la mémoire (serveur d’applications et serveur web frontal)	9,2 Go	9,4 Go

Les résultats des tests montrent que l’utilisation de la mise en cache de sortie peut augmenter considérablement le débit d’un site de publication SharePoint et diminuer le temps de réponse du serveur. Concernant les requêtes traitées à partir du cache de sortie, le délai de réponse est presque instantané.

Le graphique suivant résume les résultats des tests :

Figure 9 : Effet de la mise en cache de sortie avec un taux d’accès au cache de 90 %

Effet de la navigation gérée

Dans SharePoint Server 2013, les sites de publication peuvent également utiliser navigation gérée. Pour plus d’informations sur la façon de configurer ce paramètre, consultez Vue d’ensemble de la navigation gérée dans SharePoint Server.

Nous avons effectué la même série de tests pour notre site de test utilisant la navigation gérée que celle effectuée pour les sites utilisant la navigation structurée. Les tests indiquent que les performances sont sensiblement les mêmes, que les sites utilisent la navigation gérée ou la navigation structurée.

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS :	5	15
50è centile du temps de réponse du serveur :	70 ms	111 ms
95è centile du temps de réponse du serveur :	95 ms	215 ms
Nombre de pages consultées par seconde :	56	94
Utilisation moyenne du processeur (serveur d’applications et serveur web frontal)	54	97
Utilisation moyenne du processeur (SQL Server)	7	9
Utilisation maximale de la mémoire (serveur d’applications et serveur web frontal)	8 Go	8 Go

Le graphique suivant illustre les différents types de navigation pour le même site :

Figure 10 : Comparaison entre la navigation gérée et la navigation structurée

Effet de l’ajout d’ordinateurs (mise à l’échelle)

Si vous trouvez que vous avez besoin de plus de débit d’un déploiement SharePoint, mise à l’échelle (augmenter le nombre d’ordinateurs qui hébergent les SharePoint Server 2013 ) est une option à envisager. Le graphique suivant montre le débit augmente à mesure que nous ajouter d’autres ordinateurs de la batterie de serveurs :

Figure 11 : Effet de l’ajout de serveurs web frontaux sur le débit

Dans nos tests, nous avons augmenté la charge sur le serveur exécutant SharePoint Server 2013 pour chaque ordinateur qui a été ajoutée afin que les temps de réponse du serveur ont environ les mêmes (environ 11 millisecondes pour la zone verte, environ 250 millisecondes pour la zone rouge).

Sites de publication avec création sur place et utilisateurs authentifiés

La fonctionnalité de publication SharePoint est couramment utilisée pour l’intranet avec accès authentifié des utilisateurs aux sites. Cette section présente les tests avec des utilisateurs authentifiés, ainsi que les effets.

Le tableau suivant présente les résultats des tests des sites de publication avec création sur place consultés par des utilisateurs authentifiés à l’aide d’une authentification basée sur les revendications avec NTLM. Le matériel utilisé pour ces tests est identique à celui utilisé pour les tests décrits à la section précédente.

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS :	5	15
50è centile du temps de réponse du serveur :	76 ms	107 ms
95è centile du temps de réponse du serveur :	103 ms	194 ms
Nombre de pages consultées par seconde :	54	100
Utilisation moyenne du processeur (serveur d’applications et serveur web frontal)	50	97
Utilisation moyenne du processeur (SQL Server)	6	9
Utilisation maximale de la mémoire (serveur d’applications et serveur web frontal)	9,5 Go	9,5 Go

En se basant sur les chiffres des temps de réponse du serveur et du débit, il n’existe pas de différence significative entre les requêtes anonymes et les requêtes authentifiées.

Le graphique suivant illustre les différents types de requêtes pour le même site :

Figure 12 : Comparaison entre les requêtes anonymes et les requêtes authentifiées

Effet du cache de sortie dans les scénarios avec requêtes authentifiées

Les requêtes authentifiées envoyées au serveur nécessitent un aller-retour vers la base de données de contenu pour s’assurer que le compte qui accède au contenu dispose des autorisations pour le consulter. Par conséquent, les caractéristiques de performances de mise en cache de sortie des sites authentifiés sont différentes de celles des sites anonymes.

Le tableau suivant présente les résultats reçus pour une analyse de 10 minutes avec le cache de sortie activé et un taux d’accès au cache de 90 % :

Fonctionnalités testées	Zone verte	Zone rouge
Nombre d’utilisateurs VSTS :	6	18
50è centile du temps de réponse du serveur :	17 ms	29 ms
95è centile du temps de réponse du serveur :	87 ms	118 ms
Nombre de pages consultées par seconde :	114	236
Utilisation moyenne du processeur (serveur d’applications et serveur web frontal)	50	97
Utilisation moyenne du processeur (SQL Server)	7	10
Utilisation maximale de la mémoire (serveur d’applications et serveur web frontal)	9,9 Go	10 Go

Le graphique suivant résume ces résultats :

Figure 13 : Effet de la mise en cache de sortie authentifiée

See also

Planification de la gestion de contenu web dans SharePoint Server
Configurer les solutions de gestion de contenu web de SharePoint Server
Administrer la gestion de contenu web de SharePoint Server
Configure cache settings for a web application in SharePoint Server
Planifier la mise en cache et les performances dans SharePoint Server