Estimer les besoins en performances et capacité pour la recherche SharePoint Server 2010

 

S’applique à : SharePoint Server 2010

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

Résumé : Cet article fournit des informations sur la planification de la capacité pour différents déploiements de la recherche Microsoft SharePoint Server 2010, y compris pour des batteries de serveurs SharePoint Server 2010 petites, moyennes ou grandes.

Cet article fournit des informations sur la planification de la capacité pour le déploiement de la recherche SharePoint Server 2010 dans des environnements de collaboration. Il inclut les informations suivantes pour trois exemples de configuration de batterie de serveurs de recherche :

• Caractéristiques de l’environnement de test (matériel, topologie de batterie et configuration)

• Charge de travail utilisée pour la génération de données, y compris le nombre et la classe d’utilisateurs, ainsi que les caractéristiques d’utilisation de la batterie de serveurs

• Jeu de données de batterie de serveurs de test, y compris contenu et taille des bases de données

• Données de performances et d’intégrité spécifiques à l’environnement testé

Cet article contient également des données de test courantes et des recommandations quant à la manière de déterminer le matériel, la topologie et la configuration nécessaires pour déployer un environnement similaire et d’optimiser l’environnement pour une capacité et des caractéristiques de performances appropriées.

La recherche SharePoint Server 2010 offre un ensemble plus riche de fonctionnalités et un modèle topologique plus souple que les versions antérieures. Avant d’utiliser cette architecture pour fournir aux utilisateurs des fonctionnalités et des possibilités de traitement plus puissantes, vous devez étudier avec soin l’impact sur les performances et la capacité de la batterie de serveurs.

Après avoir lu ce document, vous saurez comment effectuer les opérations suivantes :

• Définir les objectifs de performances et de capacité de l’environnement

• Planifier le matériel requis pour prendre en charge le nombre et le type d’utilisateurs, et les fonctionnalités que vous comptez déployer

• Concevoir la topologie physique et logique pour une fiabilité et une efficacité optimales

• Tester, valider et monter en puissance l’environnement pour atteindre les objectifs en matière de performances et de capacité

• Surveiller les indicateurs clés de l’environnement.

Pour lire cet article, vous devez maîtrisiez les concepts suivants :

• Capacity management and sizing for SharePoint Server 2010

• Gestion de la capacité de SharePoint Server 2010 : Limitations et frontières logicielles

• Disponibilité

• Redondance

• Contenu spécifique de base de données

Vue d’ensemble de la planification

Les scénarios de cet article décrivent des batteries de serveurs de test petite, moyenne et grande, en partant d’hypothèses qui peuvent vous aider à planifier la capacité correcte pour la batterie. Les tailles de ces batteries sont des approximations basées sur les hypothèses suivantes :

• Les référentiels analysés sont principalement du contenu SharePoint Server.

• La grande majorité des requêtes utilisateur peuvent être trouvées dans le même tiers de l’index. Cela signifie que la plupart des utilisateurs interrogent les mêmes termes.

• Les paramètres de métadonnées par défaut sont utilisés, ce qui garantit que la base de données de propriétés ne s’accroît pas trop vite.

• Dans les batteries de serveurs moyennes et grandes, des serveurs d’analyse cibles dédiés (serveurs Web frontaux) existent et peuvent servir du contenu aux composants d’analyse de ces batteries de recherche.

• Les mesures effectuées sur ces batteries peuvent varier en fonction des conditions environnementales et réseau, et présentent jusqu’à 10 % de marge d’erreur.

Choix d’un scénario

Pour choisir le bon scénario, posez-vous les questions suivantes :

• Taille du corpus   Quelle quantité de contenu doit être accessible à la recherche ? Le nombre total d’éléments doit inclure tous les objets, y compris les documents, les pages Web, les éléments de liste et les personnes.

• Disponibilité   Quels sont les besoins en termes de disponibilité ? Les clients ont-ils besoin d’une solution de recherche qui puisse résister à une panne de serveur particulier ?

• Actualité du contenu   Quel degré d’actualité les résultats de la recherche doivent-ils présenter ? Combien de temps après la modification du contenu par un utilisateur les recherches doivent-elles fournir le contenu mis à jour dans les résultats ? À quelle fréquence le contenu est-il susceptible de changer ?

• Débit   Combien de personnes effectueront des recherches sur le contenu simultanément ? Cela inclut les personnes tapant dans une zone de requête, des requêtes masquées de composants WebPart recherchant automatiquement des données ou des connecteurs Microsoft Outlook 2010 Social Connector interrogeant des flux d’activité qui contiennent des URL nécessitant un découpage de sécurité par le système de recherche.

En fonction des réponses à ces questions, choisissez l’un des scénarios suivants :

• Petite batterie   Inclut une seule application de service de recherche qui partage des ressources sur une seule batterie de serveurs SharePoint Server. Typique des petits déploiements, la quantité de contenu sur lequel fournir la recherche est limitée (mois de 10 millions d’éléments). Selon les objectifs d’actualisation voulus, des analyses incrémentielles peuvent se produire durant les heures de bureau.

• Batterie moyenne   Inclut une ou plusieurs applications de service de recherche dans une batterie de serveurs dédiée, qui fournit des services de recherche à d’autres batteries de serveurs. La quantité de contenu sur lequel fournir la recherche est modérée (jusqu’à 40 millions d’éléments), et pour satisfaire les objectifs d’actualisation, des analyses incrémentielles sont probables durant les heures de bureau.

• Grande batterie   Inclut une ou plusieurs applications de service de recherche dans une batterie de serveurs dédiée, qui fournit des services de recherche à d’autres batteries de serveurs. La quantité de contenu sur lequel fournir la recherche est importante (jusqu’à 100 millions d’éléments), et pour satisfaire les objectifs d’actualisation, des analyses incrémentielles sont probables durant les heures de bureau.

Cycle de vie de recherche

Ces trois scénarios vous permettent d’estimer la capacité de la batterie de serveurs dans une phase précoce. Les batteries de serveurs passent par les phases suivantes du cycle de vie de recherche lors de l’analyse du contenu :

• Acquisition de l’index   Il s’agit de la première phase de remplissage des données. La durée de cette phase dépend de la taille des sources de contenu. Elle se caractérise par les éléments suivants :

  • Analyses complètes (éventuellement simultanées) du contenu.

  • Surveillance attentive du système d’analyse pour assurer que les hôtes analysés ne constituent pas de goulot d’étranglement pour l’analyse.

  • De fréquentes fusions principales, pour chaque composant de requête, sont déclenchées lorsqu’une certaine quantité d’index a changé.

• Maintenance de l’index   C’est la phase la lus courante d’une batterie de serveurs. Elle se caractérise par les éléments suivants :

  • Il y a des analyses incrémentielles de l’ensemble du contenu.

  • Pour les analyses de contenu SharePoint Server, une majorité des changements rencontrés durant l’analyse sont des modifications de sécurité.

  • Des fusions principales peu fréquentes, pour chaque composant de requête, sont déclenchées lorsqu’une certaine quantité d’index a changé.

• Nettoyage de l’index   Cette phase se produit lorsqu’un changement de contenu fait sortir la batterie de serveurs de la phase de maintenance de l’index — par exemple, lorsqu’un site ou une base de données de contenu est déplacé d’une application de service à une autre. Cette phase est déclenchée quand l’une des deux conditions suivantes se produit :

  • Un hôte fournisseur de contenu est introuvable par le robot de recherche pendant une période prolongée.

  • Une source de contenu ou une adresse de départ est supprimée d’une application de service de recherche.

Scénarios

Cette section décrit les configurations utilisées pour les scénarios de batteries de serveurs petite, moyenne et grande. Elle inclut également la charge de travail, l’ensemble de données, ainsi que les données de performances et de test pour chaque environnement.

Petite batterie

Comme la batterie de serveurs est petite, plusieurs rôles doivent être effectués par certains serveurs. Il est recommandé d’associer un composant de requête à un serveur Web frontal pour éviter de placer des composants d’analyse et des composants de requête sur le même serveur. Cette configuration utilise trois serveurs d’applications et un serveur de bases de données, de la manière suivante :

• Comme des serveurs de requête redondants sont en général suggérés pour la recherche d’entreprise, deux serveurs d’applications sont utilisés pour les composants de requête, étant donné la configuration suivante :

  • Un serveur d’applications héberge également le Centre de recherche. Cette configuration peut être omise si la petite batterie est utilisée en tant que batterie de service et que les Centres de recherche sont créés sur les batteries de contenu enfants qui utilisent l’application de service de recherche de cette batterie de service parente.

  • La configuration de requête à privilégier pour moins de 10 millions d’éléments est une partition d’index. Chaque serveur possède alors un composant de requête principal à partir de la partition d’index. Cette configuration de composant de requête active/active permet l’échec de l’un des composants de requête, tout en conservant la capacité à traiter les requêtes à partir du composant de requête restant. Si un composant de requête échoue, la recherche émet les requêtes au composant de requête suivant disponible (round-robin).

• Un serveur d’applications est utilisé pour l’analyse et l’administration. Cela signifie que l’Administration centrale, le composant d’administration de la recherche et un composant d’analyse sont créés sur ce serveur.

• Un seul serveur de bases de données pour prendre en charge la batterie de serveurs. Le serveur de bases de données doit avoir un nombre d’opérations d’entrée/sortie par seconde dédié pour les bases de données d’analyse, de propriétés et d’administration (par exemple, utiliser différentes baies de stockage).

Spécifications

Cette section fournit des informations détaillées sur le matériel, le logiciel, la topologie et la configuration de l’environnement de test.

Topologie

Matériel

Serveurs Web

Serveur Web	Serveur Web frontal/Requête (1)
Processeur	1px4c@3 GHz
RAM	16 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits
Stockage	2x450Go 15K SAS: RAID1: SE 2x450Go 15K SAS: RAID1: Données 1 2x450Go 15K SAS: RAID1: Données 2
Nombre de cartes d’interface réseau (NIC)	2
Vitesse de carte réseau	1 gigabit
Authentification	NTLM
Type d’équilibrage de la charge	Aucune
Version logicielle	SharePoint Server 2010 (version précommerciale)
Services s’exécutant localement	Tous les services (y compris Service de paramètres de site et de requête de recherche)

Serveurs d’applications

Serveur	Requête (1)	Analyse/Administration (1)
Processeur	1px4c@3 GHz	1px4c@3 GHz
RAM	16 Go	16 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits	Windows Server 2008 R2, 64 bits
Stockage	2x450Go 15K SAS:RAID1: SE 2x450Go 15K SAS:RAID1: Données 1 2x450Go 15K SAS:RAID1: Données 2	2x450Go 15K SAS: RAID1: SE 2x450Go 15K SAS: RAID1: TEMP 2x450Go 15K SAS: RAID0: Données
Nombre de cartes réseau	1	1
Vitesse de carte réseau	1 gigabit	1 gigabit
Authentification	NTLM	NTLM
Type d’équilibrage de la charge	aucune	aucune
Version logicielle	SharePoint Server 2010 (version précommerciale)	SharePoint Server 2010 (version précommerciale)
Services s’exécutant localement	SharePoint Server Search, Service de paramètres de site et de requête de recherche	SharePoint Server Search

Serveurs de bases de données

Base de données	Partagé (1)
Processeur	2px4c@3 GHz
RAM	16 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits
Stockage	2x450Go 15K SAS: RAID1: SE 2x450Go 15K SAS: RAID0: Données 2x450Go 15K SAS: RAID0: Journaux Notes Le nombre d’unités étant réduit, la pratique recommandée consistant à répartir les bases de données sur différents canaux E/S n’était pas applicable.
Nombre de cartes réseau	2
Vitesse de carte réseau	1 gigabit
Authentification	NTLM
Version logicielle	Microsoft SQL Server 2008 Enterprise

Charge de travail

Cette section décrit la charge de travail utilisée pour la génération des données, y compris le nombre d’utilisateurs et les caractéristiques d’utilisation de la batterie de serveurs.

Caractéristiques de la charge de travail	Valeur
Description de haut niveau de la charge de travail	Batteries de recherche
Nombre moyen de requêtes par minute	6
Nombre moyen d’utilisateurs simultanés	1
Nombre total de requêtes par jour	8 640

Jeu de données

Cette section décrit le jeu de données de la batterie de serveurs de test, y compris le contenu et la taille des bases de données, les index de recherche et les sources de données externes.

Objet	Valeur
Taille d’index de recherche (nombre d’éléments)	9 millions
Taille de la base de données d’analyse	52 Go
Taille du fichier journal de la base de données d’analyse	11 Go
Taille de la base de données de propriétés	68 Go
Taille du fichier journal de la base de données de propriétés	1 Go
Taille de la base de données d’administration de la recherche	2 Go
Taille des partitions d’index actives	38,4 Go (76,8 Go au total, car mise en miroir de l’index)
Nombre total de bases de données de recherche	3
Autres bases de données	SharePoint_Config, SharePoint_AdminContent, State_Service, Bdc_Service_db, WSS_UsageApplication, WSS_Content

Données d’intégrité et de performances

Cette section fournit les données d’intégrité et de performances spécifiques à l’environnement de test.

Données de performances des requêtes

Les mesures suivantes ont été effectuées avec 9 millions d’éléments dans l’index. Les colonnes indiquent les mesures effectuées durant le test spécifique, et les résultats sont en bout du tableau suivant. Les mesures sont les suivantes :

