Planifier l’architecture de recherche d’entreprise dans SharePoint Server 2016

 

**Sapplique à :**SharePoint Server 2016

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

Résumé : Découvrez comment planifier une architecture de recherche de contenu d’entreprise.

Avant de configurer votre architecture de recherche de contenu d’entreprise, un certain nombre d’éléments doivent être planifiés. Étape par étape, nous allons vous aider à planifier une architecture de recherche de contenu d’entreprise de petite, moyenne, grande ou très grande taille.

Connaissez-vous les composants du système de recherche dans SharePoint Server et la façon dont ils interagissent ? Avant de continuer, lisez la rubrique Vue d’ensemble de l’architecture de recherche dans SharePoint Server et le document Architectures de recherche pour SharePoint Server 2016 (ou Architectures de recherche pour SharePoint Server 2013) pour apprendre à connaître l’architecture de recherche, les composants de recherche, les bases de données de recherche et la topologie de recherche. Si vous souhaitez mettre en place une architecture de recherche, prenez en considération les éléments suivants :

  1. Étape 1 : Quel est le volume de contenu dont je dispose ?

  2. Étape 2 : Quelle taille d'architecture de recherche pour quel volume de contenu ?

  3. Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?

    • Choisir d’exécuter des serveurs physiques ou virtuels

    • Choisir les ressources matérielles pour les serveurs hôtes

    • Planifier les performances de stockage

    • Choisir le mode de prise en charge de la haute disponibilité dans votre architecture de recherche

  4. Étape 4 : Comment vérifier que mon architecture de recherche fonctionne correctement ?

    • Tester le sous-système d’E/S de stockage

    • Tester les performances de recherche

Étape 1 : Quel est le volume de contenu dont je dispose ?

Le volume de contenu dont vous disposez dans votre index de recherche a une incidence sur les ressources dont vous avez besoin pour héberger la batterie. Déterminez approximativement le nombre d’éléments que vous prévoyez de rendre disponibles pour la recherche. Voici quelques exemples d’éléments : documents, pages web, entrées de liste SharePoint et images. N’oubliez pas que chaque entrée d’une liste SharePoint est considérée comme un élément.

Lorsque vous avez déterminé ce nombre, multipliez-le par la croissance prévisionnelle attendue de ce contenu sur les 12 prochains mois.

Par exemple, si vous débutez avec 12 000 éléments indexés et que vous vous attendez à ce que le volume de ce contenu triple sur les 12 prochains mois, vous devez planifier votre architecture sur la base de 36 000 éléments de recherche.

Étape 2 : Quelle taille d’architecture de recherche pour quel volume de contenu ?

Il n’est pas toujours facile d’évaluer la taille que doit avoir votre architecture de recherche. Celle-ci dépend du volume de votre contenu, du taux d’analyse, du débit de requête et du niveau de haute disponibilité requis. Il existe des exemples d’architectures de recherche que nous vous recommandons d’utiliser comme bases pour votre propre batterie. L’exemple d’architecture de recherche à utiliser dépend du volume du contenu pouvant faire l’objet d’une recherche :

Volume de contenu (SharePoint 2016) Exemple d’architecture de recherche Volume de contenu (SharePoint 2013)

0 à 20 millions d’éléments

Batterie de recherche de petite taille

0 à 10 millions d’éléments

0 à 80 millions d’éléments

Batterie de recherche de taille moyenne

0 à 40 millions d’éléments

0 à 200 millions d’éléments

Batterie de recherche de grande taille

0 à 100 millions d’éléments

0 à 500 millions d’éléments

Batterie de recherche de très grande taille

Non pris en charge

Même si ces exemples d’architectures de recherche utilisent des machines virtuelles, vous pouvez utiliser à la fois des serveurs physiques et des machines virtuelles selon la stratégie de la solution SharePoint Server globale de votre architecture de recherche.

Batterie de recherche de petite taille

Nous estimons que cette architecture de recherche permet d’analyser 50 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous avez moins de 20 millions d’éléments dans une ferme SharePoint Server 2016, la batterie de recherche de petite taille est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 50 documents par seconde, une recherche de 110 heures est nécessaire pour analyser 20 millions d’éléments lors de la première analyse complète.

