Estimer les performances et les capacités pour la gestion de contenu web (SharePoint Server 2013)
S’APPLIQUE À :
2013 
2016 2019 Subscription Edition SharePoint dans Microsoft 365
Les entreprises utilisent souvent SharePoint Server 2013 pour publier du contenu auquel des utilisateurs anonymes ont accès sur un site Internet ou auquel des utilisateurs authentifiés ont accès sur un site intranet. Cet article contient des données de capacité et de performances qui vous aideront à planifier le nombre et le type d'ordinateurs nécessaires pour publier du contenu et gérer du contenu web dans SharePoint Server 2013.
Dans la publication SharePoint, plusieurs types de sites de publication et de méthodes associées sont disponibles pour chaque site. Les fonctionnalités de publication de SharePoint Server 2013 sont conçues pour vous permettre de créer des sites Internet, intranet et extranet personnalisés. Pour plus d’informations sur la publication SharePoint Server 2013, voir Vue d’ensemble de la publication sur Internet, intranet et sites 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.
La navigation gérée dans SharePoint Server 2013 permet une navigation basée sur la taxonomie pour un site de publication. Pour plus d'informations, voir 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 demande, ce qui affecte le temps nécessaire à l’utilisateur pour afficher la page. Les temps de réponse du serveur que nous fournissons dans ce document sont les 95e et 50e centiles. Ces valeurs signifient que 95 % et 50 % des demandes sont plus rapides que la valeur fournie, respectivement. Nous mesurons ces valeurs à l’aide de la « Durée » enregistrée dans la base de données d’utilisation SharePoint pour une demande 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 clés qui sous-tendent la gestion de la capacité dans SharePoint Server 2013. Les articles suivants vous permettront d'en savoir plus sur l'approche recommandée de la gestion de la capacité et vous fournit des éléments de contexte pour comprendre comment utiliser efficacement les informations figurant 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 des solutions de gestion de contenu web dans SharePoint Server.
Pour plus d’informations sur la capacité et les performances afin de mieux comprendre les données de cet article, voir Planification des performances dans 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.
Importante
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, nous avons appris que l’ordinateur qui héberge le serveur d’applications était sous-utilisé. 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 effectué près de 50 types de requêtes de temps de chargement de page 1 (PLT1) (cache de navigateur vide) et environ 3 requêtes pour les types de requêtes PLT2 (requêtes suivantes avec les résultats 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 | Aucun - 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 Recherche, tel que le composant WebPart Recherche de contenu, le navigateur commence à traiter la page avant la fin de la requête de recherche. Cela améliore la latence perçue de la page. Une fois la requête de recherche terminée, les résultats complets de la requête 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 manière asynchrone. Toutefois, les requêtes sont toujours émises à partir du serveur pendant la demande de la page.
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 nombres sont fournis pour afficher le modèle de scale-out. Les performances réelles changent en fonction de la façon dont le déploiement SharePoint est généré.
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 envisagez d’utiliser plusieurs partitions d’index, reportez-vous à Mettre à l’échelle la recherche de 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 composants WebPart de recherche de contenu ou de réutilisation d'un élément de catalogue synchrones sur une page. Lors du traitement d'une requête pour une page, SharePoint Server 2013 exécute déjà cinq requêtes en parallèle et renvoie les résultats. Si plus de cinq requêtes se trouvent sur une page, SharePoint Server 2013 exécute les cinq premières requêtes, puis la série suivante de cinq requêtes. S'il est nécessaire que des pages comprennent plus de cinq composants WebPart de recherche de contenu ou de réutilisation d'un élément de catalogue, vous pouvez exécuter les composants WebPart de recherche de contenu supplémentaires en mode asynchrone ou utiliser des règles de requête et des blocs de résultats.
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 affinements et la 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 Mise à l’échelle de la recherche de 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 du 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 important. La page d’accueil du site et les pages de catégorie qui utilisent des composants WebPart de recherche sont des exemples pour ces types de pages. Nous vous déconseillons de mettre en cache les pages d’éléments de catalogue. Étant donné qu’une page d’élément de catalogue individuelle est accessible beaucoup moins fréquemment qu’une page d’accueil et qu’il n’est peut-être pas utile de stocker l’élément dans le cache.
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 non) le cache des résultats de la recherche anonyme, définissez la valeur de la sous-propriété « TryCache » dans la DataProviderJSON propriété 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 permet de réduire de manière efficace la charge sur SharePoint Server 2013 dans les scénarios de publication. Pour plus de détails sur le fonctionnement du cache de sortie dans cet article, voir Mise en cache de sortie et 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.
Importante
Il existe un problème connu dans SharePoint Server 2013 lorsque la mise en cache de sortie est activée pour des pages qui contiennent également des composants WebPart de recherche de contenu. Pour éviter ce problème dans votre déploiement, installez la mise à jour SharePoint Server 2013 du 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 obtenir des informations sur les analyses de l'utilisation prêtes à être utilisées, SharePoint Server 2013 traite les informations présentes dans la base de données d'utilisation. Dans notre topologie, le traitement d'analyse se fait sur le nœud qui contient le nœud d'administration de la recherche, le service de cache distribué et d'autres applications de service. Pour plus d’informations, voir Vue d’ensemble du traitement analytique dans SharePoint Server
Nous avons relevé des mesures de temps de traitement d'analyse à l'aide du site de publication intersites utilisé dans les tests précédents. Nous avons mesuré le temps que SharePoint Server 2013 met pour traiter un nombre important de clics sur les pages du site. Même si ces résultats proviennent d'un site de publication intersites, ils s'appliquent également aux sites utilisant la méthode de publication avec création sur 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
La publication SharePoint est couramment utilisée sur les sites intranet. À l'aide de SharePoint Server 2013, ces sites peuvent également utiliser la publication intersites. Les sections suivantes rappellent des distinctions importantes à prendre en compte lors de la planification d'un site de publication intersites demandant l'authentification des utilisateurs. Hormis les exceptions mentionnées dans les sections suivantes, les règles qui s’appliquent aux sites dont l’accès est anonyme s’appliquent également aux sites demandant l’authentification des utilisateurs.
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.
Importante
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
En fonction de la taille de l'entreprise qui déploie SharePoint Server 2013, les déploiements intranet pour SharePoint Server 2013 permettent généralement d'indexer un plus grand nombre de documents. Ainsi, la topologie de recherche requise pour indexer ces documents est différente de la topologie décrite à la section précédente. Reportez-vous à Planifier la recherche dans SharePoint Server pour dimensionner votre déploiement SharePoint de manière appropriée.
Publication avec création sur place
Cette section fournit des instructions et des résultats qui utilisent SharePoint Server 2013, mais elle ne détaille pas les différentes fonctionnalités qui ont une incidence sur la planification de la capacité. Pour plus d’informations sur cette zone, voir 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 | Aucun - 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 permet de réduire de manière efficace la charge sur SharePoint Server 2013 dans les scénarios de publication. Pour plus d'informations, voir 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 la navigation gérée. Pour plus d’informations sur la configuration, voir Vue d’ensemble de la navigation managé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 constatez que vous avez besoin de plus de débit à partir d’un déploiement SharePoint, la montée en charge (augmentation du nombre d’ordinateurs hébergeant SharePoint Server 2013) est une option à envisager. Le graphique suivant montre que l'augmentation du débit est liée à l'ajout d'ordinateurs à 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 ajouté afin que les temps de réponse du serveur soient à peu près identiques (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
Voir aussi
Concepts
Planification de la gestion de contenu web dans SharePoint Server
Configurer des solutions de gestion de contenu web dans SharePoint Server
Configurer les paramètres de cache pour une application web dans SharePoint Server
Planifier la mise en cache et les performances dans SharePoint Server