• Latence des requêtes   Ces mesures ont été effectuées durant un test de latence des requêtes, où un outil de test soumettait un jeu de requêtes standard, comme un utilisateur, puis mesurait la latence obtenue. Aucune analyse ne se déroulait durant le test.

• Débit des requêtes   Ces mesures ont été effectuées durant un test de débit des requêtes, où un outil de test soumettait un jeu de requêtes standard auprès de la batterie de serveurs, comme un nombre croissant d’utilisateurs simultanés (jusqu’à 80), puis mesurait la latence et le débit obtenus. Aucune analyse ne se déroulait durant le test.

	Mesure de performance	Latence des requêtes	Débit des requêtes
Mesures CPU	Moyenne CPU SQL Server	3,4 %	12 %
	Moyenne CPU serveur Web frontal	8 %	51 %
	Moyenne CPU serveur de requêtes	13,3 %	95 %
Fiabilité	Taux d’échec	0	0
	Incidents serveur Web frontal	0	0
	Incidents serveur d’applications	0	0
SQL Server	Taux de réussite en cache (SQL Server)	99,97 %	100 %
	Verrous SQL Server : temps d’attente moyen (ms)	0,071	0,038
	Verrous SQL Server : temps d’attente de verrouillage (ms)	0,035	0,019
	Verrous SQL Server : blocages/seconde	0	0
	Bascules SQL Server : temps d’attente moyen (ms)	31	0,017
	Compilations SQL Server/seconde	14,9	10,2
	Statistiques SQL Server : recompilations SQL Server/seconde	0,087	0,05
	Longueur moyenne de file d’attente disque (SQL Server)	0,011	0,01
	Longueur de file d’attente disque : écritures (SQL Server)	0,01	0,008
	Lectures disque/seconde (SQL Server)	0,894	0,05
	Écritures disque/seconde (SQL Server)	45	106
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur de requêtes)	0,013	0,001
	Longueur de file d’attente disque : écritures (serveur de requêtes)	0	0,001
	Lectures disque/seconde (serveur de requêtes)	11,75	0,06
	Écritures disque/seconde (serveur de requêtes)	4	5,714
	Moyenne de mémoire utilisée (serveur de requêtes)	8,73 %	9 %
	Maximum de mémoire utilisée (serveur de requêtes)	8,75 %	9 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	0	0
	Moyenne de mémoire utilisée (serveur Web frontal)	9,67 %	95 %
	Maximum de mémoire utilisée (serveur Web frontal)	9,74 %	100 %
Résultats des tests	Nombre de succès	1 757	13 608
	Nombre d’erreurs	0	0
	Latence IU de requête (75e centile)	0,331 seconde	3,68 seconde
	Latence IU de requête (95e centile)	0,424 seconde	3,93 seconde
	Débit des requêtes	3,29 requêtes/s	22,4 requêtes/s

Données de performances d’analyse

Les mesures suivantes ont été effectuées durant les analyses complètes séquentielles initiales de la source de contenu donnée. La taille de la source de contenu est indiquée en millions d’éléments. Les colonnes indiquent les mesures effectuées durant l’analyse spécifique, et les résultats sont en bout du tableau.

	Mesure de performance	Contenu SharePoint (4 M)	Partage de fichiers (1 M)	HTTP (non SharePoint) (1 M)
Mesures CPU	Moyenne CPU SQL Server	5,4 %	11,7 %	23 %
	Moyenne CPU indexeur	41,6 %	69 %	71 %
Fiabilité	Taux d’échec	0	0	0
	Incidents serveur Web frontal	0	0	0
	Incidents serveur d’applications	0	0	0
SQL Server	Taux de réussite en cache (SQL Server)	N/A	N/A	N/A
	Verrous SQL Server : temps d’attente moyen (ms)	436	51,76	84,73
	Verrous SQL Server : temps d’attente de verrouillage (ms)	N/A	N/A	N/A
	Verrous SQL Server : blocages/seconde	N/A	N/A	N/A
	Bascules SQL Server : temps d’attente moyen (ms)	1,05	1,64	3,53
	Compilations SQL Server/seconde	N/A	N/A	N/A
	Statistiques SQL Server : recompilations SQL Server/seconde	N/A	N/A	N/A
	Longueur moyenne de file d’attente disque (SQL Server)	27,124	6,85	45
	Longueur de file d’attente disque : écritures (SQL Server)	17,6	6,7	21,57
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur d’analyse)	0,008	0,032	0,02
	Longueur de file d’attente disque : écritures (serveur d’analyse)	0,006	0,025	0,012
	Moyenne de mémoire utilisée (serveur d’analyse)	14,16 %	10,4 %	11,5 %
	Maximum de mémoire utilisée (serveur d’analyse)	19,2 %	11,13 %	12,78 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	0	0	0
	Moyenne de mémoire utilisée (serveur Web frontal)	N/A	N/A	N/A
	Maximum de mémoire utilisée (serveur Web frontal)	N/A	N/A	N/A
Résultats des tests	Nombre de succès	3 934 881	1 247 838	996 982
	Nombre d’erreurs	9 645	302	2
	Vitesse d’analyse du portail (éléments/s)	46,32	120,436	138,316
	Vitesse d’analyse d’ancrage (éléments/s)	5 197	3 466,219	2 192,982
	Vitesse d’analyse totale (éléments/s)	45,91	116,392	130,086

Données de test

Cette section fournit les données de test illustrant les performances de la batterie. Voir la section Optimisations plus loin dans cet article pour savoir comment améliorer ces performances.

Latence des requêtes

Le graphique suivant montre les centiles de latence des requêtes pour cette batterie en fonction de l’augmentation de la charge utilisateur (recueillis durant le test de débit des requêtes). Un centile de 95 % signifie que 95 % des latences mesurées étaient en dessous de cette valeur.

D’après ce graphique, vous pouvez constater qu’avec un index plus petit, cette batterie peut maintenir une latence des requêtes inférieure à la seconde, même lorsque davantage d’utilisateurs simultanés (20) effectuent des requêtes sur cette batterie.

Débit des requêtes

Le graphique suivant montre le débit des requêtes pour cette batterie en fonction de l’augmentation de la charge utilisateur (recueilli durant le test de débit des requêtes).

D’après les deux précédents graphiques, vous pouvez constater que si vous augmentez la charge utilisateur au-delà de 20 utilisateurs simultanés, cette batterie n’acceptera aucun débit de requêtes supplémentaire et que la latence augmentera.

Taux d’analyse

Le graphique suivant affiche le taux d’analyse de cette batterie durant la phase d’acquisition d’index du cycle de vie de recherche. Les valeurs représentent une analyse complète, en nombre d’éléments analysés par seconde.

La surcharge supplémentaire que représente une analyse complète d’une source de contenu de site SharePoint entraîne une diminution du taux d’analyse global sur cette batterie.

Bilan global

Cette batterie est proche de la capacité en RAM pour les serveurs de requêtes. Comme les processus de serveur Web frontal (consommant également de la RAM) sont également sur l’un des serveurs de requêtes, cela affecte la latence des requêtes s’exécutant sur ce serveur.

Pour améliorer les performances de cette batterie, les étapes à entreprendre sont les suivantes :

• Déplacer les processus de serveur Web frontal sur le serveur Web frontal correspondant (c’est-à-dire, ajouter un autre serveur Web frontal pour la redondance).

• Ajouter de la RAM aux deux serveurs de requêtes. Nous recommandons une quantité suffisante de RAM sur le serveur de requêtes pour 33 % de la partition d’index du composant de requête actif plus 3 Go pour le système d’exploitation et les autres processus.

• Ajouter des baies de stockage afin de pouvoir regrouper les bases de données sur le même serveur de bases de données.

Batterie moyenne

La configuration de batterie moyenne utilise un serveur Web, six serveurs d’applications et deux serveurs de bases de données, de la manière suivante :

• Un serveur Web a été utilisé dans cette configuration de test pour héberger le Centre de recherche. Ce serveur Web peut être omis si les recherches sont toujours effectuées à partir d’une batterie enfant en utilisant un proxy d’application de service de recherche (installé sur la batterie enfant). Sinon, vous ajouteriez probablement un autre serveur Web à cette batterie pour la redondance.

• Deux serveurs d’applications sont utilisés pour l’analyse et l’administration. Cela signifie que :

  • L’Administration centrale et le composant d’administration de la recherche sont créés sur l’un des serveurs d’applications.

  • Chaque serveur comporte deux composants d’analyse qui sont chacun reliés à une base de données d’analyse différente pour la redondance.

• Les quatre autres serveurs d’applications sont utilisés pour l’interrogation. Jusqu’à 40 millions d’éléments, la configuration standard consiste à avoir quatre partitions d’index. La fonctionnalité de requête redondante est obtenue en organisant les composants de requête de sorte que chaque serveur ait un composant de requête actif à partir de l’une des partitions d’index et un composant de requête de basculement à partir d’une partition d’index différente. Cependant, cet exemple de batterie montre quoi faire si vous envisagez plus de 40 millions d’éléments. Vous commencez avec huit partitions d’index (chacune avec ses propres composants de requête actif et de basculement) sur les quatre serveurs d’applications afin de minimiser le repartitionnement d’index. Nous supposons que chaque serveur satisfait les conditions suivantes afin de permettre quatre composants sur le même serveur d’applications :

  • Suffisamment de RAM et d’E/S par seconde disponibles

  • Chaque serveur a plus de six cœurs de processeur pour prendre en charge le traitement de la manière suivante :

    • Quatre cœurs de processeur pour les deux composants de requête actifs.

    • Deux cœurs de processeur pour les deux composants de requête de basculement.

• Deux serveurs de bases de données prennent en charge la batterie de serveurs. L’un des deux serveurs est utilisé pour les deux bases de données d’analyse. L’autre est utilisé pour les bases de données de propriétés et d’administration de la recherche, ainsi que pour les autres bases de données SharePoint. Les serveurs de bases de données doivent avoir un nombre d’opérations d’entrée/sortie par seconde dédié pour chaque base de donnée d’analyse, de propriétés et d’administration de la recherche (par exemple, utiliser différentes baies de stockage).

Spécifications

Cette section fournit des informations détaillées sur le matériel, le logiciel, la topologie et la configuration de l’environnement de test.

Topologie

Matériel

Serveur Web

Serveur Web	Serveur Web frontal (1)
Processeur	2px4c@2,33 GHz
RAM	8 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS: RAID1: SE
Nombre de cartes réseau	2
NIC speed	1 gigabit
Authentification	NTLM
Type d’équilibrage de la charge	Aucune
Version logicielle	Microsoft SharePoint Server (version précommerciale)
Services s’exécutant localement	Tous les services

Serveurs d’applications

La batterie de serveurs contient six serveurs d’applications. Quatre serveurs sont utilisés pour le traitement des requêtes et deux serveurs sont utilisés pour l’analyse.

Serveur (nombre)	Requête (4)	Analyse (1), Analyse/Admin (1)
Processeur	2px4c@2,33 GHz	2px4c@2,33 GHz
RAM	32 Go	8 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS: RAID1: SE 4x300Go 15K SAS:RAID0: Données	2x148Go 15K SAS:RAID1: SE/Données
Nombre de cartes réseau	2	2
Vitesse de carte réseau	1 gigabit	1 gigabit
Authentification	NTLM	NTLM
Type d’équilibrage de la charge	Aucune	Aucune
Version logicielle	SharePoint Server 2010 (version précommerciale)	SharePoint Server 2010 (version précommerciale)
Services s’exécutant localement	SharePoint Server Search, Service de paramètres de site et de requête de recherche	SharePoint Server Search

Serveurs de bases de données

Il y a deux serveurs de bases de données. Le premier contient les bases de données d’administration de la recherche, de propriétés et les autres bases de données SharePoint Server. Le second contient les deux bases de données d’analyse. Notez que les volumes de stockage créés optimisaient le matériel existant disponible pour le test.

Serveur de bases de données	Base de données d’administration de la recherche, de propriétés et SharePoint	Bases de données d’analyse
Processeur	2px4c@3,2 GHz	4px2c@2,19 GHz
RAM	32 Go	16 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS :RAID1: SE 2x148Go 15K SAS :RAID1: Journal TEMP 2x450Go 15K SAS :RAID1: BDD TEMP 6x450Go 15K SAS :RAID0: BDD Propriétés 2x450Go 15K SAS :RAID1: BDD Admin recherche, SharePoint 2x450Go 15K SAS :RAID1:Journaux	2x148Go 15K SAS :RAID1: SE 2x148Go 15K SAS :RAID1: Journal TEMP 2x300Go 15K SAS :RAID1: BDD TEMP 6x146Go 15K SAS : RAID0: BDD Analyse 1 6x146Go 15K SAS :RAID0: BDD Analyse 2 2x300Go 15K SAS :RAID1: Journal BDD Analyse 1 2x300Go 15K SAS :RAID1: Journal BDD Analyse 2
Nombre de cartes réseau	2	2
Vitesse de carte réseau	1 gigabit	1 gigabit
Authentification	NTLM	NTLM
Version logicielle	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Charge de travail

Cette section décrit la charge de travail utilisée pour la génération des données, y compris le nombre d’utilisateurs et les caractéristiques d’utilisation de la batterie de serveurs.

Caractéristiques de la charge de travail	Valeur
Description de haut niveau de la charge de travail	Batteries de recherche
Nombre moyen de requêtes par minute	12
Nombre moyen d’utilisateurs simultanés	1
Nombre total de requêtes par jour	17 280
Travaux du minuteur	Analyse du fonctionnement de la recherche - Suivi des événements, Rapport du journal d’analyse, Tâche d’analyse de l’intégrité, Recherche et processus