Diagram of the servers and search components in the small enterprise search architecture sample

Batterie de recherche de taille moyenne

Nous estimons que cette architecture de recherche permet d’analyser 100 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous disposez de 20 à 80 millions d’éléments dans une batterie SharePoint Server 2016, la batterie de recherche de taille moyenne est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 200 documents par seconde, une recherche de 280 heures est nécessaire pour analyser 80 millions d’éléments lors de la première analyse complète.

Diagram of the servers and search components in the medium enterprise search architecture sample

Batterie de recherche de grande taille

Nous estimons que cette architecture de recherche permet d’analyser 200 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Si vous disposez de 80 à 200 millions d’éléments dans une batterie SharePoint Server 2016, la batterie de recherche de grande taille est probablement la plus adaptée à vos besoins. Avec un taux d’analyse de 200 documents par seconde, une recherche de 280 heures est nécessaire pour analyser 200 millions d’éléments lors de la première analyse complète.

Diagram of the servers and search components in the large enterprise search architecture sample

Batterie de recherche de très grande taille

Microsoft a testé cette architecture de recherche et a mesuré qu’elle permet d’analyser entre 300 et 500 documents par seconde et de répondre aux ordres de 10 requêtes par seconde. Seul SharePoint Server 2016 prend en charge les architectures de recherche de cette taille. Si vous avez jusqu’à 500 millions d’éléments, une batterie comparable à la batterie de recherche de très grande taille est un bon point de départ. Avec un taux d’analyse de 500 documents par seconde, une recherche de 300 heures est nécessaire pour analyser 500 millions d’éléments lors de la première analyse complète.

La création d’une batterie de recherche de cette taille nécessite de planifier et régler soigneusement la batterie afin d’obtenir les performances souhaitées. Des conseils d’experts peuvent être profitables. Il est également important de planifier la sauvegarde et la restauration d’une batterie de recherche de cette taille, ainsi que la récupération de la batterie si votre centre de données subit une panne importante. Nous vous recommandons de vous entraîner à exécuter des procédures de sauvegarde, de restauration et de récupération.

Diagram of the servers and search components in the extra large enterprise search sample.

Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?

Maintenant que vous avez déterminé le volume de votre contenu et choisi un exemple d’architecture de recherche, la prochaine étape consiste à planifier le matériel dont vous avez besoin, comme décrit dans cette section :

  • Choisir d'exécuter des serveurs physiques ou virtuels

  • Choisir les ressources matérielles pour les serveurs hôtes

    • Stockage global

    • Ressources matérielles minimales pour la batterie de recherche de petite taille

    • Ressources matérielles minimales pour la batterie de recherche de taille moyenne

    • Ressources matérielles minimales pour la batterie de recherche de grande taille

    • Ressources matérielles minimales pour la batterie de recherche de très grande taille

  • Planifier les performances de stockage

    • Choisir le stockage

      • Besoins en IOPS des composants de recherche

      • Besoins en IOPS des bases de données de recherche

  • Choisir le mode de prise en charge de la haute disponibilité dans votre architecture de recherche

Choisir d’exécuter des serveurs physiques ou virtuels

Si vous utilisez l’une des architectures que nous avons évaluées pour vous, vous allez exécuter votre architecture de recherche sur des machines virtuelles. Notez également que même si un environnement virtuel est plus facile à gérer, son niveau de performances peut parfois être légèrement inférieur à celui d’un environnement physique. Un serveur physique peut héberger davantage de composants de recherche sur le même serveur qu’un serveur virtuel. Vous trouverez des conseils utiles dans Vue d’ensemble des architectures et de la virtualisation de batterie de serveurs pour SharePoint 2013.

Il est également possible d’exécuter votre architecture de recherche sur des serveurs physiques. Dans l’exemple d’architecture de batterie de serveurs, il suffit de déplacer les composants de recherche des machines virtuelles sur le serveur hôte et d’enlever les machines virtuelles. Chaque serveur physique peut héberger jusqu’à quatre composants d’index, mais seulement un de chaque type des autres composants de recherche. Par exemple, si vous modifiez l’exemple d’architecture de recherche de taille moyenne pour utiliser des serveurs physiques, vous vous apercevrez que vous avez deux composants de traitement du contenu sur l’hôte E. La solution consiste à enlever un des composants de traitement du contenu. Cela fonctionne car l’analyse, le traitement du contenu et le traitement des analyses dépendent de la quantité de ressources disponibles, et non du nombre de composants affectés à cette tâche.

