Planifier l’architecture de recherche d’entreprise dans SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Avant de configurer votre architecture de recherche d'entreprise, un certain nombre d'éléments doivent être planifiés. Étape par étape, nous vous aiderons à planifier une architecture de recherche 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 ? 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) avant de continuer pour apprendre à connaître l'architecture de recherche, les composants de recherche, les bases de données de recherche et la topologie de recherche. Quand vous planifiez une architecture de recherche, tenez compte des éléments suivants :
Étape 2 : Quelle architecture de recherche de taille pour la quantité de contenu ?
Étape 3 : De quelle configuration matérielle requise dois-je tenir compte ?
Étape 4 : Comment vérifier que mon architecture de recherche fonctionne correctement ?
É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 commencez avec 12 000 éléments indexés et que vous prévoyez que le volume de ce contenu triple au cours des 12 prochains mois. Vous devez prévoir 36 000 éléments pouvant faire l’objet d’une recherche.
Étape 2 : Quelle architecture de recherche de taille pour la quantité 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 conseillons d’utiliser comme base pour planifier votre propre batterie de serveurs. 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’articles | Batterie de recherche de petite taille | 0 à 10 millions d'éléments |
| 0-80 millions d’articles | Batterie de recherche de taille moyenne | 0-40 millions d’articles |
| 0-200 millions d’articles | Batterie de recherche de grande taille | 0-100 millions d’articles |
| 0-500 millions d’articles | Batterie de serveurs de recherche très volumineuse | Non pris en charge |
Bien que ces exemples d’architectures de recherche utilisent des machines virtuelles, vous pouvez utiliser des serveurs physiques et des machines virtuelles en fonction de la stratégie de la solution SharePoint Server globale de votre architecture de recherche.
Batterie de recherche de petite taille
Nous avons estimé que cette architecture de recherche peut analyser 50 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez jusqu’à 20 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la petite batterie de serveurs de recherche sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 50 documents par seconde, la recherche prend 110 heures pour analyser 20 millions d’éléments dans la première analyse complète.
Batterie de recherche de taille moyenne
Nous avons estimé que cette architecture de recherche peut analyser 100 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez entre 20 et 80 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la batterie de serveurs de recherche moyenne sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 200 documents par seconde, la recherche prend 280 heures pour analyser 80 millions d’éléments dans la première analyse complète.
Batterie de recherche de grande taille
Nous avons estimé que cette architecture de recherche peut analyser 200 documents par seconde et servir de l’ordre de 10 requêtes par seconde. Si vous avez entre 80 et 200 millions d’éléments dans une batterie de serveurs SharePoint Server 2016, la batterie de serveurs de recherche volumineuse sera probablement la batterie de serveurs qui vous convient le mieux. Avec un taux d’analyse de 200 documents par seconde, la recherche prend 280 heures pour analyser 200 millions d’éléments dans la première analyse complète.
Batterie de serveurs de recherche très volumineuse
Microsoft a testé cette architecture de recherche et a mesuré qu’elle peut analyser 300 à 500 documents par seconde et traiter de l’ordre de 10 requêtes par seconde. Seul SharePoint Server 2016 prend en charge cette architecture de recherche de taille. Si vous avez jusqu’à 500 millions d’articles, une batterie similaire à la batterie de recherche très grande est un bon point de départ. Avec un taux d’analyse de 500 documents par seconde, la recherche prend environ 300 heures pour analyser 500 millions d’éléments dans la première analyse complète.
La création d’une batterie de recherche de cette taille vous oblige à planifier et paramétrer soigneusement la batterie pour obtenir les performances souhaitées. Vous trouverez peut-être avantageux de demander l’aide d’un expert. Il est également important de planifier la sauvegarde et la restauration d’une batterie de recherche de cette taille, et comment la récupérer si votre centre de données est en panne majeure. Nous vous recommandons de pratiquer la sauvegarde, la restauration et la récupération.
É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 les ressources matérielles pour les serveurs hôtes
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 serveurs de recherche très volumineuse
Choose how your search architecture supports high availability
Choisir d’exécuter des serveurs physiques ou virtuels
Si vous utilisez l’une des architectures que nous avons estimé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 plus faible que celui d'un environnement physique. Un serveur physique peut héberger plus de composants de recherche sur le même serveur qu'un serveur virtuel. Vous trouverez des conseils utiles ici : Overview of farm virtualization and architectures for SharePoint 2013.
Il est également possible d’exécuter votre architecture de recherche sur des serveurs physiques. Dans les exemples d’architectures de batterie, déplacez simplement les composants de recherche depuis les machines virtuelles vers le serveur hôte et enlevez 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. Si, par exemple, vous modifiez l’architecture de recherche de l’exemple moyen pour utiliser des serveurs physiques, vous constaterez que vous disposez de deux composants de traitement de contenu sur l’hôte E. La solution consiste à enlever l’un des composants de traitement du contenu. Cela fonctionne, car l’analyse, le traitement du contenu et le traitement de l’analytique dépendent de la quantité de ressources disponibles, et non du nombre de composants de traitement du contenu.
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
Assurez-vous que chaque serveur hôte dispose de suffisamment d’espace disque pour l’installation de base du système d’exploitation Windows Server et pour les fichiers 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 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 la planification des bases de données SQL, consultez Planification et configuration de la capacité de stockage et SQL Server (SharePoint Server).
Le stockage minimal requis par la base de données de rapports d’analytique peut varier. En effet, la quantité de stockage dépend de la façon dont les utilisateurs interagissent avec SharePoint Server. Lorsque les utilisateurs interagissent fréquemment, 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 repensée.
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 | Processeur1 | 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 de processeur2,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.
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de stockage, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, 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 batterie de serveurs de recherche SharePoint Server 2013.
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 | Processeur1 | 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 de processeur2,3 | 1 Gbit/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 de processeur2,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.
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de stockage, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, 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 batterie de serveurs de recherche SharePoint Server 2013.
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 | Processeur1 | 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 de processeur2, 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 de processeur2, 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.
deuxAvec SharePoint Server 2013, la quantité minimale de ressources nécessaires est de 500 Go de stockage, 16 Go de RAM et quatre cœurs de processeur.
3Avec SharePoint Server 2016, vous pouvez également utiliser 250 Go de stockage, 16 Go de RAM et quatre cœurs de processeur, 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 batterie de serveurs de recherche SharePoint Server 2013.
Ressources matérielles minimales pour la batterie de serveurs de recherche très volumineuse
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 uniquement générer cet exemple de batterie avec SharePoint Server 2016.
| Serveur | Hôte | Stockage | Mémoire RAM | Processeur1 | Bande passante réseau |
|---|---|---|---|---|---|
| Serveur d’applications qui a des composants d’index. | A-X | 500 Go | 32 Go | 1,8 GHz 8 cœurs de processeur x | 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 de processeur x | 1 Gbit/s |
| Serveurs d’applications qui ont des composants d’analyse, d’administration de recherche ou de traitement du contenu | AA-AF | 100 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs d’applications qui ont des composants de traitement d’analytique | AG, AH | 800 Go | 8 Go | 1,8 GHz 4 cœurs d’UC | 1 Gbit/s |
| Serveurs de base de données qui ont 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 programmes 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 ultérieurement, 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 Planification et configuration de la capacité de stockage et SQL Server (SharePoint Server). Les serveurs qui hébergent les composants de traitement d’index ou d’analytique, ou les bases de données de recherche, ont besoin d’un stockage capable de maintenir une faible latence, tout en fournissant suffisamment 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 connaissez peu les stratégies de haute disponibilité, voici un article qui vous permettra de démarrer : 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 :
Réseau redondant
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 :
Vérifiez que les composants d'index utilisent un sous-système d'E/S de stockage avec un nombre suffisant d'IOPS. Voir Tester le sous-système d'E/S de stockage.
Déployez l'architecture de recherche vers un environnement pilote. Veillez à ce que l'environnement pilote soit représentatif de l'environnement de production.
Testez les performances de recherche de l'environnement pilote. Voir Tester les performances de recherche.
Pour obtenir une vue d’ensemble des tests en général dans SharePoint, voir Tests de performances pour 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 DiskSpd pour exécuter ces tests. Consultez DiskSpd : A Robust Storage Performance Tool.
Configurer l’environnement de test
Vous n’avez pas besoin de configurer l’architecture de recherche entière ou 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 :
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.
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
Créez un fichier de test de 256 GioBytes à l’aide de la commande
diskspd -c256G testfile. Cette commande crée un fichier de taille de 256 Giobytes nommé « testfile ». Vous pouvez également créer un fichier avec une autre taille en suivant la syntaxe :diskspd -c<size>[K|M|G|b] <filename>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.
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 présente les commandes DiskSpd que vous devez 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 | Portée | Command |
|---|---|---|
| 1 | Lecture de 64 Ko [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | Écriture de 256 Ko [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | Lecture de 100 Mo [Mo/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | Écriture de 100 Mo [Mo/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 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 fichier de test très volumineux qui contient des données réelles, au lieu de générer un fichier de test synthétique à l’aide des commandes DiskSpd.
| 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 :
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 recherche dans les rapports d’intégrité d’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. Ou, si vos utilisateurs sont plus actifs que prévu, nous vous suggérons d’augmenter la quantité d’espace de stockage de la base de données analytique.