Jeu de données

Cette section décrit le jeu de données de la batterie de serveurs de test, y compris le contenu et la taille des bases de données, les index de recherche et les sources de données externes.

Objet	Valeur
Taille d’index de recherche (nombre d’éléments)	46 millions
Taille de la base de données d’analyse	356 Go
Taille du fichier journal de la base de données d’analyse	85 Go
Taille de la base de données de propriétés	304 Go
Taille du fichier journal de la base de données de propriétés	9 Go
Taille de la base de données d’administration de la recherche	5 Go
Taille des partitions d’index actives	316 Go (79 Go par composant actif).
Nombre total de bases de données	4
Autres bases de données	SharePoint_Config, SharePoint_AdminContent, State_Service, Bdc_Service_db, WSS_UsageApplication, WSS_Content

Données d’intégrité et de performances

Cette section fournit les données d’intégrité et de performances spécifiques à l’environnement de test.

Données de performances des requêtes

Les mesures suivantes ont été effectuées avec 46 millions d’éléments dans l’index de recherche. Les colonnes indiquent les mesures effectuées durant le test spécifique, et les résultats sont en bout du tableau. Les mesures sont les suivantes :

• Latence des requêtes   Ces mesures ont été effectuées durant un test de latence des requêtes, où un outil de test soumettait un jeu de requêtes standard, comme un utilisateur, puis mesurait la latence obtenue. Aucune analyse ne se déroulait durant le test.

• Débit des requêtes   Ces mesures ont été effectuées durant un test de débit des requêtes, où un outil de test soumettait un jeu de requêtes standard auprès de la batterie de serveurs, comme un nombre croissant d’utilisateurs simultanés (jusqu’à 80), puis mesurait la latence et le débit obtenus. Aucune analyse ne se déroulait durant le test.

	Mesure de performance	Latence des requêtes	Débit des requêtes
Mesures CPU	Moyenne CPU SQL Server (serveur de base de données de propriétés)	5 %	98 %
	Moyenne CPU serveur Web frontal	3 %	33 %
	Moyenne CPU serveur de requêtes	3 %	47 %
Fiabilité	Taux d’échec	0,07 %	0 %
	Incidents serveur Web frontal	0	0
	Incidents serveur d’applications	0	0
SQL Server (serveur de base de données de propriétés)	Taux de réussite en cache (SQL Server)	100 %	99,9 %
	Verrous SQL Server : temps d’attente moyen (ms)	0,000	0,159
	Verrous SQL Server : temps d’attente de verrouillage (ms)	0,000	0,080
	Verrous SQL Server : blocages/seconde	0	0
	Bascules SQL Server : temps d’attente moyen (ms)	0,041	1,626
	Compilations SQL Server/seconde	9,776	93,361
	Statistiques SQL Server : recompilations SQL Server/seconde	0,059	0,071
	Ratio de lecture/écriture (E/S par base de données)	0,01	0,81
	Longueur moyenne de file d’attente disque (SQL Server)	0,001	0,037
	Longueur de file d’attente disque : écritures (SQL Server)	0,000	0,003
	Lectures disque/seconde (SQL Server)	0,057	14,139
	Écritures disque/seconde (SQL Server)	4,554	17,515
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur de requêtes)	0,000	0,001
	Longueur de file d’attente disque : écritures (serveur de requêtes)	0,000	0,001
	Lectures disque/seconde (serveur de requêtes)	0,043	0,266
	Écritures disque/seconde (serveur de requêtes)	4,132	5,564
	Moyenne de mémoire utilisée (serveur de requêtes)	9 %	10 %
	Maximum de mémoire utilisée (serveur de requêtes)	9 %	10 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	0	0
	Moyenne de mémoire utilisée (serveur Web frontal)	47 %	48 %
	Maximum de mémoire utilisée (serveur Web frontal)	47 %	49 %
Résultats des tests	Nombre de succès	1 398	14 406
	Nombre d’erreurs	1	0
	Latence IU de requête (75e centile)	0,47 seconde	2,57 seconde
	Latence IU de requête (95e centile)	0,65 seconde	3,85 seconde
	Débit des requêtes	2,38 requêtes/s	27,05 requêtes/s

Données de performances d’analyse

Les mesures suivantes ont été effectuées durant les analyses complètes initiales de la source de contenu donnée. La taille de la source de contenu est indiquée en millions d’éléments. Les colonnes indiquent les mesures effectuées durant l’analyse spécifique, et les résultats sont en bout du tableau.

	Mesure de performance	Contenu SharePoint (3,5 millions)	Partage de fichiers (1 million)	HTTP (non SharePoint) (1 million)
Mesures CPU	Moyenne CPU SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	11 %, 19 %	22 %, 7 %	23 %, 5 %
	Maximum CPU SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	96 %, 100 %	86 %, 45 %	79 %, 28 %
	Moyenne CPU indexeur	41,6 %	69 %	71 %
Fiabilité	Taux d’échec	0,2 %	0,02 %	0 %
	Incidents serveur Web frontal	0	0	0
	Incidents serveur d’applications	0	0	0
SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	Taux de réussite en cache (SQL Server)	99,5 %, 99,8 %	Non recueilli	99,9 %, 99,3 %
	Verrous SQL Server : temps d’attente moyen (ms)	1 881,749, 1 106,314	1 617,980, 2,882	983,137, 0,904
	Verrous SQL Server : temps d’attente maximum (ms)	69 919,500, 1 081 703	55 412,000, 304,500	24 000,500, 47
	Verrous SQL Server : temps d’attente moyen de verrouillage (ms)	339,658, 10 147,012	Non recueilli	739,232, 0,136
	Verrous SQL Server : temps d’attente maximum de verrouillage (ms)	598 106,544, 234 708 784	Non recueilli	52 711,592, 23,511
	Verrous SQL Server : blocages/seconde	0,001, 0	Non recueilli	0,008, 0
	Bascules SQL Server : temps d’attente moyen (ms)	2,288, 13,684	3,042, 13,516	2,469, 20,093
	Bascules SQL Server : temps d’attente maximum (ms)	2 636, 1 809	928, 858,5	242,929, 938,706
	Moyenne compilations SQL Server/seconde	20,384, 5,449	Non recueilli	76,157, 6,510
	Maximum compilations SQL Server/seconde	332,975, 88,992	Non recueilli	295,076, 42,999
	Statistiques SQL Server : moyenne recompilations SQL Server/seconde	0,560, 0,081	Non recueilli	0,229, 0,125
	Statistiques SQL Server : maximum recompilations SQL Server/seconde	22,999, 88,492	Non recueilli	17,999, 15,5
	Ratio maximum de lecture/écriture (E/S par base de données)	2,15, 1,25	Non recueilli	1,45, 0,364
	Longueur moyenne de file d’attente disque (SQL Server)	66,765, 27,314	129,032, 20,665	182,110, 11,816
	Longueur maximum de file d’attente disque (SQL Server)	4 201,185, 5 497,980	3 050,015, 762,542	1 833,765, 775,7
	Longueur moyenne de file d’attente disque : écritures (SQL Server)	58,023, 13,532	114,197, 19,9	175,621, 10,417
	Longueur maximum de file d’attente disque : écritures (SQL Server)	1 005,691, 881,892	1 551,437, 761,891	1 018,642, 768,289
	Moyenne lectures disque/seconde (SQL Server)	245,945, 94,131	Non recueilli	137,435, 154,103
	Maximum lectures disque/seconde (SQL Server)	6 420,412, 6 450,870	Non recueilli	3 863,283, 1 494,805
	Moyenne écritures disque/seconde (SQL Server)	458,144, 286,884	Non recueilli	984,668, 278,175
	Maximum écritures disque/seconde (SQL Server)	2 990,779, 5 164,949	Non recueilli	2 666,285, 4 105,897
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur d’analyse)	0,052	0,043	0,030
	Longueur de file d’attente disque : écritures (serveur d’analyse)	0,029	0,031	0,026
	Lectures disque/seconde (serveur d’analyse)	5,405	Non recueilli	0,798
	Écritures disque/seconde (serveur d’analyse)	48,052	Non recueilli	102,235
	Moyenne de mémoire utilisée (serveur d’analyse)	68 %	45 %	52 %
	Maximum de mémoire utilisée (serveur d’analyse)	76 %	47 %	59 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	0	0	0
	Moyenne de mémoire utilisée (serveur Web frontal)	N/A	N/A	N/A
	Maximum de mémoire utilisée (serveur Web frontal)	N/A	N/A	N/A
Résultats des tests	Nombre de succès	3 631 080	1 247 838	200 000
	Nombre d’erreurs	7 930	304	0
	Vitesse d’analyse du portail (éléments/s)	82	148	81
	Vitesse d’analyse d’ancrage (éléments/s)	1 573	1 580	1 149
	Vitesse d’analyse totale (éléments/s)	79	136	76

Données de test

Cette section fournit les données de test illustrant les performances de la batterie sous charge.

Latence des requêtes

Le graphique suivant montre les centiles de latence des requêtes pour cette batterie en fonction de l’augmentation de la charge utilisateur (recueillis durant le test de débit des requêtes). Un centile de 95 % signifie que 95 % des latences mesurées étaient en dessous de cette valeur.

D’après ce graphique, vous pouvez constater qu’avec un index plus petit, cette batterie peut maintenir une latence de requêtes inférieure à la seconde au 95e centile, même lorsque davantage d’utilisateurs simultanés (22) effectuent des requêtes sur cette batterie.

Débit des requêtes

Le graphique suivant montre le débit des requêtes pour cette batterie en fonction de l’augmentation de la charge utilisateur (recueilli durant le test de débit des requêtes).

D’après ce graphique et le précédent, vous pouvez constater qu’avec 33 millions d’éléments dans l’index, la batterie peut maintenir une latence de requêtes inférieure à la seconde au 75e centile avec 30 utilisateurs simultanés environ. Une charge d’utilisateurs simultanés supplémentaire reste possible, mais la latence de requêtes ne sera plus inférieure à la seconde.

Cependant, avec 46 millions d’éléments dans l’index, aucune charge d’utilisateurs simultanés supplémentaire ne peut être prise en charge et la latence de requêtes augmente.

Taux d’analyse

Le graphique suivant affiche le taux d’analyse de cette batterie durant la phase d’acquisition d’index du cycle de vie de recherche. Les valeurs représentent une analyse complète, en nombre d’éléments analysés par seconde.

La surcharge supplémentaire que représente une analyse effective d’une source de contenu de site SharePoint entraîne une diminution du taux d’analyse global sur cette batterie.

Bilan global

Cette batterie est proche de la capacité en RAM pour les serveurs de requêtes.

Pour améliorer les performances de cette batterie, les étapes à entreprendre sont les suivantes :

• Ajouter de la RAM aux deux serveurs de requêtes. Nous recommandons une quantité suffisante de RAM sur le serveur de requêtes pour 33 % de la partition d’index du composant de requête actif plus 3 Go pour le système d’exploitation et les autres processus.

• Ajoutez de la RAM au serveur de bases de données qui héberge la base de données de propriétés. Dans cette configuration, les tables clés occupaient 92 Go environ (y compris les index), ce qui suggère une configuration de 30 Go de RAM. Cependant, le serveur de bases de données ne disposait que de 32 Go de RAM pour traiter la base de données de propriétés, la base de données d’administration de recherche et les autres bases de données SharePoint Server.

• Ajoutez des baies de stockage afin de pouvoir regrouper les bases de données sur le même serveur de bases de données.

• Montez en puissance afin d’augmenter le débit ou réduire la latence des requêtes ou les deux.

Bien que le taux d’analyse soit élevé sur cette batterie avec deux bases de données d’analyse et quatre composants d’analyse, disposer de certaines parties de l’index plus actualisées peut être un objectif important pour la batterie afin que certains contenus soient analysés plus fréquemment. L’ajout d’une autre base de données d’analyse dédiée à l’hébergement de la source de contenu voulue (avec des règles de distribution d’hôte) et l’association de deux composants d’analyse supplémentaires à la base de données prendra en charge l’objectif d’actualisation de l’index.

Grande batterie

La configuration voulue utilise un serveur Web, 13 serveurs d’applications et 3 serveurs de bases de données, de la manière suivante :

• Un serveur Web est utilisé pour héberger le Centre de recherche. Ce serveur peut être omis si les recherches sont toujours effectuées à partir d’une batterie de contenu en utilisant un proxy d’application de service de recherche (installé sur la batterie de contenu).

• Trois serveurs d’applications sont utilisés pour l’analyse et l’administration. Cela signifie que :

  • L’Administration centrale et le composant d’administration de la recherche sont créés sur l’un des serveurs d’applications.

  • Chaque serveur comporte deux composants d’analyse qui sont chacun reliés à une base de données d’analyse distincte.

• Les dix autres serveurs d’applications sont utilisés pour l’interrogation. La configuration recommandée est d’avoir dix partitions d’index. Chaque serveur possède alors un composant de requête principal à partir de l’une des partitions d’index et un composant de requête de basculement à partir d’une partition d’index différente.

• Quatre serveurs de bases de données prennent en charge la batterie de serveurs. Un serveur est utilisé pour les bases de données de propriétés et d’administration de la recherche. Un second serveur est utilisé pour une base de données de propriétés. Un troisième serveur est utilisé pour deux bases de données d’analyse. Le quatrième serveur est utilisé pour une base de données d’analyse et les autres bases de données SharePoint. Les serveurs de bases de données doivent avoir un nombre d’opérations d’entrée/sortie par seconde dédié pour chaque base de donnée d’analyse, de propriétés et d’administration de la recherche (par exemple, utiliser différentes baies de stockage).