Choose to run the servers physically or virtually

Choisir les ressources matérielles pour les serveurs hôtes

Chaque composant de recherche et base de données de recherche a besoin d’une quantité minimale de ressources matérielles du serveur hôte pour fonctionner correctement. Cependant, plus vous avez de ressources matérielles, plus les performances de votre architecture de recherche seront bonnes. Il est donc judicieux de disposer de plus de ressources matérielles que le minimum requis. Les ressources que chaque composant de recherche exige dépendent de la charge de travail, qui est la plupart du temps déterminée par le taux d’analyse, le taux de requête et le nombre d’éléments indexés.

Par exemple, en cas d’hébergement de machines virtuelles sur Windows Server 2008 R2 Service Pack 1 (SP1), vous ne pouvez pas utiliser plus de quatre cœurs de processeur par machine virtuelle. Avec Windows Server 2012 ou une version ultérieure, vous utilisez au moins huit cœurs de processeur par machine virtuelle. Vous pouvez alors effectuer une mise à l’échelle horizontale avec plus de cœurs de processeur pour chaque machine virtuelle au lieu d’effectuer une mise à l’échelle verticale avec plus de machines virtuelles. Configurez des serveurs ou des machines virtuelles qui hébergent les mêmes composants de recherche, avec les mêmes ressources matérielles. Prenons le composant d’index comme exemple. Lorsque vous hébergez des partitions d’index sur des machines virtuelles, la machine virtuelle ayant les performances les plus faibles détermine les performances de l’architecture de recherche globale.

Stockage global

Veillez à ce que chaque serveur hôte dispose d’un espace disque suffisant pour l’installation de base du système d’exploitation Windows Server et des fichiers de programme SharePoint Server. Le serveur hôte doit aussi disposer d’un espace disque supplémentaire pour les fonctions de diagnostic, telles que la journalisation, le débogage et la création de fichiers de vidage de la mémoire, pour les opérations quotidiennes et pour le fichier d’échange. Normalement, 80 Go d’espace disque sont suffisants pour le système d’exploitation Windows Server et pour les fichiers de programme SharePoint Server.

Ajoutez du stockage pour l’espace du journal SQL de chaque serveur de base de données. Si vous ne définissez pas le serveur de base de données pour sauvegarder les bases de données régulièrement, l’espace du journal SQL utilise beaucoup de stockage. Pour plus d’informations sur le mode de planification des bases de données SQL, reportez-vous à la rubrique Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server).

Le stockage minimal nécessaire pour la base de données de création de rapports d’analyse peut varier, car la quantité de stockage dépend de la façon dont les utilisateurs interagissent avec SharePoint Server. Lorsque les utilisateurs interagissent souvent, il y a généralement plus d’événements à stocker. Vérifiez la quantité de stockage utilisée par votre architecture de recherche actuelle pour la base de données d’analyse, et affectez au moins cette quantité à votre topologie redéfinie.

Ressources matérielles minimales pour la batterie de recherche de petite taille

Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d’applications ou serveur de bases de données.

Serveur Hôte Stockage Mémoire RAM Processor1 Bande passante réseau

Serveur d’applications avec composants d’index et de traitement des requêtes.

A, B

500 Go2,3

32 Go2,3

1,8 GHz 8 cœurs d’UC2,3

1 Gbit/s

Serveur d’applications avec composants de traitement analytique et de contenu, d’administration de la recherche et d’analyse.

A, B

200 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveur de bases de données avec toutes les bases de données de recherche.

C, D

100 Go

16 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une SharePoint Server 2013 batterie de serveurs de recherche.

Ressources matérielles minimales pour la batterie de recherche de taille moyenne

Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d’applications ou serveur de bases de données.

Serveur Hôte Stockage Mémoire RAM Processor1 Bande passante réseau