Spécifications

Cette section fournit des informations détaillées sur le matériel, le logiciel, la topologie et la configuration de l’environnement de test.

Topologie

Cette section décrit la topologie de l’environnement de test.

Matériel

Cette section décrit le matériel utilisé pour les tests.

Serveurs Web

Serveur Web	Serveur Web frontal (1)
Processeur	2px4c@2,33 GHz
RAM	8 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS: RAID1: SE
Nombre de cartes réseau	2
Vitesse de carte réseau	1 gigabit
Authentification	NTLM
Type d’équilibrage de la charge	aucune
Version logicielle	SharePoint Server 2010 (version précommerciale)
Services s’exécutant localement	Tous les services

Serveurs d’applications

La batterie de serveurs contient 13 serveurs d’applications ; 10 serveurs sont utilisés pour le traitement des requêtes et 3 serveurs sont utilisés pour l’analyse.

Serveur (nombre)	Requête (10)	Analyse (2), Analyse/Administration (1)
Processeur	2px4c@2,5 GHz	2px4c@2,5 GHz
RAM	32 Go	32 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS: RAID1: SE 4x300Go 15K SAS:RAID0: Données	2x148Go 15K SAS:RAID1: SE/Données
Nombre de cartes réseau	2	2
Vitesse de carte réseau	1 gigabit	1 gigabit
Authentification	NTLM	NTLM
Type d’équilibrage de la charge	Aucune	Aucune
Version logicielle	SharePoint Server 2010 (version précommerciale)	SharePoint Server 2010 (version précommerciale)
Services s’exécutant localement	SharePoint Server Search, Service de paramètres de site et de requête de recherche	SharePoint Server Search

Serveurs de bases de données

Il y a quatre serveurs de bases de données. Le premier contient les bases de données de propriétés et d’administration de la recherche ; le second contient une base de données de propriétés ; le troisième contient deux bases de données d’analyse ; le quatrième contient une base de données d’analyse et une base de données SharePoint. Notez que les volumes de stockage créés optimisaient le matériel existant disponible pour le test.

Serveur de bases de données	Base de données d’administration de la recherche, de propriétés et SharePoint	Bases de données d’analyse
Processeur	2px4c@3,2 GHz	4px2c@2,19 GHz
RAM	32 Go	16 Go
Système d’exploitation	Windows Server 2008 R2, 64 bits	Windows Server 2008 R2, 64 bits
Stockage	2x148Go 15K SAS :RAID1: SE 2x148Go 15K SAS :RAID1: Journal TEMP 2x450Go 15K SAS :RAID1: BDD TEMP 6x450Go 15K SAS :RAID0: BDD Propriétés 2x450Go 15K SAS :RAID1: BDD Admin recherche, SharePoint 2x450Go 15K SAS :RAID1: Journaux	2x148Go 15K SAS :RAID1: SE 2x148Go 15K SAS :RAID1: Journal TEMP 2x300Go 15K SAS :RAID1: BDD TEMP 6x146Go 15K SAS :RAID0: BDD Analyse 1 6x146Go 15K SAS :RAID0: BDD Analyse 2 2x300Go 15K SAS :RAID1: Journal BDD Analyse 1 2x300Go 15K SAS :RAID1: Journal BDD Analyse 2
Nombre de cartes réseau	2	2
Vitesse de carte réseau	1 gigabit	1 gigabit
Authentification	NTLM	NTLM
Version logicielle	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Données de performances des requêtes

Les mesures suivantes ont été effectuées avec 103 millions d’éléments dans l’index. Les colonnes indiquent les mesures effectuées durant le test spécifique, et les résultats sont en bout du tableau. Les mesures sont les suivantes :

• Latence des requêtes   Ces mesures ont été effectuées durant un test de latence des requêtes, où un outil de test soumettait un jeu de requêtes standard, comme un utilisateur, puis mesurait la latence obtenue. Aucune analyse ne se déroulait durant le test.

• Débit des requêtes   Ces mesures ont été effectuées durant un test de débit des requêtes, où un outil de test soumettait un jeu de requêtes standard auprès de la batterie de serveurs, comme un nombre croissant d’utilisateurs simultanés (jusqu’à 120), puis mesurait la latence et le débit obtenus. Aucune analyse ne se déroulait durant le test.

	Mesure de performance	Débit des requêtes
Mesures CPU	Moyenne CPU SQL Server (serveur de base de données de propriétés)	34 %
	Moyenne CPU serveur Web frontal	45 %
	Moyenne CPU serveur de requêtes	20 %
Fiabilité	Taux d’échec	0 %
	Incidents serveur Web frontal	0
	Incidents serveur d’applications	0
SQL Server (serveur de base de données de propriétés)	Taux de réussite en cache (SQL Server)	100 %
	Verrous SQL Server : temps d’attente moyen (ms)	0
	Verrous SQL Server : temps d’attente de verrouillage (ms)	0
	Verrous SQL Server : blocages/seconde	0
	Bascules SQL Server : temps d’attente moyen (ms)	1,401
	Compilations SQL Server/seconde	73,349
	Statistiques SQL Server : recompilations SQL Server/seconde	0,006
	Ratio de lecture/écriture (E/S par base de données)	0,81
	Longueur moyenne de file d’attente disque (SQL Server)	0,037
	Longueur de file d’attente disque : écritures (SQL Server)	0,003
	Lectures disque/seconde (SQL Server)	9,88
	Écritures disque/seconde (SQL Server)	354,1
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur de requêtes)	0,002
	Longueur de file d’attente disque : écritures (serveur de requêtes)	0,002
	Lectures disque/seconde (serveur de requêtes)	0,035
	Écritures disque/seconde (serveur de requêtes)	6,575
	Moyenne de mémoire utilisée (serveur de requêtes)	6,548 %
	Maximum de mémoire utilisée (serveur de requêtes)	6,601 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	0
	Moyenne de mémoire utilisée (serveur Web frontal)	18,081 %
	Maximum de mémoire utilisée (serveur Web frontal)	19,983 %
Résultats des tests	Nombre de succès	10 925
	Nombre d’erreurs	0
	Latence IU de requête (75e centile)	3,431 seconde
	Latence IU de requête (95e centile)	3,512 seconde
	Débit des requêtes	36,42 requêtes/s

Données de performances d’analyse

Les mesures suivantes ont été effectuées durant les analyses complètes séquentielles initiales de la source de contenu donnée. La taille du contenu est indiquée en millions d’éléments. Les colonnes indiquent les mesures effectuées durant l’analyse spécifique, et les résultats sont en bout du tableau.

	Mesure de performance	Contenu SharePoint (3,5 millions)	Partage de fichiers (1 million)
Mesures CPU	Moyenne CPU SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	15,74 %, N/A	24 %, 6,6 %
	Maximum CPU SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	100 %, N/A	100 %, 45 %
	Moyenne CPU indexeur	44 %	49 %
Fiabilité	Taux d’échec	0,0 %	0,00 %
	Incidents serveur Web frontal	0	0
	Incidents serveur d’applications	0	0
SQL Server (serveur de bases de données d’analyse, serveur de base de données de propriétés)	Taux de réussite en cache (SQL Server)	99,8 %, N/A	99,797 %, 99,49 %
	Verrous SQL Server : temps d’attente moyen (ms)	734,916, N/A	1 165, 5,866
	Verrous SQL Server : temps d’attente maximum (ms)	15 335, N/A	28 683, 210,5
	Verrous SQL Server : temps d’attente moyen de verrouillage (ms)	108,98, N/A	847,72, 5,325
	Verrous SQL Server : temps d’attente maximum de verrouillage (ms)	17 236,96, N/A	124 353, 12 920
	Verrous SQL Server : blocages/seconde	0, N/A	0,012, 0
	Bascules SQL Server : temps d’attente moyen (ms)	1,4, N/A	2,233, 40,6
	Bascules SQL Server : temps d’attente maximum (ms)	1 606, N/A	917,8, 1 895
	Moyenne compilations SQL Server/seconde	24,28, N/A	72,7, 11,39
	Maximum compilations SQL Server/seconde	416, N/A	460, 76,62
	Statistiques SQL Server : moyenne recompilations SQL Server/seconde	0,560, N/A	0,295, 0,099
	Statistiques SQL Server : maximum recompilations SQL Server/seconde	0,24, N/A	17,50, 17,393
	Ratio maximum de lecture/écriture (E/S par base de données)	20,3, N/A	1,18/0,214
	Longueur moyenne de file d’attente disque (SQL Server)	90,113, N/A	138,64, 27,478
	Longueur maximum de file d’attente disque (SQL Server)	3 179, N/A	2 783,543, 847,574
	Longueur moyenne de file d’attente disque : écritures (SQL Server)	86,93, N/A	130 853, 26,086
	Longueur maximum de file d’attente disque : écritures (SQL Server)	1 882, N/A	2 781,197, 884,801
	Moyenne lectures disque/seconde (SQL Server)	99, N/A	147,462, 159,159
	Maximum lectures disque/seconde (SQL Server)	3 772, N/A	2 403,336, 896,462
	Moyenne écritures disque/seconde (SQL Server)	373, N/A	475,886, 539,497
	Maximum écritures disque/seconde (SQL Server)	18 522, N/A	2 031,888, 4 174,271
Serveur d’applications	Longueur moyenne de file d’attente disque (serveur d’analyse)	0,075	0,063
	Longueur de file d’attente disque : écritures (serveur d’analyse)	0,046	0,053
	Lectures disque/seconde (serveur d’analyse)	1,958	1,693
	Écritures disque/seconde (serveur d’analyse)	62,33	101,093
	Moyenne de mémoire utilisée (serveur d’analyse)	59 %	56,38 %
	Maximum de mémoire utilisée (serveur d’analyse)	70 %	58,93 %
Serveur Web frontal	Requêtes ASP.NET en file d’attente (moyenne de tous les serveurs Web frontaux)	N/A	N/A
	Moyenne de mémoire utilisée (serveur Web frontal)	N/A	N/A
	Maximum de mémoire utilisée (serveur Web frontal)	N/A	N/A
Résultats des tests	Nombre de succès	1 909 739	1 247 838
	Nombre d’erreurs	9 361	331
	Vitesse d’analyse du portail (éléments/s)	70,3	131,44
	Vitesse d’analyse d’ancrage (éléments/s)	764	525,84
	Vitesse d’analyse totale (éléments/s)	64	105

Recommandations et dépannage

Les sections suivantes fournissent des recommandations quant à la manière de déterminer le matériel, la topologie et la configuration nécessaires pour déployer des environnements similaires à ces scénarios et d’optimiser l’environnement pour une capacité et des caractéristiques de performances appropriées.

Recommandations

Cette section décrit comment optimiser l’environnement pour une capacité et des caractéristiques de performances appropriées.

Recommandations relatives au matériel

Pour des informations spécifiques sur les configurations système minimale et recommandée requises, voir Configuration matérielle et logicielle requise (SharePoint Server 2010). Notez que la configuration des serveurs utilisés pour la recherche dans ces scénarios l’emporte sur la configuration système globale. Utilisez les recommandations suivantes concernant la RAM, le processeur et les E/S par seconde (IOPS) pour satisfaire les objectifs de performances.

Dimensionnement de la recherche

Cette section explique le système de recherche, y compris les exigences et les instructions de dimensionnement, par composant.

SharePoint Server 2010 peut être déployé et configuré de nombreuses façons. Par conséquent, il n’est pas aisé d’évaluer le nombre d’utilisateurs ou d’éléments pouvant être pris en charge par un nombre de serveurs donné. Veillez donc à effectuer des tests dans votre propre environnement avant de déployer SharePoint Server 2010 dans un environnement de production.

Système de requête de recherche

Cette section décrit les composants du système de requête de recherche pour une application de service de recherche donnée. Les exigences de dimensionnement de chaque composant sont listées dans le tableau Détails d’échelle qui suit le diagramme ci-après.

Description des objets

La liste ci-après définit les objets du système de requête de recherche du diagramme précédent :

• Proxy de recherche   Il s’agit du proxy de l’application de service de recherche installé sur une batterie qui consomme la recherche à partir de cette application. Il s’exécute dans le contexte des applications Web associées au proxy de l’application de service de recherche.

• Service de paramètres de site et de requête de recherche   Également appelé processeur de requêtes. Recevant la requête d’une connexion au proxy de l’application de service de recherche, le processeur de requêtes effectue les opérations suivantes :

  • Envoie la requête à un composant de requête actif pour chaque partition d’index (ou à la base de données de propriétés ou aux deux, selon la requête)

  • Récupère les meilleurs résultats et supprime les doublons pour obtenir le jeu de résultats

  • Effectue un filtrage de sécurité des résultats basé sur les descripteurs de sécurité dans la base de données de recherche

  • Récupère les métadonnées du jeu de résultats final à partir de la base de données de propriétés

  • Renvoie les résultats de la requête au proxy

• Partition d’index   Il s’agit d’un groupe logique de composants de requête, qui représente un sous-ensemble de l’index de texte intégral. La somme des partitions d’index compose l’index de texte intégral. Cependant, notez que les composants de requête contiennent le sous-ensemble réel de l’index. Une partition d’index est associée à une base de données de propriétés.

• Composant de requête de recherche   Un composant de requête contient la totalité ou une partie de l’index de texte intégral. Lorsqu’il est interrogé par un processeur de requête, le composant de requête détermine les meilleurs résultats à partir de son index et retourne ces éléments. Un composant de requête peut être créé dans l’un des types suivantes :

  • Actif, ce qui signifie qu’il répondra aux requêtes par défaut. L’ajout de plusieurs composants de requête à la même partition d’index augmentera le débit.

  • Basculement, ce qui signifie qu’il répondra aux requêtes seulement quand tous les composants de requête actifs de la même partition d’index ont échoué.

• Base de données d’administration de la recherche   Créée en même temps que l’application de service de recherche, cette base de données contient les données à l’échelle de l’application de service de recherche utilisées pour les requêtes comme Meilleurs résultats, les descripteurs de sécurité et les paramètres d’application utilisés pour l’administration.

• Base de données de propriétés   Une telle base de données contient les métadonnées (titre, auteur, champs associés) des éléments de l’index. Cette base de données est utilisée pour les requêtes basées sur les propriétés ainsi que pour la récupération des métadonnées nécessaires pour afficher les résultats finals. Si plusieurs partitions d’index existent, ces partitions peuvent être mappées à différentes bases de données de propriétés.

Détails d’échelle

Objet	Considérations d’échelle	RAM	IOPS (lecture/écriture)
Proxy de recherche	S’étend aux serveurs Web frontaux auxquels il est associé	N/A	N/A
Service de requête de recherche et de paramètres de site	Ce service, qui est installé sur la page Services sur le serveur dans l’Administration centrale, doit être démarré sur chaque serveur doté d’un composant de requête. Il peut être déplacé sur un serveur distinct (ou une paire pour une haute disponibilité) pour éviter d’utiliser la RAM sur les serveurs contenant les composants de requête. Par ailleurs, si un filtre de sécurité personnalisé est utilisé, cela peut affecter les ressources de CPU et de RAM.	Utilise de la RAM (cache de processus) pour la mise en cache des descripteurs de sécurité de l’index.	N/A
Partition d’index	L’augmentation du nombre de partitions d’index diminue le nombre d’éléments dans la partition d’index, ce qui réduit l’espace RAM et disque nécessaire sur le serveur de requêtes qui héberge le composant de requête attribué à la partition d’index.	N/A	N/A
composant de requête	Chaque composant de requête actif sur un serveur consomme de la mémoire pour le traitement des requêtes. Chaque composant de requête actif est créé ou modifié en tant que composant de la topologie d’une application de service de recherche. Les deux composants, actif et de basculement, consomment des E/S lorsque l’analyse a lieu. Des serveurs peuvent être dédiés aux composants de requête (par exemple, deux composants actif et deux composants de basculement sur le même serveur), en supposant que les exigences de RAM et E/S sont satisfaites. Si c’est possible, dédiez au moins deux cœurs de processeur par composant actif et par serveur, et au moins un cœur de processeur par composant de basculement et par serveur.	Pour chaque composant de requête actif sur un serveur d’applications, 33 % de son index doit se trouver en RAM (cache du système d’exploitation).	2 K requis par paire de composants de requête (actif/basculement) sur un serveur donné. Le composant de requête nécessite des E/S pour : Charger l’index en RAM pour les requêtes Écrire les fragments d’index reçus de chaque composant d’analyse Fusionner les fragments d’index dans son index, par exemple durant une fusion principale
Base de données d’administration de la recherche	Pour chaque requête, les meilleurs résultats et les descripteurs de sécurité sont chargés à partir de la base de données d’administration de la recherche. Assurez-vous que le serveur de bases de données possède suffisamment de RAM pour le traitement de celle-ci à partir du cache. Si possible, évitez de la placer sur un serveur hébergeant une base de données d’analyse, car cette dernière a tendance à réinitialiser le cache de son serveur.	Assurez-vous que le serveur de bases de données possède suffisamment de RAM pour conserver la table critique (MSSSecurityDescriptors) en RAM.	700
Base de données de propriétés	Pour chaque requête, des métadonnées sont extraites de la base de données de propriétés pour les résultats de documents, vous pouvez donc ajouter de la RAM au serveur de bases de données pour améliorer les performances. Si plusieurs partitions d’index existent, vous pouvez partitionner la base de données de propriétés et la déplacer vers un autre serveur de bases de données pour diminuer les exigences de RAM et d’E/S.	Assurez-vous que le serveur de bases de données possède suffisamment de RAM pour conserver 33 % des tables critiques (MSSDocSDIDs + MSSDocProps + MSSDocresults) en cache.	2 K 30 % lecture, 70% écriture

Système d’analyse de recherche

Cette section décrit les composants du système d’analyse de recherche. Les exigences de dimensionnement de chaque composant sont listées dans le tableau qui suit le diagramme.

Description des objets

Cette section définit les objets du système d’analyse de recherche du diagramme précédent :

• Composant d’administration   Un composant d’administration est utilisé au lancement d’une analyse ou quand une tâche d’administration est effectuée sur le système d’analyse.

• Composant d’analyse   Un composant d’analyse traite les analyses, propage les fichiers de fragments d’index obtenus aux composants de requête et ajoute des informations sur l’emplacement et la planification de l’analyse des sources de contenu à sa base de données d’analyse associée.

• Base de données d’administration de la recherche   La base de données d’administration de la recherche, qui est créée en même temps que l’application de service de recherche, stocke les descripteurs de sécurité découverts durant l’analyse, ainsi que les paramètres d’application utilisés pour l’administration.

• Base de données d’analyse   Une base de données d’analyse contient les données liées à l’emplacement des sources de contenu, aux planifications d’analyse, ainsi que d’autres informations propres aux opérations d’analyse. Vous pouvez dédier les bases de données d’analyse à des hôtes spécifiques en créant des règles de distribution des hôtes. Une base de données d’analyse ne stocke que des données. Le composant d’analyse qui lui est associé effectue l’analyse.

• Système de requête de recherche

Détails d’échelle

Objet	Considérations d’échelle	RAM	IOPS (facultatif, % lecture/écriture)
Composant d’administration	Le composant d’administration est unique et non déployable. Par défaut, il est situé sur un serveur qui héberge un composant d’analyse (et l’Administration centrale, sur les batteries plus petites).	Minime	Minime
Composant d’analyse	Les composants d’analyse utilisent la bande passante CPU de façon considérable. Idéalement, un composant d’analyse donné peut utiliser quatre cœurs de processeur. La consommation de RAM n’est pas aussi critique. Dans les batteries plus grandes, des serveurs dédiés à l’hébergement des composants d’analyse permettent de minimiser l’impact du robot sur les autres composants (particulièrement en utilisant des composants d’analyse associés à différentes bases de données d’analyse, si la redondance est requise).	Modéré. Notez que l’analyse de documents d’Asie de l’Est accroît les exigences de RAM à cause des césures de mots.	300-400
Base de données d’administration de la recherche	Voir Système de requête de recherche ci-dessus. Si possible, évitez de la placer sur un serveur hébergeant une base de données d’analyse, car cette dernière a tendance à réinitialiser le cache de son serveur.	Voir Système de requête de recherche ci-dessus.	700
Base de données d’analyse	Les bases de données d’analyse utilisent la bande passante E/S de façon considérable. La consommation de RAM n’est pas aussi critique. Une base de données d’analyse requiert 3,5 K d’E/S par seconde (IOPS) pour les activités d’analyse ; elle consommera jusqu’à 6 K d’E/S par seconde, selon la bande passante disponible.	Modéré	3,5 – 7 K 73 % lecture, 27 % écriture

Dimensionnement du stockage

Calculez les facteurs suivants afin d’évaluer vos besoins de stockage. Les facteurs de dimensionnement sont basés sur un système de prédéploiement interne avec un index qui contient le contenu d’origine de SharePoint (la taille des bases de données de contenu est de 13,3 téraoctets). Surtout, la recherche SharePoint requiert environ 20 % de l’espace disque des bases de données de contenu. Comme indiqué précédemment, assurez-vous de procéder à des tests dans votre propre environnement avant de déployer SharePoint Server 2010 dans un environnement de production.

Avertissements :

• Le corpus dont sont tirés ces nombres correspond principalement à du contenu SharePoint (en anglais), donc si votre contenu diffère (par exemple, il est constitué principalement de partages de fichiers ou de sites HTTP non SharePoint), vous devez vous attendre à des variations.

• Même si le contenu est essentiellement du contenu SharePoint, les coefficients peuvent varier dans les circonstances suivantes :

  • Si vous avez de grands référentiels de documents, les coefficients seront beaucoup plus grands.

  • Si le contenu est constitué principalement d’images, vous devez pouvoir réduire les coefficients.

  • Le contenu dans une langue différente affectera probablement les coefficients.

1. Calculez le facteur de dimensionnement des bases de données de contenu (ContentDBSum)

Déterminez la somme des bases de données de contenu SharePoint qui sera analysée. Il s’agit de la valeur ContentDBSum qui sera utilisée comme corrélation dans les calculs de stockage suivants.

2. Calculez les tailles d’index (TotalIndexSize et QueryComponentIndexSize)

Déterminez la taille de l’index total (qui est situé sur les composants de requête et est utilisé pour les requêtes de texte intégral) :

Multipliez ContentDBSum par 0,035. Vous obtenez la valeur TotalIndexSize avant de partitionner et réserver de l’espace pour les fusions et le repartitionnement.

Ensuite, déterminez le nombre de partitions d’index sur lequel sera basé votre scénario. En règle générale, une partition d’index devrait compter 5 à 10 millions d’éléments. Une fois le nombre de partitions d’index déterminé, vous pouvez calculer la taille de stockage du composant de requête.

• Divisez TotalIndexSize par le nombre de partitions d’index. Vous obtenez la valeur QueryComponentIndexSize qui permet de calculer les tailles suivantes :

  • Pour la RAM, multipliez QueryComponentIndexSize par 0,33. Vous obtenez la RAM minimum requise pour ce composant de requête, s’il est actif.

    • S’il s’agit d’un composant de basculement, il ne nécessite pas de RAM tant qu’il est inactif.

    • Pour un serveur donné, si vous avez plusieurs composants de requête actifs sur le même serveur, vous devez additionner la RAM de chaque composant de requête actif pour obtenir les besoins en RAM du serveur.

  • Pour le stockage disque, utilisez QueryComponentIndexSize comme suit pour estimer les besoins en disque, selon que vous envisagez de repartitionner ou non l’index (c’est-à-dire, si vous prévoyez une croissance de l’index supérieure à 10 millions par partition) :

    • Multipliez QueryComponentIndexSize par 3 pour calculer le stockage disque pour un seul composant de requête en laissant la place pour la fusion d’index.

    • Multipliez QueryComponentIndexSize par 4 pour calculer le stockage disque pour un seul composant de requête en laissant la place pour le repartitionnement d’index.

Pour un serveur donné, si vous avez plusieurs composants de requête sur le même serveur, vous devez prévoir le stockage pour chacun selon les besoins d’E/S par seconde répertoriés dans la section Détails d’échelle de la section Système de requête de recherche, plus haut dans cet article.

3. Calculez les tailles des bases de données de propriétés

Déterminez la taille des bases de données de propriétés de la manière suivante :

• Multipliez ContentDBSum par 0,015. Vous obtenez la valeur TotalPropertyDBSize avant partitionnement.

• Multipliez ContentDBSum par 0,0031. Vous obtenez la valeur TotalPropertyDBLogSize avant partitionnement. Cela suppose que vous utilisez le mode de récupération simple pour les bases de données SQL Server.

• Multipliez ContentDBSum par 0,00034. Vous obtenez la valeur TempDBSize de la base de données de propriétés. Comme il est recommandé que 33 % des tables clés de la base de données de propriétés soient en RAM, l’utilisation de la base de données temporaire est légère.

Ensuite, déterminez le nombre de bases de données de propriétés que vous aurez, en fonction de votre scénario. En règle générale, une base de données de propriétés devrait compter jusqu’à 50 millions d’éléments, en supposant qu’il n’y ait pas de problèmes de performances des requêtes et que vous n’ayez qu’un nombre limité de propriétés gérées (configuration standard).

• Divisez TotalPropertyDBSize par le nombre de bases de données de propriétés. Vous obtenez la valeur PropertyDatabaseSize.

• Divisez TotalPropertyDBLogSize par le nombre de bases de données de propriétés. Vous obtenez la valeur PropertyDatabaseLogSize.

• Pour la RAM, multipliez PropertyDatabaseSize par 0,33. Vous obtenez la quantité minimum de RAM recommandée pour cette base de données de propriétés.

Pour un serveur de bases de données particulier, si vous avez plusieurs bases de données de propriétés sur le même serveur, vous devez prévoir le stockage et la RAM pour chacune selon les besoins d’E/S par seconde et de RAM répertoriés dans la section Détails d’échelle de la section Système de requête de recherche, plus haut dans cet article.

4. Calculez les tailles des bases de données d’analyse

Ensuite, déterminez la taille nécessaire pour la base de données d’analyse comme suit :

• Multipliez ContentDBSum par 0,046. Vous obtenez la valeur TotalCrawlDBSize avant partitionnement.

• Multipliez ContentDBSum par 0,011. Vous obtenez la valeur TotalCrawlDBLogSize avant partitionnement. Cela suppose que vous utilisez le mode de récupération simple pour les bases de données SQL Server.