Serveur d’applications avec composants d’index et de traitement des requêtes .

A, B, C, D

500 Go2,3

32 Go2,3

1,8 GHz 8 cœurs d’UC2,3

1 Gbits/s

Serveur d’applications avec un composant d’index.

A, B, C, D

500 Go2,3

32 Go2,3

1,8 GHz 8 cœurs d’UC2,3

1 Gbit/s

Serveur d’applications avec composants de traitement analytique et de contenu.

E, F

300 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveur d’applications avec composants de traitement de contenu, d’administration de la recherche et d’analyse.

E, F

100 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveur de bases de données avec toutes les bases de données de recherche.

G, H

400 Go

16 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une SharePoint Server 2013 batterie de serveurs de recherche.

Ressources matérielles minimales pour la batterie de recherche de grande taille

Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d’applications ou serveur de bases de données.

Serveur Hôte Stockage Mémoire RAM Processor1 Bande passante réseau

Serveur d’applications avec composants d’index et de traitement des requêtes .

A, B, C, D, E, G, H

500 Go2, 3

32 Go2, 3

1,8 GHz 8 cœurs d’UC2, 3

1 Gbit/s

Serveur d’applications avec un composant d’index.

A, B, C, D, E, F, G, H, I, J

500 Go2, 3

32 Go2, 3

1,8 GHz 8 cœurs d’UC2, 3

1 Gbit/s

Serveurs d’applications avec composants de traitement analytique et de contenu.

K, L, M, N

300 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveurs d’applications avec composants d’administration de la recherche et d’analyse.

K, L

100 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveurs contenant des bases de données de recherche.

O, P, Q, R

500 Go

16 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.

2Avec SharePoint Server 2013 la quantité minimale de ressources requises est de 500 Go de RAM, 16 Go de RAM et quatre cœurs d’UC.

3Avec SharePoint Server 2016 vous pouvez également utiliser un espace de stockage de 500 Go, 16 Go de RAM et quatre cœurs d’UC, mais chaque composant d’index ne peut contenir que 10 millions d’éléments et la batterie de serveurs de recherche prend uniquement en charge le même volume de contenu qu’une SharePoint Server 2013 batterie de serveurs de recherche.

Ressources matérielles minimales pour la batterie de recherche de très grande taille

Ce tableau indique la quantité minimale de ressources matérielles dont a besoin chaque serveur d’applications ou serveur de bases de données. Vous pouvez seulement créer cet exemple de batterie de serveurs avec SharePoint Server 2016.

Serveur Hôte Stockage Mémoire RAM Processor1 Bande passante réseau

Serveur d’applications avec des composants d’index.

A-X

500 Go

32 Go

1,8 GHz 8 cœurs d’UC

1 Gbit/s

Serveur d’applications avec composants d’index et de traitement des requêtes .

Y, Z

500 Go

32 Go

1,8 GHz 8 cœurs d’UC

1 Gbit/s

Serveurs d’applications avec composants de traitement de contenu, d’administration de la recherche ou d’analyse.

AA-AF

100 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveurs d’applications avec composants de traitement de l’analyse.

AG, AH

800 Go

8 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

Serveurs de base de données contenant des bases de données de recherche.

AI-AL

500 Go

16 Go

1,8 GHz 4 cœurs d’UC

1 Gbit/s

1Le nombre de cœurs d’UC est spécifié ici, pas le nombre de threads d’UC.

Planifier les performances de stockage

La vitesse du stockage a une incidence sur les performances de recherche. Veillez à ce que le stockage dont vous disposez soit assez rapide pour gérer le trafic provenant des bases de données et des composants de recherche. La vitesse du disque est mesurée en opérations d’E/S par seconde (IOPS).

La façon dont vous décidez de distribuer les données provenant des composants de recherche et du système d’exploitation dans l’ensemble de votre stockage influe sur les performances de recherche. Il est conseillé de :

  • Fractionner les fichiers du système d’exploitation de Windows Server, les fichiers de programme de SharePoint Server et les journaux de diagnostic en trois volumes ou partitions de stockage distincts avec des performances normales.

  • Stocker les données de composant de recherche sur une partition ou un volume de stockage distinct avec des performances élevées.

    Notes

    Vous pouvez définir un emplacement personnalisé pour les données de composant de recherche lorsque vous installez SharePoint Server sur un hôte. Tous les composants de recherche sur l’hôte qui doivent stocker des données le font à cet emplacement. Pour modifier cet emplacement par la suite, vous devez réinstaller SharePoint Server sur cet hôte.