• Multipliez ContentDBSum par 0,0011. Vous obtenez la valeur TempDBSize de la base de données d’analyses. Comme le système d’analyse de recherche affecte les performances de la base de données temporaire, il est déconseillé de placer d’autres bases de données sur les serveurs qui hébergent la base de données d’analyse ou des bases de données qui seraient affectées par cela.

Ensuite, déterminez le nombre de bases de données d’analyse que vous aurez, en fonction de votre scénario. En règle générale, une base de données d’analyse devrait compter jusqu’à 25 millions d’éléments, en supposant qu’il n’y ait pas de problèmes de performances de l’analyse.

• Divisez TotalCrawlDBSize par le nombre de bases de données d’analyse. Vous obtenez la valeur CrawlDatabaseSize.

• Divisez TotalCrawlDBLogSize par le nombre de bases de données d’analyse. Vous obtenez la valeur CrawlDatabaseLogSize.

Pour un serveur donné, si vous avez plusieurs bases de données d’analyse sur le même serveur, vous devez prévoir le stockage pour chacune selon les besoins d’E/S par seconde répertoriés dans la section Détails d’échelle de la section Système d’analyse de recherche plus haut dans cet article. Pour la RAM, nous recommandons au moins 16 Go sur les serveurs de bases de données dédiés aux bases de données d’analyse.

5. Calculez la taille de la base de données d’administration de la recherche

Déterminez la taille de la base de données d’administration de la recherche (en supposant l’authentification Windows) comme suit :

• Multipliez le nombre d’éléments de l’index (en millions) par 0,3. Vous obtenez la valeur SearchAdminDBSize.

• Pour la RAM, multipliez SearchAdminDBSize par 0,33. Vous obtenez la quantité minimum de RAM recommandée pour cette base de données d’administration de la recherche.

Pour un serveur de bases de données particulier, si vous avez plusieurs bases de données sur le même serveur, vous devez prévoir le stockage et la RAM pour chacune selon les besoins d’E/S par seconde et de RAM répertoriés dans la section Détails d’échelle de la section Système de requête de recherche, plus haut dans cet article.

Facultatif : calculer la taille des sauvegardes

Pour déterminer l’espace disque requis pour sauvegarder une application de service de recherche, effectuez le calcul suivant :

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = taille de sauvegarde de base.

Cette taille de sauvegarde de base est un point de départ. Elle peut être affectée par les facteurs suivants :

• La taille d’index supplémentaire qui est incluse dans TotalIndexSize pour toute analyse effectuée depuis la dernière fusion principale.

• La croissance au cours du temps due à des éléments, des requêtes et des descripteurs de sécurité supplémentaires.

En outre, vous voudrez probablement conserver plusieurs sauvegardes de différents moments, et réserver également l’espace pour la prochaine sauvegarde.

Exercice de dimensionnement

Utilisant les facteurs de dimensionnement mentionnés précédemment, l’exercice de dimensionnement suivant concerne une batterie contenant 100 millions d’éléments qui doit traiter des requêtes principalement sur du contenu SharePoint. Partant du scénario de grande batterie, vous supposez les conditions suivantes :

• Dix partitions d’index logiques sont nécessaires pour prendre en charge les 100 millions d’éléments.

• Pour traiter les requêtes, 10 composants de requête actifs sont requis, un par partition d’index.

• La redondance d’interrogation étant importante, vous avez 10 composants de requête de basculement, un par partition d’index (situé sur un serveur différent par rapport au composant actif).

Pour déterminer les besoins de stockage et de RAM, procédez comme suit :

1. Dans une batterie de contenu SharePoint ayant plusieurs bases de données de contenu, ajoutez les bases de données de contenu que vous voulez analyser pour obtenir 20 téraoctets.

2. En utilisant le coefficient d’index ci-dessus, multipliez 20 téraoctets par 0,035 (coefficient d’index) pour obtenir 716,8 Go. Vous obtenez la valeur TotalIndexSize. Si vous n’aviez qu’une partition, cela correspondrait à la taille de l’index, au repos.

3. Divisez TotalIndexSize par le nombre de partitions : 716,8 Go / 10 = 71,68 Go. C’est la taille d’index requise par composant de requête (QueryComponentIndexSize), avec une partition d’index. La taille est la même pour les composants actifs ou de basculement.

4. Multipliez TotalIndexSize par 4 si vous comptez repartitionner. Sinon, multipliez TotalIndexSize par 3 pour prendre en charge les fusions principales. 71,68 Go * 4 = 286,72 Go. Il vous faut 286,72 Go disponibles sur le disque du serveur de requêtes pour prendre en charge un composant de requête. Si vous avez deux composants de requête sur le même serveur d’applications (comme dans la topologie actif/basculement recommandée pour les grandes batteries), vous aurez la configuration d’unités de disque suivante :

   1. Unité du système d’exploitation (taille standard).

   2. Système de stockage supplémentaire 1 : Partage du composant de requête 1 (taille = au moins 300 Go), utilisé pour le composant de requête actif à partir de la partition d’index 1.

   3. Système de stockage supplémentaire 2 : Partage du composant de requête 2 (taille = au moins 300 Go), utilisé pour le composant de requête de basculement (miroir) à partir de la partition d’index 2.

Limites logicielles

Le tableau suivant donne les limites logicielles imposées pour permettre une expérience de recherche acceptable.

Objet	Limite	Notes supplémentaires
Application de service de recherche SharePoint	Maximum recommandé de 20 par batterie. Maximum absolu de 256 applications de service au total.	Vous pouvez déployer plusieurs applications de service de recherche sur la même batterie de serveurs, car vous pouvez affecter des bases de données et des composants de recherche à des serveurs distincts.
Documents indexés	Maximum total recommandé de 10 millions d’éléments par partition d’index et de 100 millions d’éléments par application de service de recherche.	La recherche SharePoint prend en charge les partitions d’index, qui contiennent chacune un sous-ensemble de l’index de recherche entier. Le maximum recommandé est de 10 millions d’éléments pour une partition donnée. Le nombre d’éléments maximum recommandé global, y compris les personnes, les éléments de liste, les documents et les pages Web, est de 100 millions.
Partitions d’index	Maximum recommandé de 20 par application de service de recherche	Cette partition d’index est un sous-ensemble logique de l’index de l’application de service de recherche. La limite recommandée est de 20. L’augmentation du nombre de partitions d’index diminue le nombre d’éléments dans la partition d’index, ce qui réduit l’espace RAM et disque nécessaire sur le serveur de requêtes qui héberge le composant de requête attribué à la partition d’index. Cependant, cela peut affecter la pertinence car le nombre d’éléments dans la partition d’index est diminué. La limite stricte des partitions d’index est de 128.
Base de données de propriétés	Limite recommandée de 10 par application de service de recherche	La base de données de propriétés stocke les métadonnées des éléments de chaque partition d’index qui lui est associée. Une partition d’index ne peut être associée qu’à une seule banque de propriétés. La limite recommandée est de 10 par application de service de recherche, avec une limite stricte de 255 (comme pour les partitions d’index).
Bases de données d’analyse	La limite est de 32 bases de données d’analyse par application	La base de données d’analyse stocke les données d’analyse (y compris durée et statut) au sujet de tous les éléments qui ont été analysés. La limite recommandée est de 25 millions d’éléments par base de données d’analyse, ou quatre bases de données au total par application de service de recherche.
Composants d’analyse	La limite recommandée par application est de 16 composants d’analyse au total, dont deux par base de données d’analyse et deux par serveur, dans l’hypothèse où le serveur possède au moins huit processeurs (cœurs).	Le nombre total de composants d’analyse par serveur doit être inférieur à 128/(nombre total de composants de requête) pour réduire au minimum la dégradation des opérations d’E/S de propagation. Le dépassement de la limite recommandée peut ne pas se traduire par de meilleures performances d’analyse ; en fait, celles-ci peuvent diminuer suivant la disponibilité des ressources sur le serveur d’analyse, la base de données et l’hôte du contenu.
Composants de requête	La limite recommandée par application est de 128, avec 64/(nombre total de composants d’analyse) par serveur.	Le nombre total de composants de requête est limité par la capacité des composants d’analyse à copier les fichiers. Le nombre maximum de composants de requête par serveur est limité par la capacité des composants de requête à absorber les fichiers propagés à partir des composants d’analyse.
Analyses simultanées	Limite recommandée de 20 analyses par application de service de recherche	Il s’agit du nombre d’analyses en cours d’exécution en même temps. Les analyses sont des tâches de recherche extrêmement couteuses qui peuvent affecter la charge de base de données en plus de la charge d’autre application. Le dépassement de 20 analyses simultanées peut entraîner une diminution du taux d’analyse global.
Sources de contenu	Limite recommandée de 50 sources de contenu par application de service de recherche.	La limite recommandée peut être dépassée jusqu’à la frontière de 500 par application de service de recherche. Toutefois, vous devez utiliser moins d’adresses de démarrage et respecter la limite du nombre d’analyses simultanées.
Adresses de démarrage	Limite recommandée de 100 adresses de démarrage par source de contenu.	La limite recommandée peut être dépassée jusqu’à la frontière de 500 par source de contenu. Cependant, il est recommandé d’utiliser moins de sources de contenu. Une meilleure approche si vous avez beaucoup d’adresses de démarrage est de les placer sous forme de liens dans une page HTML et de faire analyser celle-ci par le robot HTTP, en suivant les liens.
Règles d’analyse	Limite recommandée de 100 par application de service de recherche	La recommandation peut être dépassée ; toutefois, cela se traduit par une dégradation de l’affichage des règles d’analyse dans l’administration de la recherche.
Journaux d’analyse	Limite recommandée de 100 millions par application	Il s’agit du nombre des différentes entrées du journal d’analyse. Ce nombre suit la limite des documents indexés.
Propriétés de métadonnées reconnues par élément	Limite stricte de 10 000.	Il s’agit du nombre de propriétés de métadonnées pouvant être déterminées (et éventuellement mappées et utilisées pour des requêtes) lorsqu’un élément est analysé.
Propriétés analysées	500 000 par application de service de recherche	Il s’agit des propriétés détectées pendant une analyse.
Propriétés gérées	100 000 par application de service de recherche	Il s’agit de propriétés qu’utilise le système de recherche dans les requêtes. Les propriétés analysées sont mappées aux propriétés gérées. Nous recommandons un maximum de 100 mappages par propriété gérée. Le dépassement de cette limite peut entraîner une diminution de la vitesse d’analyse et des performances des requêtes.
Étendues	Limite recommandée de 200 par site.	Il s’agit d’une limite recommandée par site. Le dépassement de cette limite peut réduire l’efficacité de l’analyse et affecter la latence du navigateur de l’utilisateur final si les étendues sont ajoutées au groupe d’affichage. En outre, l’affichage des étendues dans l’administration de la recherche se dégrade dès que le nombre d’étendues dépasse la limite recommandée.
Groupes d’affichage	25 par site	Les groupes d’affichage permettent d’obtenir un affichage groupé des étendues via l’interface utilisateur. Le dépassement de cette limite entraîne la dégradation de l’expérience des étendues dans l’administration de la recherche.
Règles d’étendue	Limite recommandée de 100 règles d’étendue par étendue et 600 au total par application de service de recherche.	Le dépassement de cette limite réduit le caractère actualisé et retarde les résultats potentiels des requêtes sur lesquelles porte la recherche.
Mots clés	Limite recommandée de 200 par collection de sites	La limite recommandée peut être dépassée jusqu’à la limite maximale de 5 000 (imposée par ASP.NET) par collection de sites sur la base de cinq meilleurs résultats par mot clé. L’affichage des mots clés dans l’interface utilisateur de l’administration du site s’en trouvera dégradé. Vous pouvez ajuster la limite imposée par ASP.NET en modifiant les fichiers Web.config et Client.config (MaxItemsInObjectGraph).
Pages de référence	La limite recommandée est une page de référence de niveau supérieur et aussi peu que possible de pages de deuxième et troisième niveau pour atteindre la pertinence désirée.	La limite stricte est 200 par niveau de pertinence et par application de service de recherche, mais l’ajout de pages ne permet pas forcément d’atteindre la pertinence désirée. Ajoutez le site clé au premier niveau de pertinence. Ajoutez les sites clés suivants au second ou troisième niveau de pertinence, un par un, et évaluez la pertinence après chaque ajout pour vous assurer que l’effet de pertinence désirée est obtenu.
Alertes	Limite recommandée de 1 000 000 par application de service de recherche	Il s’agit de la limite testée.
Suppression des résultats	100 URL en une opération	Il s’agit du nombre recommandé maximal d’URL à supprimer du système en une seule opération.

Optimisations

Les sections suivantes traitent des méthodes permettant d’améliorer les performances de la batterie.

De nombreux facteurs peuvent avoir un impact sur les performances. Ces facteurs comprennent le nombre d’utilisateurs, ainsi que le type, la complexité et la fréquence des opérations utilisateur, le nombre de publications dans une opération et les performances des connexions de données. Chacun de ces facteurs peut avoir un impact majeur sur le débit de la batterie. Vous devez étudier chacun avec soin lorsque vous planifiez le déploiement.

La capacité et les performances d’un système de recherche dépendent extrêmement de sa topologie. Vous pouvez soit monter en niveau soit en augmentant la capacité des ordinateurs serveurs existants soit monter en puissance en ajoutant des serveurs à la topologie.

Optimisations du système de requête de recherche

En général, les optimisations des requêtes de recherche suivent les scénarios suivants :

• Les utilisateurs se plaignent de la latence des requêtes, qu’il faut donc réduire.

• Beaucoup plus de requêtes de recherche que prévu se produisent et les performances se dégradent ; il faut donc augmenter le débit des requêtes.

La montée en niveau ou en puissance du sous-système de requêtes implique systématiquement la création de composants de requête supplémentaires. Si vous avez de la capacité excédentaire (RAM, E/S et CPU) sur un serveur de requêtes existant, vous pouvez choisir de monter en niveau en créant davantage de composants de requête sur ce serveur, en augmentant la RAM, la CPU ou les E/S si vous atteignez un goulot d’étranglement. Sinon, vous pouvez choisir de monter en puissance en créant davantage de composants de requête (ou de déplacer des composants existants) sur un nouveau serveur.

La section suivante montre diverses façons d’ajouter des ressources de requête à un système de requête de recherche.

Comment réduire la latence des requêtes

Ajout de composants de requête pour réduire la latence

Le graphique suivant illustre l’impact produit par l’ajout de composants de requête actifs sur différents serveurs sans changement de taille de l’index.

Ajoutez des composants de requête actifs supplémentaires pour maintenir une latence de requêtes inférieure à la seconde tandis que la charge utilisateur augmente sur le système (mesurée en nombre de requêtes utilisateur simultanées).

Ajout de processeurs de requêtes (Service de paramètres de site et de requête) pour réduire la latence

Le graphique suivant illustre l’impact produit par l’ajout de services processeurs de requêtes actifs sur différents serveurs sans changer aucune autre partie du système de requête.

Démarrez d’autres instances actives du Service de paramètres de site et de requête sur différents serveurs pour maintenir une latence de requêtes inférieure à la seconde tandis que la charge utilisateur augmente sur le système (mesurée en nombre de requêtes utilisateur simultanées).

Monter en puissance pour augmenter le débit des requêtes

Ajout de composants de requête pour augmenter le débit des requêtes

Le graphique suivant illustre l’impact produit par l’ajout de composants de requête actifs sur différents serveurs sans changement de taille de l’index.

Ajoutez des composants de requête actifs supplémentaires pour augmenter le débit des requêtes tandis que la charge utilisateur augmente sur le système (mesurée en nombre de requêtes utilisateur simultanées).

Ajout de processeurs de requêtes (Service de paramètres de site et de requête) pour augmenter le débit des requêtes

Le graphique suivant illustre l’impact produit par l’ajout de services processeurs de requêtes actifs sur différents serveurs sans changer aucune autre partie du système de requête.

Démarrez d’autres instances actives du Service de paramètres de site et de requête sur différents serveurs pour augmenter le débit des requêtes tandis que la charge utilisateur augmente sur le système (mesurée en nombre de requêtes utilisateur simultanées).

Optimisations du système d’analyse de recherche

En général, vous procédez à des optimisations du système d’analyse de recherche lorsque les utilisateurs se plaignent à propos de résultats manquants ou de résultats obsolètes dans les résultats affichés.

Lorsque vous essayez d’analyser l’adresse de démarrage d’une source de contenu dans un objectif d’actualisation, vous pouvez rencontrer les problèmes de performances d’analyse suivants :

• Le taux d’analyse est faible à cause de goulots d’étranglement des E/S par seconde dans le sous-système d’analyse de recherche.

• Le taux d’analyse est faible à cause d’un manque de threads CPU dans le sous-système d’analyse de recherche.

• Le taux d’analyse est faible à cause d’une réactivité lente du référentiel.

Chacun de ces problèmes part de l’hypothèse que le taux d’analyse est faible. Voir Utiliser les rapports d’administration de la recherche (SharePoint Server 2010) (étant donné les phases du cycle de vie logiciel) afin de définir une référence du taux d’analyse standard du système dans le temps. Lorsque cette référence régresse, les sous-sections suivantes vous indiquent différentes façons de résoudre ces problèmes de performances de l’analyse.

Goulot d’étranglement des E/S par seconde de l’analyse

Après avoir déterminé qu’une base de données d’analyse ou de propriétés représente un goulot d’étranglement, vous devez monter en niveau ou en puissance le système d’analyse pour résoudre ce problème en utilisant une solution appropriée. Le tableau suivant montre comment l’ajout d’E/S par seconde (une autre base de données d’analyse) améliore le taux d’analyse (jusqu’à ce que l’ajout de composants supplémentaires conduise à nouveau à un goulot d’étranglement).

Conseil : vérifiez systématiquement que la base de données d’analyse ne constitue pas le goulot d’étranglement. Si les E/S par seconde de la base de données d’analyse sont déjà en goulot d’étranglement, l’ajout de composants d’analyse ou l’augmentation du nombre de threads n’apportera aucune amélioration.

Topologie (Composant d’analyse/ Base de données d’analyse)	% CPU	RAM : % taux de réussite en cache tampon	Latence en lecture	Latence en écriture	Vitesse d’analyse (docs/s)
2 / 1	19,5	99,6	142 ms	73 ms	50
4 / 2	8,502	99,55	45 ms	75 ms	~75
6 / 2	22	99,92	55 ms	1 050 ms	~75

Goulot d’étranglement des threads CPU d’analyse

Si vous avez un grand nombre d’hôtes et pas d’autre goulot d’étranglement d’analyse, il vous faut monter en niveau ou en puissance le système d’analyse en utilisant une solution appropriée. Le robot peut prendre en charge 256 threads au maximum par application de service de recherche. Nous recommandons un processeur quadricœur pour tirer pleinement bénéfice du maximum de threads. Lorsqu’il est déterminé de façon décisive que le référentiel sert les données suffisamment rapidement (voir la section Goulot d’étranglement d’analyse sur le référentiel, plus loin dans cet article), le débit d’analyse peut être amélioré en accélérant les demandes de données du référentiel au moyen d’un plus grand nombre de threads du robot. Pour cela, vous pouvez procéder des trois façons suivantes :

1. Remplacez le niveau de performance de l’indexeur par Partiellement réduite ou Maximum à l’aide de l’applet de commande Windows PowerShell suivante :

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

     La valeur Maximum correspond à un processeur ayant moins de quatre cœurs.

2. Utilisez les règles d’impact du robot pour augmenter le nombre de threads par hôte. Il faut tenir compte du maximum de 256 threads pris en charge et du fait qu’attribuer un grand nombre de threads à quelques hôtes seulement pourrait ralentir la récupération des données d’autres référentiels.

3. Pour un grand nombre d’hôtes, la solution idéale consiste à ajouter un autre composant d’analyse sur une indexeur distinct afin d’analyser les hôtes devant être indexés plus vite.

Le moyen idéal d’augmenter de façon homogène le débit d’analyse est d’ajouter un autre indexeur si le sous-système de recherche ne subit pas de goulot d’étranglement en E/S par seconde et que le référentiel sert le contenu rapidement.

Goulot d’étranglement d’analyse sur le référentiel

Parfois, lorsqu’une application Web SharePoint avec beaucoup de collections de sites imbriquées ou de partages de fichiers distants est analysée, le robot de recherche peut rencontrer un goulot d’étranglement sur le référentiel. Ce type de goulot d’étranglement peut être identifié si les deux conditions suivantes sont vérifiées :

• L’utilisation CPU sur les serveurs d’analyse est faible (moins de 20 %).

• Il y a un grand nombre de threads en attente sur le réseau (presque tous dans le pire des cas).

  Le goulot d’étranglement est identifié en examinant le compteur de performances OSS Search Rassembleur/Threads accédant au réseau.

Dans cette situation, les threads sont bloqués en attente des données du référentiel. Dans un environnement avec beaucoup de sources de contenu, il peut être utile d’identifier l’hôte dont la réactivité est faible en mettant toutes les autres analyses en suspens, puis en effectuant une analyse qui utilise la source de contenu ayant l’hôte suspecté comme l’une de ses adresses de démarrage.

Lorsqu’un hôte problématique a été identifié, vous devez déterminer la cause de ces temps de réponse lents. Pour du contenu SharePoint en particulier, voir l’article Capacity management and sizing for SharePoint Server 2010.

Le débit d’analyse peut être considérablement amélioré en réglant les performances des référentiels de données analysés.

Résolution des problèmes d’échelle et de performances

Il est essentiel de connaître la charge sur la batterie de serveurs pour résoudre les problèmes de performances. La section suivante utilise les données d’une batterie de serveurs réelle contenant 60 millions d’éléments pour montrer diverses mesures du système à différentes phases du cycle de vie de la recherche.

Relevés de performances durant le cycle de vie de recherche

Mesure	Acquisition d’index	Maintenance d’index	Nettoyage d’index
CPU SQL Server (en %) Base de données de propriétés / Base de données d’analyse	14,8 / 19,13	35 / 55	11 / 63
Espérance de vie de page SQL Server Base de données de propriétés / Base de données d’analyse	60 548 / 5 913	83 366 / 5 373	33 927 / 2 806
Moyenne disque s/écriture SQL Server Base de données de propriétés / Base de données d’analyse	9 ms / 48 ms MAX : 466 ms / 1 277 ms	12 ms / 28 ms	20 ms / 49 ms MAX : 253 ms / 1 156 ms
Moyenne disque s/lecture SQL Server Base de données de propriétés / Base de données d’analyse	8 ms / 43 ms MAX : 1 362 ms / 2 688 ms	11 ms / 24 ms	24 ms / 29 ms MAX : 2 039 ms / 2 142 ms
CPU Robot (en %) Serveur d’index 1 (2 composants d’analyse) / Serveur d’index 2 (2 composants d’analyse)	18 / 11	25,76 / 21,62	8,34 / 7,49 Pics maximum à 99 %
Écritures disque/s Serveur d’index 1 (2 composants d’analyse) / Serveur d’index 2 (2 composants d’analyse)	64,32 / 42,35	93,31 / 92,45	99,81 / 110,98
Lectures disque/s Serveur d’index 1 (2 composants d’analyse) / Serveur d’index 2 (2 composants d’analyse)	0,23 / 0,20	4,92 / 2,03	1,38 / 1,97
Moyenne disque s/écriture Serveur d’index 1 (2 composants d’analyse) / Serveur d’index 2 (2 composants d’analyse)	11 ms / 11 ms	1 ms / 2 ms	5 ms / 4 ms MAX : 1 962 ms / 3 235 ms
Moyenne disque s/lecture Serveur d’index 1 (2 composants d’analyse) / Serveur d’index 2 (2 composants d’analyse)	1 ms / 2 ms	12 ms / 11 ms	10 ms / 16 ms MAX : 2 366 ms / 5 206 ms

Résolution des problèmes de performances des requêtes

La recherche SharePoint comprend un pipeline de requête instrumenté et des rapports d’administration associés pour vous aider à résoudre les problèmes de performances des requêtes sur le serveur. Pour plus d’informations, voir Utiliser les rapports d’administration de la recherche (SharePoint Server 2010). Cette section présente des rapports et montre comment ils permettent de déterminer la solution des problèmes de performances sur le serveur. En outre, cette section contient des outils et des conseils pour vous aider à résoudre les problèmes de performances sur le client (navigateur).

Problèmes de requête sur le serveur

Les problèmes de performances des requêtes sur le serveur peuvent être répartis sur les deux niveaux suivants :

• Problèmes de performances de recherche en frontal

• Problèmes de performances de recherche en dorsal

Les deux sous-sections suivantes détaillent le dépannage dans ces deux cas. Notez qu’il s’agit d’instructions générales.

Problèmes de performances en frontal

La première étape pour résoudre des problèmes de performances de recherche en frontal consiste à examiner le rapport d’administration de recherche Latence de requête globale. En voici un exemple :

Dans ce rapport, les performances en frontal sont représentées par les séries de données suivantes :

• Rendu serveur : représente, pour la minute indiquée, le temps moyen passé par requête dans les divers composants WebPart de recherche sur le serveur Web frontal.

• Modèle d’objet : représente, pour la minute indiquée, le temps moyen passé en communication entre le serveur Web frontal et le serveur dorsal de recherche.

Résolution des problèmes de rendu serveur

Les problèmes de rendu serveur peuvent être dus à toute chose se produisant sur le serveur Web frontal qui sert la page des résultats de la recherche. En général, vous souhaitez savoir combien de temps prend la récupération des divers composants WebPart pour déterminer où s’ajoute la latence supplémentaire. Activez le Tableau de bord du développeur (éventuellement en anglais) sur la page des résultats de la recherche pour un rapport détaillé sur la latence. Parmi les problèmes courants qui se manifestent par une latence de rendu serveur excessive, citons notamment :

• Des problèmes de plateforme tels que :

  • Recherches Active Directory lentes

  • Temps de réponse SQL Server lents

  • Requêtes à l’application de profils utilisateur lentes dans les requêtes de personnes de SharePoint Server 2010 ou dans toutes les requêtes de FAST Search Server 2010 for SharePoint

  • Requêtes d’extraction des préférences utilisateur lentes

  • Appels d’obtention du jeton utilisateur lents auprès du service d’émission de jetons de sécurité

• Problèmes de code-behind tels que des pages de résultats de recherche modifiées (comme results.aspx et peopleresults.aspx) qui sont archivées mais non publiées.

Résolution des problèmes liés au modèle d’objet

Les problèmes liés au modèle d’objet peuvent être provoqués par :

• Des problèmes avec la couche Windows Communication Foundation (WCF) tels que :

  • Des délais d’expiration et des exceptions threadabortexception au sein d’appels WCF dans le déploiement.

  • Une communication lente entre le serveur Web frontal et le serveur d’applications. Cela peut être dû à des problèmes IPsec ou à des connexions réseau lentes.