Choisir le stockage

Pour obtenir une vue d’ensemble des architectures de stockage et des types de disques, consultez la rubrique Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server). Les serveurs qui hébergent les composants de traitement d’analyse ou d’index, ou les bases de données de recherche, requièrent un stockage capable de maintenir une latence faible, tout en permettant de réaliser un nombre suffisant d’opérations d’E/S par seconde (IOPS). Les tableaux suivants indiquent le nombre d’IOPS que chacun de ces composants et bases de données de recherche requièrent.

Si vous déployez un stockage partagé de type SAN/NAS, la charge disque maximale d’un composant de recherche coïncide généralement avec la charge disque maximale d’un autre composant de recherche. Pour obtenir le nombre d’IOPS requises par la recherche dans le cas d’un stockage partagé, vous devez ajouter les besoins en IOPS de chacun de ces composants.

Besoins en IOPS des composants de recherche

Nom du composant Détails du composant Besoins en IOPS Utilisation de volume/partition de stockage distinct

Composant d’index

Utilise le stockage lors de la fusion de l’index et lors de la gestion et de la réponse aux requêtes.

  • 300 IOPS pour 64 Ko de lectures aléatoires

  • 100 IOPS pour 256 Ko d’écritures aléatoires

  • 200 Mo/s pour les lectures séquentielles

  • 200 Mo/s pour les écritures séquentielles

Oui

Composant analytique

Analyse les données localement, en traitement en bloc.

Non

Oui

Composant d’analyse

Stocke le contenu téléchargé localement, avant de l’envoyer à un composant de traitement de contenu. Le stockage est limité par la bande passante réseau.

Non

Oui

Besoins en IOPS des bases de données de recherche

Nom de la base de données Besoins en IOPS Charge classique sur le sous-système d’E/S

Base de données d’analyse

IOPS moyennes à élevées

10 IOPS pour un taux d’analyse d’1 document par seconde (DPS)

Base de données de liens

IOPS moyennes

10 IOPS pour 1 million d’éléments dans l’index de recherche

Base de données d’administration de la recherche

IOPS faibles

Non applicable

Base de données de création de rapports d’analyse

IOPS moyennes

Non applicable

Choisir le mode de prise en charge de la haute disponibilité dans votre architecture de recherche

Si vous ne connaissez pas les stratégies de haute disponibilité, lisez cet article pour commencer : Créer une architecture et une stratégie haute disponibilité pour SharePoint Server. Votre architecture de recherche prend en charge la haute disponibilité quand vous hébergez des bases de données et des composants de recherche redondants sur des domaines d’erreur distincts. Tous les exemples d’architectures de recherche hébergent des composants de recherche redondants sur des serveurs indépendants.

Pour chaque serveur hôte redondant dans votre architecture de recherche, vous devez prévoir l’installation des éléments suivants :

  1. Réseau redondant

  2. Sources d’alimentation redondantes avec un câblage indépendant ou un onduleur (UPS)

Étape 4 : Comment vérifier que mon architecture de recherche fonctionne correctement ?

Avant de déployer votre architecture de recherche vers un environnement de production, vous devez vérifier qu’elle fonctionne correctement. Voici la liste des opérations à effectuer :

  1. Vérifiez que les composants d’index utilisent un sous-système d’E/S de stockage avec un nombre suffisant d’IOPS. Consultez la section Tester le sous-système d'E/S de stockage.

  2. Déployez l’architecture de recherche vers un environnement pilote. Veillez à ce que l’environnement pilote soit représentatif de l’environnement de production.

  3. Testez les performances de recherche de l’environnement pilote. Voir Tester les performances de recherche.

Pour une vue d’ensemble des tests en général dans SharePoint, consultez la rubrique Test des performances de SharePoint Server 2013.

Tester le sous-système d’E/S de stockage