• Des problèmes de communication entre les batteries de contenu et de services (si elles sont configurées).

Problèmes de performances en dorsal

La première étape pour résoudre des problèmes de performances des requêtes en dorsal consiste à examiner le rapport d’administration de recherche Latence des requêtes du serveur principal SharePoint. En voici un exemple :

Dans ce rapport, les performances du serveur dorsal sont représentées par les séries de données suivantes (chacune représente le temps moyen passé par requête, pour la minute indiquée), regroupées par composant fonctionnel :

• Composant de requête :

  • Requête en texte intégral : temps moyen passé à interroger l’index de texte intégral pour les résultats.

• Base de données de propriétés :

  • Extraction de résultats multiples : temps moyen passé à extraire des métadonnées de document, telles que le titre ou l’auteur, qui doivent apparaître dans les résultats de la requête.

  • Requête de banque de propriétés : temps moyen passé à interroger la base de données de propriétés pour les requêtes basées sur les propriétés.

• Base de données d’administration de la recherche :

  • Meilleurs résultats : temps moyen passé à déterminer si de meilleurs résultats existent pour les termes de la requête.

  • Résultats à niveau de confiance élevé : temps moyen passé à extraire des résultats de niveau de confiance élevé pour les requêtes.

• Processeur de requêtes :

  • Filtrage de sécurité : temps moyen passé à supprimer des éléments auxquels l’utilisateur n’a pas accès.

  • Suppression des doublons : temps moyen passé à supprimer les doublons.

  • Renseignement des résultats : temps moyen passé à la création de la table en mémoire transmise au modèle objet.

Résolution des problèmes de performances des composants de requête

Les composants de requête sont gourmands en ressources, surtout lorsque le composant est actif — c’est-à-dire, lorsqu’il répond aux demandes de requêtes. La résolution des problèmes de performances des composants de requête est l’une des plus compliquées. Voici les pistes générales à investiguer :

• L’événement le plus consommateur de ressources d’un composant de requête est la fusion principale, où les index secondaires sont fusionnés avec l’index principal. Cet événement se produit de manière indépendante pour chaque composant de requête. Un exemple de cet impact peut être observé sur le rapport Latence des requêtes du serveur principal SharePoint mentionné précédemment, sur la période avant 13:30:00. Si cet événement affecte la latence des requêtes, il est possible de définir des périodes de censure durant lesquelles la fusion principale est évitée sauf si le pourcentage de changements dépasse la limite définie.

• Si des valeurs élevées prolongées existent pour l’environnement, il vous faut probablement effectuer les opérations suivantes :

  • Examinez la taille de l’index pour chaque composant sur le serveur. Assurez-vous que le serveur contient suffisamment de RAM pour permettre la mise en cache d’environ 33 % de la somme des tailles d’index.

  • Examinez le canal des E/S des composants de requête sur le serveur. Assurez-vous qu’il n’y ait aucun goulot d’étranglement des E/S.

  • Si les E/S et la RAM ne sont pas à l’origine des problèmes de performances, vous devriez repartitionner les composants de requête (en ajoutant des partitions d’index) et ajouter les composants de requête supplémentaires sur de nouveaux serveurs.

Résolution des problèmes de base de données de propriétés

Examinez l’intégrité SQL Server en utilisant les concepts décrits dans Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Si vous exécutez des requêtes personnalisées, vous pouvez consulter les conseils afin de les planifier correctement.

Résolution des problèmes de base de données d’administration de la recherche

Examinez l’intégrité SQL Server en utilisant les concepts décrits dans Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Résolution des problèmes de processeur de requêtes

La résolution des problèmes de processeur de requêtes dépend du domaine du processeur de requêtes qui affecte la latence des requêtes ; ce domaine est l’un des suivants :

• Filtrage de sécurité :

  • Pour les revendications Windows, examinez la connexion Active Directory du serveur qui héberge le processeur de requêtes.

  • Dans tous les cas, la taille du cache utilisé par le processeur de requêtes peut être augmentée s’il y a corrélation avec un grand nombre d’aller-retour SQL Server (déterminé par le générateur de profils SQL Server). Plus de 25 % des requêtes ne devraient pas nécessiter d’appel SQL Server pour récupérer les descripteurs de sécurité à partir de la base de données d’administration de la recherche. Si ce n’est pas le cas, réglez la taille du cache du processeur de requêtes.

• Suppression des doublons :

  • Regardez si vous analysez le même contenu en plusieurs endroits. Désactivez la détection des doublons dans le Centre de recherche.

• Extraction de résultats multiples :

  • Examinez l’intégrité SQL Server en utilisant les concepts décrits dans Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

Problèmes de requête sur le serveur :

Les utilisateurs peuvent être ravis ou au contraire exaspérés par la vitesse d’obtention des résultats de la recherche. Le temps de chargement des pages est l’un des facteurs importants de la satisfaction des utilisateurs à propos de l’expérience de recherche. La question du temps de chargement des pages concerne en majeure partie le serveur, en particulier le temps que le serveur met à retourner les résultats. L’affichage côté client, cependant, peut constituer une part significative du temps de chargement des pages ; il est donc important d’en tenir compte.

L’expérience utilisateur de la recherche est conçue pour fournir des temps de réponse inférieurs à la seconde pour le temps de chargement des pages total. Hormis ce temps, l’affichage client prend généralement moins de 280 millisecondes, selon le navigateur et les mesures de rendu. Cette expérience ravit les utilisateurs car les résultats sont très rapides.

Les personnalisations apportées à l’expérience des résultats peuvent facilement dégrader les performances de l’affichage. Les administrateurs de recherche et les développeurs doivent être vigilants dans les mesures du temps d’affichage après chaque modification afin de s’assurer que les performances n’ont pas diminué de manière significative. Chaque ajout à la page, que ce soit un nouveau composant WebPart ou un nouveau style de feuille de style en cascade, augmente le temps d’affichage dans le navigateur et retarde les résultats pour les utilisateurs. L’ampleur du retard, cependant, peut varier considérablement selon que vous respectez ou non les pratiques recommandées lorsque vous personnalisez la page.

Voici quelques conseils généraux :

• Les personnalisations de base ou de style apportées à la page ne doivent pas rajouter plus de 25 ms environ au temps de chargement de page. Mesurez le temps de chargement de page avant et après l’implémentation des personnalisations pour observer le changement.

• Les utilisateurs remarquent généralement un changement (plus rapide ou plus lent) par incrément de 20 %. Gardez cela à l’esprit lorsque vous apportez des modifications. 20 % du temps d’affichage standard ne représente que 50 ms. (Source : Designing and Engineering Time (éventuellement en anglais)).

• Les feuilles de style en cascade et JScript sont les causes les plus courantes et les plus grandes des performances d’affichage élevées. Si vous personnalisez des feuilles de style en cascade et du code JScript, veillez à ce que cela se limite à un seul fichier de chaque type.

• JScript peut se charger à la demande après l’affichage de la page afin de fournir plus tôt à l’utilisateur des résultats visibles. Les détails sur la manière de procéder sont décrits dans l’article à propos des considérations sur les performances.

• Plus vous ajoutez des personnalisations à la page, plus son chargement sera lent. Considérez si la fonctionnalité et le style ajoutés justifient ce délai supplémentaire des résultats pour les utilisateurs.

Outre ces directives, vous trouverez énormément d’informations sur Internet sur la façon de réduire le temps de chargement des pages et à propos de l’impact des pages lentes sur l’expérience utilisateur.

Résolution des problèmes de performances d’analyse

La recherche SharePoint peut subir des goulots d’étranglement dans le sous-système d’analyse lorsque le système passe par les phases d’acquisition, de maintenance et de suppression d’index. Pour résoudre efficacement les problèmes de performances de l’analyse, vous devez utiliser les rapports Analyse du fonctionnement de la recherche avec les instructions de la section Goulots d’étranglement courants et leurs causes, plus loin dans cet article, afin d’isoler les problèmes d’analyse.

Résolution des problèmes de la phase d’acquisition d’index

Le rapport d’intégrité Taux d’analyse par source de contenu est le premier endroit où identifier les problèmes d’analyse. Comme montré plus loin dans cet article, ce rapport donne un aperçu du taux d’analyse de chaque source de contenu du système. En général, le taux d’analyse doit être supérieur à 15 documents/s pour une source de contenu de personnes et à 35 documents/s pour tous les autres types de sources de contenu.

Lorsqu’une source de contenu ayant un taux d’analyse réduit est identifiée, nous recommandons de procéder comme suit :

1. Suspendez toutes les autres analyses excepté celle de la source de contenu en examen. Le taux d’analyse a-t-il progressé au-delà de l’objectif de 15 à 35 documents/s ?

2. Si l’étape précédente n’est pas concluante, assurez-vous que le référentiel analysé est suffisamment réactif et n’est pas la cause de la lenteur d’analyse. Voir la section Goulot d’étranglement d’analyse sur le référentiel, plus haut dans cet article.

3. Si le référentiel n’est pas la cause du goulot d’étranglement, identifiez le goulot sur le serveur d’analyse ou sur le serveur de bases de données et procédez à l’optimisation sur le serveur concerné. Vous trouverez les instructions dans les sections Goulot d’étranglement des E/S par seconde de l’analyse et Goulot d’étranglement des threads CPU d’analyse, plus haut dans cet article.

Résolution des problèmes de la phase de maintenance d’index

Le but principal durant la phase de maintenance de l’index est de maintenir l’index le plus actualisé possible. Les deux indicateurs clés sont les suivants :

• Actualisation de l’index : Les analyses se terminent-elles dans le temps imparti et conformément aux directives informatiques quant à l’actualisation de l’index ?

• Vitesse d’analyse incrémentielle : Si l’objectif d’actualisation de l’index n’est pas atteint, recherchez si les vitesses d’analyse incrémentielle sont de 10 documents/s pour les sources de contenu de personnes et de 35 documents/s pour toutes les autres sources de contenu. Si les vitesses d’analyse incrémentielle sont réduites, il faut procéder à une analyse de goulot d’étranglement sur le référentiel analysé et le sous-système d’analyse, comme décrit ci-dessus.

Goulots d’étranglement courants et leurs causes

Durant les tests de performances, plusieurs goulots d’étranglement courants ont été révélés. Un goulot d’étranglement est une condition où la capacité d’un composant spécifique d’une batterie est atteinte, ce qui provoque une stabilisation ou une diminution du débit de la batterie.

Le tableau suivant répertorie certains goulots d’étranglement courants et décrit leurs causes et les résolutions possibles.

Goulot d’étranglement	Symptôme (compteur de performances)	Solution
RAM de bases de données	Base de données de propriétés, Base de données d’administration de la recherche : Gestionnaire de tampons SQL Server/Espérance de vie de page < 300 s (devrait être > 1000 s) Gestionnaire de tampons SQL Server/Taux de réussite en cache tampon < 96 % (devrait être > 98 %)	Ajoutez de la mémoire au serveur de bases de données. Défragmentez la base de données de propriétés, si la règle de défragmentation hebdomadaire est désactivée. Assurez-vous d’utiliser l’édition SQL Server 2008 Enterprise pour permettre la compression de page. Déplacez la base de données de propriétés sur un serveur distinct et ajoutez plusieurs bases de données de propriétés, si nécessaire.
E/S par seconde du serveur de bases de données	Une base de données d’analyse ou de propriétés présente les résultats suivants : Moyenne disque s/lecture et Moyenne disque s/écriture ~50 ms ou > 50 ms	Assurez-vous que le serveur de bases de données possède suffisamment de RAM pour conserver 33 % des tables critiques (MSSDocSDIDs + MSSDocProps + MSSDocresults) en cache. Augmentez nombre d’E/S par seconde dédié à la base de donnée de la façon suivante : Utilisez différentes baies de stockage Optimisez la configuration du stockage, par exemple en ajoutant des piles de disques (unités de disque) à la baie de stockage. Exécutez la règle de l’analyseur d’intégrité SharePoint Rechercher - Une ou plusieurs bases de données de propriétés contiennent des index fragmentés, si elle a été désactivée. Exécutez la règle de l’analyseur d’intégrité SharePoint Rechercher - Une ou plusieurs bases de données d’analyse peuvent contenir des index fragmentés. Assurez-vous d’utiliser l’édition SQL Server 2008 Enterprise pour permettre la compression de page. Déplacez la base de données sur un serveur distinct et ajoutez plusieurs bases de données de propriétés et/ou bases de données d’analyse, si nécessaire.
E/S par seconde de composant de requête	Le disque logique utilisé pour l’index d’un composant de requête présente les résultats suivants : Moyenne disque s/lecture et Moyenne disque s/écriture ~30 ms ou > 30 ms pendant une période prolongée (c.-à-d., la plupart de la journée, pas seulement durant une fusion d’index).	Assurez-vous que chaque serveur d’applications ait suffisamment de RAM pour conserver 33 % de l’index de chaque composant de requête actif (sur ce serveur) en cache (cache du système d’exploitation). Augmentez nombre d’E/S par seconde dédié à l’unité utilisée pour l’index du composant de requête de la façon suivante : Utilisez différentes baies de stockage pour les différents composants. Optimisez la configuration du stockage, par exemple en ajoutant des piles de disques (unités de disque) à la baie de stockage.

À propos de l’auteur

Brion Stone est responsable senior de programme SharePoint Server Search chez Microsoft.