Pour tester le sous-système d’E/S de stockage, exécutez les opérations sur disque les plus importantes et mesurez les E/S par seconde. Vous pouvez utiliser l’outil SQLIO pour exécuter ces tests. Voir Outil d’évaluation de sous-système de disque SQLIO.

Configurer l’environnement de test

Vous n’êtes pas obligé de configurer l’architecture de recherche entière, ni d’installer SharePoint Server. Il suffit de configurer un environnement de test qui produit une charge de travail réaliste pour le sous-système d’E/S de stockage.

Prenons le cas d’un stockage local. Par exemple, si l’hôte A dans la batterie de recherche de taille moyenne utilise un disque local, vous devez installer les deux machines virtuelles et exécuter les tests d’opérations sur disque sur les deux machines virtuelles en même temps.

Vous devez utiliser une configuration différente pour le stockage partagé. Si, par exemple, la charge de travail de tous les composants d’index dans la batterie de recherche de taille moyenne et d’autres charges de travail non liées partagent le même stockage, vous devez effectuer les opérations suivantes :

  1. Installez les huit machines virtuelles sur les hôtes A, B, C et D, et configurez les sources des charges de travail non liées.

  2. Veillez à ce que la charge de travail non liée soit appliquée au stockage partagé en même temps que vous exécutez simultanément les tests d’opérations sur disque sur toutes les machines virtuelles sur les hôtes A, B, C et D.

Créer un fichier de test

  1. Créez un fichier de test de 1 Go à l’aide de la commande sqlio.exe -t32 -s1 -b256 1g. Cette commande crée un fichier nommé « 1g ».

  2. Enregistrez le fichier de test sur le dispositif de stockage que vous souhaitez tester. Par exemple, sur le disque dur de l’hôte A de la batterie de taille moyenne.

  3. Concaténez le fichier de test dans un fichier de test suffisamment grand. Par exemple, 256 Go, avec la commande copy 1g+1g+1g+...+1g testfile.

  4. Redémarrez le serveur. Cela permettra de garantir que la mise en cache ne fausse pas les résultats du test.

Exécuter les tests

Il est conseillé de mesurer les éléments suivants :

  • Les performances des accès aléatoires de taille moyenne (voir test numéro 1 et 2 ci-dessous).

  • Le débit de lecture et d’écriture pour les transferts conséquents (voir test numéro 3 et 4 ci-dessous).

Le tableau ci-dessous répertorie les commandes SQLIO à utiliser pour exécuter chaque test. Toutes les commandes supposent que le fichier de test « testfile » existe dans le répertoire actif. Chaque test est exécuté pendant 300 secondes.

Numéro de test Domaine d’application Commande

1

Lecture de 64 Ko [IOPS]

sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile

2

Écriture de 256 Ko [IOPS]

sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile

3

Lecture de 100 Mo [Mo/s]

sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile

4

Écriture de 100 Mo [Mo/s]

sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 testfile

Résultats de l’exemple pour le stockage de disque local

Les exemples de résultats figurant dans le tableau ci-dessous indiquent un déploiement dans lequel au moins 50 % de la capacité du sous-système de disque était utilisée avant l’ajout du fichier de test.

Le contrôleur de disque et les broches du disque influencent fortement ces résultats.

Si vous faites des tests sur des disques vides, vous obtiendrez des résultats élevés car le fichier de test sera dans les pistes les plus optimales dans l’ensemble des broches (trajectoire courte). Cela peut accroître les performances jusqu’à deux ou trois fois. Vous obtiendrez des résultats anormalement élevés si vous testez un disque dur qui optimise les accès sur un espace de stockage non initialisé, ou un stockage contenant tous les zéros, par exemple les fichiers dynamiques VHD/VHDX. Dans ce cas, utilisez un très grand fichier de test qui contient des données réelles, plutôt que de générer un fichier de test synthétique à l’aide des commandes SQLIO.

Disposition du disque

Test 1

Test 2

Test 3

Test 4

IOPS minimales recommandées pendant les opérations ordinaires

300

100

200

200

4 x 1 To 7 200 tr/min NLSAS, RAID5, contrôleur RAID Dell H710 (taille de bande 64 Ko, taille de blocs 64 Ko)

1181

206

284

296

8 x 1 To 7 200 tr/min NLSAS, RAID5, contrôleur RAID Dell H710 (taille de bande 64 Ko, taille de blocs 64 Ko)

2082

337

610

645

16 x 1 To 7 200 tr/min NLSAS, RAID5, contrôleur RAID Dell H710 (taille de bande 64 Ko, taille de blocs 64 Ko)

3763

595

1173

1181

16 x 1 To 7 200 tr/min NLSAS, RAID50 (2 x 8), contrôleur RAID Dell H710 (taille de bande 64 Ko, taille de blocs 64 Ko)

3613

545

1139

1164

16 x 1 To 7 200 tr/min NLSAS, RAID10, contrôleur RAID Dell H710 (taille de bande 256 Ko, taille de blocs 64 Ko)

4030

1146

970

775

4 x SmartStorage Optimus 800 Go SSD, RAID5, contrôleur RAID Dell H710 (taille de bande 64 Ko, taille de blocs 64 Ko)

32385

3781

1714

1319

4 x SmartStorage Optimus 800 Go SSD, RAID0, contrôleur RAID Dell H710 (taille de bande 256 Ko, taille de blocs 64 Ko)

31747

7149

1643

1798

Tester les performances de recherche

Voici la liste des opérations à effectuer pour tester votre architecture de recherche :

  1. Choisir le contenu sur lequel exécuter les tests

  2. Choisir les termes et les expressions pour tester les performances des requêtes

  3. Mesurer les performances de recherche

Choisir le contenu sur lequel exécuter les tests

Choisissez un contenu qui représente bien votre contenu de production. Si vous choisissez un contenu réservé aux tests, veillez à avoir différents types d’éléments, pas uniquement un élément que vous avez dupliqué plusieurs fois. En effet, le processeur de requêtes risque de passer du temps à détecter les éléments dupliqués, ce qui aura une influence sur les performances de recherche, et vos résultats ne seront pas représentatifs d’un environnement de production.

Configurez une ou plusieurs sources de contenu pour analyser le contenu. Vérifiez que vous disposez de l’accès réseau et du compte d’utilisateur requis.

Choisir les termes et les expressions pour tester les performances des requêtes

Le nombre de résultats que vous obtenez pour une requête est appelé le rappel.

Pour tester les performances des requêtes, vous devez d’abord créer un ensemble de termes et d’expressions à utiliser en tant que requêtes. Vous pouvez également collecter des requêtes à partir d’une installation existante. Assurez-vous que l’ensemble contient des termes et des expressions qui possèdent un rappel faible et un rappel élevé, et que les termes et expressions sont appropriés pour votre environnement.

Exemples

  • Si vous recherchez un numéro de produit dans un catalogue de produits, il est très probable qu’un numéro ne correspond qu’à un seul produit. Par conséquent, vous obtiendrez les résultats de la recherche rapidement. Il s’agit du rappel faible.

  • Si vous recherchez un terme courant, tel que « présentation », sur l’intranet d’une entreprise, de nombreux résultats vont très certainement apparaître. Il s’agit du rappel élevé.

  • Si, par exemple, votre contenu est lié aux ressources humaines, utilisez des termes de recherche en rapport avec ce domaine.

Mesurer les performances de recherche

SharePoint Server collecte les mesures de performances de la recherche dans les rapports d’intégrité de l’analyse et les rapports d’intégrité des requêtes. Vous pouvez trouver ces rapports dans l’Administration centrale, sous Administration de la recherche.

Il est conseillé de mesurer les performances de la recherche d’abord avec une charge synthétique, puis avec un petit ensemble d’utilisateurs et du contenu en direct. Lorsque vous utilisez des utilisateurs et du contenu en direct, vous pouvez observer le fonctionnement de l’architecture de recherche. Si votre contenu augmente plus vite que prévu, envisagez peut-être d’utiliser l’architecture de recherche de taille supérieure. Par ailleurs, si vos utilisateurs sont plus actifs que prévu, nous vous recommandons d’augmenter la quantité d’espace de stockage de la base de données analytique.