Évaluer les performances et la capacité requises pour les environnements de recherche
Mise à jour : 2009-05-21
Dans cet article :
Caractéristiques clés
Environnement de test
Recommandations
Ce scénario de planification des performances et de la capacité intègre une batterie de serveurs Microsoft Office SharePoint Server 2007 unique utilisée pour la recherche et l’indexation de contenu Office SharePoint Server dans un environnement d’entreprise.
.gif "Important") Important : |
|---|
Certaines instructions de cet article ont été mises à jour pour Office SharePoint Server 2007 avec SP1. Pour obtenir la liste complète des mises à jour Office SharePoint Server 2007 avec SP1, voir Livre à télécharger : Planification et déploiement du Service Pack 1 pour Office SharePoint Server 2007 dans un environnement multiserveur. |
Caractéristiques clés
Les caractéristiques clés décrivent les facteurs environnementaux, les caractéristiques d’utilisation et d’autres aspects susceptibles de concerner les déploiements basés sur ce scénario.
Les caractéristiques clés de ce scénario sont les suivantes :
**Temps de réponse utilisateur **Les objectifs de temps de réponse utilisateur pour les opérations courantes, non courantes, de longue durée et rares sont répertoriés dans le tableau « Temps de réponse utilisateur » de l’article Planifier les limites des logiciels (Office SharePoint Server). Certaines organisations tolèrent des temps de réponse utilisateur plus lents, d’autres exigent des temps de réponse utilisateur plus rapides. Le temps de réponse utilisateur prévu est un facteur clé qui détermine les objectifs de débit global. Le débit correspond au nombre de demandes que la batterie de serveurs peut traiter par seconde. En présence d’un nombre plus élevé d’utilisateurs, l’obtention du même temps de réponse utilisateur nécessite un objectif de débit plus élevé.
**Utilisateurs simultanés **Un taux de simultanéité de 10 % est supposé, avec 1 % d’utilisateurs simultanés effectuant une demande à un moment donné. Par exemple, pour 10 000 utilisateurs, 1 000 utilisent la solution en même temps de façon active, tandis que 100 effectuent une demande de façon active.
**Tâches asynchrones de longue durée **Les tâches telles que l’analyse de contenu et la sauvegarde de bases de données ajoutent une charge de performances à la batterie de serveurs. Les caractéristiques de performances générales des exemples de topologie supposent que ces tâches s’exécutent pendant les heures creuses, par exemple la nuit. Ainsi, les taux de réponse utilisateur pendant les heures de travail ne sont pas affectés.
Environnement de test
Le test pour ce scénario a été conçu de manière à évaluer la réaction de différentes configurations de batterie de serveurs aux modifications apportées à de nombreux facteurs, dont les suivants :
nombre d’utilisateurs simultanés utilisant le système ;
types d’opérations utilisateur en cours d’exécution ;
nombre de documents dans l’index en cours d’interrogation.
Il est important que noter que même s’il est possible de tirer certaines conclusions des résultats des tests, les chiffres spécifiques de la capacité et des performances indiqués dans cette section seront différents de ceux obtenus dans les environnements réels. Les chiffres indiqués dans cet article sont destinés à fournir un point de départ pour concevoir un environnement correctement adapté. Après avoir terminé la conception initiale de votre système, testez la configuration pour déterminer si votre système prendra en charge les facteurs inhérents à votre environnement.
.gif "Note") Remarque : |
|---|
Ces tests ont été effectués pour simuler un environnement d’entreprise comportant des millions de documents et une base d’utilisateurs volumineuse. Le matériel utilisé pour l’environnement de test a été configuré avec des processeurs robustes et une grande capacité de mémoire et de disque. Pour connaître les recommandations sur la configuration matérielle de départ, voir Recommandations matérielles dans la section Recommandations de cet article. |
Pour plus d’informations sur le test de votre déploiement, voir Outils pour la planification des performances et de la capacité (Office SharePoint Server).
Hypothèses
**Architecture 64 bits **Seuls des serveurs 64 bits ont été utilisés dans l’environnement de test. Bien qu’Office SharePoint Server 2007 puisse être déployé sur des serveurs 32 bits, il est recommandé d’employer des serveurs 64 bits dans les déploiements de batteries de serveurs Office SharePoint Server 2007. Pour plus d’informations, voir la section 64 bits et 32 bits dans l’article À propos de la planification des performances et de la capacité (Office SharePoint Server).
La mise en cache sur disque est activée La mise en cache sur disque élimine la nécessité d’accéder à la base de données plusieurs fois pour obtenir des fragments de code ou des fichiers binaires volumineux, tels que des fichiers d’images, de sons et de vidéos. L’activation de la mise en cache sur disque améliore les performances dans la totalité de votre déploiement. Notez que, par défaut, la mise en cache sur disque n’est pas activée. Pour plus d’informations sur l’activation de la mise en cache sur disque, voir Mise en cache sur disque pour les objets BLOB (https://msdn2.microsoft.com/fr-fr/library/aa604896.aspx?amp;clcid=0x40c° .
Topologie du test
Diverses configurations de batterie de serveurs ont été utilisées pour les tests, allant d’un à huit serveurs de requête, et comprenant un serveur d’index, un fournisseur de services partagés (SSP, Shared Services Provider) et un ordinateur serveur de bases de données exécutant le logiciel de gestion de base de données Microsoft SQL Server 2005. Tous les ordinateurs serveurs exécutaient la configuration par défaut d’Office SharePoint Server 2007 édition Entreprise sur le système d’exploitation Microsoft Windows Server 2003 Service Pack 1 (SP1), Enterprise x64 Edition.
Le tableau suivant répertorie le matériel spécifique utilisé pour les tests.
| Rôle de l’ordinateur | Matériel | Capacité du disque dur |
|---|---|---|
Serveurs de requête |
4 processeurs double cœur Intel Xeon 2,66 Gigahertz (GHz) 32 gigaoctets (Go) de mémoire vive (RAM) |
40 Go pour le système d’exploitation (RAID (Redundant Array of Independent Disks) 5) 956 Go pour l’index de contenu et le fichier d’échange du système d’exploitation (RAID 10) |
Serveur d’index |
4 processeurs double cœur Intel Xeon 2,66 GHz 32 Go de RAM |
40 Go pour le système d’exploitation (RAID 5) 956 Go pour l’index de contenu et le fichier d’échange du système d’exploitation (RAID 10) |
Serveur de base de données |
4 processeurs double cœur Intel Xeon 2,66 GHz 32 Go de RAM |
40 Go pour le système d’exploitation (RAID 5) 956 Go pour la base de données SharedServices_Search_DB avec contrôleur SCSI (Small Computer System Interface) dédié (RAID 10) Les disques suivants partageaient un contrôleur SCSI : 273 Go pour la base de données SharedServices_DB (RAID 10) 273 Go pour la base de données TempDb (RAID 10) 273 Go pour les fichiers journaux (RAID 10) 136 Go pour la base de données SharePoint_Config (RAID 10) |
Un réseau Gigabit (1 milliard de bits/s) a été utilisé dans l’environnement de test. Il est recommandé d’utiliser un réseau gigabit entre les serveurs d’une batterie de serveurs Office SharePoint Server pour garantir une bande passante réseau adéquate.
Profil d’utilisation
Les tableaux suivants montrent le profil d’utilisation de l’environnement de test de la recherche Office SharePoint Server 2007.
| Remarque : |
|---|
Pour les tests de ce scénario, seules des opérations utilisateur de requête ont été utilisées pour l’évaluation des performances du système. |
Environ 50 millions d’éléments ont été analysés pour les tests. Le tableau suivant indique les types et les nombres d’éléments analysés. Les éléments présentaient une taille comprise entre 10 kilo-octets (Ko) et 100 Ko et incluaient des éléments de liste, des pages Web et différents types de documents.
| Type d’élément | Nombre d’éléments |
|---|---|
Contenu sur des sites SharePoint |
10 millions d’éléments, dont les suivants :
|
Contenu sur des partages de fichiers |
15 millions d’éléments |
Contenu HTTP |
15 millions d’éléments |
Profils de personnes |
2,5 millions |
Outil Stitch (outil de test en mémoire qui génère des documents dans la mémoire) |
7,5 millions |
Propriétés (métadonnées) |
1 million |
Le tableau suivant indique l’utilisation de l’espace disque.
| Type d’utilisation | Volume |
|---|---|
Taille de l’index sur le serveur de requête |
100 Go* |
Taille de l’index sur le serveur d’index |
100 Go* |
Taille de la base de données de recherche |
600 Go |
| Remarque : |
|---|
Les tailles d’index testées sont plus petites que ce qui pourrait être observé dans un environnement de production. Dans le corpus généré par les tests, le nombre de mots uniques est limité et ceux-ci sont souvent répétés. |
35 jours furent nécessaires pour réaliser une analyse complète pendant les tests (environ 15 documents par seconde). Notez que les résultats de ces tests ont été observés dans un environnement de production dans lequel le temps de réponse du réseau et la réactivité des référentiels analysés ont influencé la vitesse d’analyse. La vitesse d’analyse mesurée en documents par seconde peut être sensiblement plus rapide dans un environnement de test pur ou dans les environnements où la bande passante et la réactivité des référentiels analysés sont supérieures.
En cas de modification à hauteur de 2 pour cent d’un corpus de la taille utilisée dans l’environnement de test, une analyse incrémentielle visant à traiter les modifications prend environ 8 à 12 heures, en fonction du temps de réponse et de la réactivité des sites en cours d’analyse. Notez que le traitement des modifications apportées aux métadonnées et aux liens sortants dure plus longtemps que celui des modifications apportées au contenu des documents.
Recommandations
Cette section fournit des recommandations d’ordre général sur les performances et la capacité. Utilisez-les pour déterminer les caractéristiques de performances et de capacité de la topologie de départ que vous avez créée dans Planifier la redondance (Office SharePoint Server) et pour déterminer si vous avez besoin de soumettre la topologie de départ à une montée en puissance parallèle ou par unité.
| Remarque : |
|---|
Le terme *montée en puissance parallèle* désigne l’ajout de plusieurs serveurs dans un rôle particulier, tandis que le terme *montée en puissance par unité* désigne l’augmentation des performances ou de la capacité d’un serveur donné en ajoutant de la mémoire, de la capacité de disque dur ou de la vitesse processeur. |
Recommandations matérielles
Le tableau suivant répertorie le matériel recommandé pour les serveurs Web, les serveurs d’index et les serveurs de base de données.
| Remarque : |
|---|
Les besoins en mémoire pour les serveurs Web, les serveurs d’index et les serveurs de base de données dépendent de la taille de la batterie de serveurs, du nombre d’utilisateurs simultanés et de la complexité des fonctionnalités et des pages de la batterie de serveurs. Les recommandations de mémoire figurant dans le tableau suivant peuvent être adaptées à une batterie de serveurs peu ou faiblement sollicitée, à condition de surveiller attentivement l’utilisation de la mémoire pour déterminer s’il est nécessaire d’en ajouter. |
| Rôle de serveur | Matériel recommandé |
|---|---|
Serveur Web (requête) |
Biprocesseurs 2,5 GHz ou plus rapides (3 GHz ou plus rapide recommandé) 2 Go de mémoire RAM minimum recommandé 3 Go d’espace disque disponible Lecteur DVD, local ou réseau accessible |
Serveur d’index |
Biprocesseurs 2,5 GHz ou plus rapides (3 GHz ou plus rapide recommandé) 4 Go de mémoire RAM minimum recommandé 3 Go d’espace disque disponible Lecteur DVD, local ou réseau accessible |
Serveur de base de données |
Biprocesseurs 2,5 GHz ou plus rapides (3 GHz ou plus rapide recommandé) 4 Go de mémoire RAM minimum recommandé L’espace disque nécessaire à la base de données de contenu est basé sur un rapport de 1:1,2 entre taille du contenu et capacité de la base de données. Par exemple, si vous prévoyez 100 Go de contenu, vous avez besoin d’au moins 120 Go d’espace disque disponible pour la base de données de contenu, ainsi que de l’espace supplémentaire pour les journaux des transactions. L’espace disque dur nécessaire à la base de données de recherche est basé sur un rapport de 1:4 entre taille de l’index et capacité de la base de données. Par exemple, si vous prévoyez une taille de 100 Go pour l’index, vous avez besoin d’au moins 400 Go d’espace disque disponible pour la base de données de recherche, ainsi que de l’espace supplémentaire pour les journaux des transactions. Lecteur DVD, local ou réseau accessible |
| Remarque : |
|---|
La quantité d’espace disque dur requise sur le serveur de bases de données pour les journaux des transactions dépend des paramètres de journal. Pour plus d’informations, voir Présentation et gestion des journaux de transactions (https://msdn2.microsoft.com/fr-fr/library/ms345583.aspx?amp;clcid=0x40c). |
Pour plus d’informations sur les configurations minimale et recommandée requises, voir Determine hardware and software requirements (Search Server 2008).
Topologies de point de départ
Vous pouvez estimer les performances de votre topologie de point de départ en comparant celle-ci aux topologies de point de départ fournies dans Planifier la redondance (Office SharePoint Server). Vous pouvez ainsi déterminer rapidement si vous devez ajuster votre topologie de point de départ en fonction de vos objectifs de performances et de capacité.
Capacité et performances des topologies avec montée en puissance par unité ou parallèle
Pour augmenter la capacité et les performances d’une des topologies de point de départ, appliquez une montée en puissance par unité en implémentant des ordinateurs serveurs dotés d’une capacité supérieure ou appliquez une montée en puissance parallèle en ajoutant des serveurs à la topologie. Cette section décrit les caractéristiques de performances générales de plusieurs topologies avec montée en puissance par unité ou parallèle. Les exemples de topologies représentent les méthodes courantes suivantes pour soumettre une topologie à une montée en puissance par unité ou parallèle dans le cadre d’un environnement de recherche :
Pour traiter une charge utilisateur supérieure, ajoutez des ordinateurs serveurs de requête. Vous pouvez également ajouter des serveurs d’index et des serveurs de requête dédiés pour alléger la charge de traitement qui pèse sur les serveurs Web.
Pour prendre en compte une charge supérieure de données, ajoutez de la capacité au rôle de serveur de bases de données en augmentant la capacité d’un serveur unique (en cluster ou en miroir), en effectuant une mise à niveau vers un serveur 64 bits ou en ajoutant des serveurs en cluster ou en miroir.
Conservez un rapport inférieur ou égal à huit ordinateurs serveurs de requête pour un ordinateur serveur de bases de données (en cluster ou en miroir). Les tests effectués dans notre atelier indiquent un rapport optimal de 7x1x1 (sept serveurs de requête pour un serveur d’index et un serveur de bases de données)
Estimer les objectifs de débit
Cette section fournit des données de test qui montrent le débit de la batterie de serveurs pour un nombre croissant de serveurs de requête et de connexions utilisateur.
Étant donné qu’Office SharePoint Server 2007 peut être déployé et configuré de nombreuses façons, aucune méthode simple ne permet d’estimer le nombre d’utilisateurs pouvant être pris en charge par un nombre donné de serveurs. Par conséquent, il est important que vous meniez le test dans votre propre environnement avant de déployer Office SharePoint Server 2007 dans un environnement de production.
Plusieurs facteurs peuvent influencer le débit, notamment le nombre d’utilisateurs, la complexité et la fréquence des opérations utilisateur, la mise en cache, ainsi que la personnalisation des pages et des composants WebPart. Chacun de ces facteurs peut avoir un impact majeur sur le débit de la batterie de serveurs. Vous devez envisager avec soin chacun de ces facteurs lorsque vous planifiez votre déploiement.
Pour plus d’informations sur la mise en cache dans Office SharePoint Server 2007, voir les ressources suivantes :
Vue d’ensemble de la mise en cache personnalisée (https://go.microsoft.com/fwlink/?linkid=82618&clcid=0x40C)
Section « Mise en cache » de l’article Autres facteurs de planification de la capacité et des performances (Office SharePoint Server)
Si votre organisation dispose d’une solution de recherche, vous pouvez afficher les journaux Internet Information Services (IIS) pour déterminer les modèles d’utilisation et les tendances de votre environnement actuel. Pour plus d’informations sur l’analyse des journaux IIS, voir Analyse des fichiers journaux (IIS 6.0) (en anglais) (https://go.microsoft.com/fwlink/?linkid=78825&clcid=0x40C) (en anglais) .
Si votre organisation prévoit le déploiement d’une nouvelle solution de recherche, utilisez les informations de la section suivante pour estimer vos modèles d’utilisation.
Résultats des tests : débit par configuration de batterie de serveurs
Le tableau de cette section présente les résultats des tests pour une variété de profils d’opérations utilisateur avec le matériel et le profil d’utilisation répertoriés dans le paragraphe Environnement de test plus haut dans cet article. Sachez toutefois que pour chaque configuration de batterie de serveurs, un à huit serveurs de requête ont été testés conjointement avec un serveur d’index et un serveur de bases de données. Par conséquent, une configuration de batterie de serveurs 3x1x1 correspond à trois serveurs de requête pour un serveur d’index et un serveur de bases de données. Aucun test n’a été effectué sur des batteries de serveurs contenant plusieurs serveurs d’index ou de base de données.
Le tableau suivant illustre les résultats de tests pour des opérations utilisateur liées à la recherche.
| Taille de la batterie de serveurs | Demandes/s | Pourcentage d’utilisation processeur sur les serveurs de requête | Pourcentage d’utilisation processeur sur les serveurs d’index | Pourcentage d’utilisation processeur sur les serveurs de base de données | Nombre moyen d’écritures disque/s sur le serveur de bases de données |
|---|---|---|---|---|---|
1x1x1 |
24,01 |
99,49 |
1,98 |
7,23 |
6,11 |
2x1x1 |
48,04 |
96,98 |
3,95 |
13,02 |
2,66 |
3x1x1 |
71,07 |
94,73 |
5,61 |
20,56 |
2,29 |
4x1x1 |
93,11 |
91,77 |
8,81 |
29,21 |
2,41 |
5x1x1 |
114,95 |
90,50 |
10,27 |
39,38 |
2,45 |
6x1x1 |
133,34 |
87,29 |
11,91 |
52,94 |
2,83 |
7x1x1 |
148,52 |
80,20 |
15,24 |
63,72 |
3,14 |
8x1x1 |
146,94 |
65,65 |
15,15 |
69,15 |
2,87 |
Le graphique suivant montre la relation entre le débit et le nombre de serveurs de requête pour les opérations de recherche.
.gif "Demandes par seconde ou serveurs de requêtes")
Estimer la fenêtre d’analyse
Dans un environnement de recherche Office SharePoint Server 2007, l’analyse du contenu est généralement l’opération la plus longue qui ne soit pas initiée par les utilisateurs. Vous devrez effectuer des tests dans votre propre environnement pour évaluer la durée nécessaire à l’analyse du contenu à partir d’une source de contenu spécifique et déterminer si le débit consommé par l’analyse de ce contenu interfère avec vos objectifs en termes de temps de réponse utilisateur. En règle générale, vous devez vérifier que l’analyse d’une source de contenu spécifique peut être entièrement effectuée pendant une plage nocturne de 12 heures.
Estimer l’espace disque nécessaire
Utilisez les informations suivantes pour planifier l’espace disque nécessaire pour les serveurs d’index, de requête et de base de données de votre environnement.
Espace disque requis pour les serveurs d’index et les serveurs de requête
Utilisez les informations suivantes pour planifier l’espace disque requis pour les serveurs d’index et les serveurs de requête de votre batterie de serveurs.
| Remarque : |
|---|
La taille de l’index de contenu est généralement plus petite que le corpus parce que tous les mots parasites sont supprimés avant que le contenu ne soit indexé. |
| Remarque : |
|---|
Si le rôle de serveur de requête est activé sur un serveur autre que le serveur d’index, l’index est automatiquement propagé vers ces serveurs de requête. Pour qu’une copie de l’index de contenu puisse être stockée dans le système de fichiers sur un serveur de requête, chaque serveur de requête nécessite la même quantité d’espace disque que celle utilisée par le serveur d’index pour l’index de contenu. Pour plus d’informations, voir Planifier la redondance (Office SharePoint Server). |
Pour estimer l’espace disque requis pour le disque dur qui contient l’index de contenu :
Estimez la quantité de contenu que vous souhaitez analyser et la taille moyenne de chaque fichier. Si vous ne connaissez pas la taille moyenne des fichiers du corpus, utilisez 10 Ko par document comme point de départ.
Utilisez la formule suivante pour calculer la quantité d’espace disque requise pour stocker l’index de contenu :
Espace disque requis (en Go) = taille_totale_corpus (en Go) x modificateur_taille_fichier x 2,85
où modificateur_taille_fichier est un nombre appartenant à la plage suivante, basée sur la taille moyenne des fichiers de votre corpus :
1,0 si votre corpus contient de très petits fichiers (taille moyenne des fichiers = 1 Ko) ;
0,12 si votre corpus contient des fichiers de taille modeste (taille moyenne des fichiers = 10 Ko) ;
0,05 si votre corpus contient des fichiers volumineux (taille moyenne des fichiers = 100 Ko ou plus).
| Remarque : |
|---|
Cette équation est uniquement destinée à établir une estimation de départ. Dans la pratique, les résultats peuvent varier considérablement en fonction de la taille et du type des documents en cours d’indexation et de la quantité de métadonnées en cours d’indexation pendant une opération d’analyse. |
Dans cette équation, vous effectuez la multiplication taille_totale_corpus (en Go) x modificateur_taille_fichier pour obtenir la taille estimée du fichier d’index. Ensuite, vous multipliez le résultat par 2,85 pour prendre en charge le traitement des fusions principales réalisées lors de la fusion des données analysées avec l’index. Le résultat final exprime l’espace disque requis estimé.
Par exemple, pour un corpus de 1 Go contenant principalement des fichiers dont la taille moyenne est 10 Ko, utilisez les valeurs suivantes pour calculer la taille estimée du fichier d’index :
1 Go x 0,12 = 0,12 Go
D’après ce calcul, la taille estimée du fichier d’index est 120 Mo.
Ensuite, multipliez la taille estimée du fichier d’index par 2,85 :
120 Mo x 2,85 = 342 Mo
Par conséquent, l’espace disque requis pour le fichier d’index et pour la prise en charge des opérations d’indexation est 342 Mo ou 0,342 Go.
| Remarque : |
|---|
Le volume de données analysées est tributaire du contenu en cours d’analyse. Une source de contenu est un ensemble d’options qui vous permettent de spécifier le protocole à utiliser lors de l’analyse, les URL à partir desquelles commencer l’analyse, le nombre de niveaux sur lesquels celle-ci doit être réalisée et le moment auquel elle doit être effectuée. |
Si votre estimation indique que l’index de contenu contient dans l’espace disque disponible sur les serveurs d’index et de requête, passez à l’étape 3. Sinon, ajoutez de l’espace disque ou réévaluez l’étape 1 avant de passer à l’étape 3.
Analysez une partie du contenu.
Évaluez la taille de l’index de contenu et le nombre de fichiers qui ont été analysés. Utilisez ces informations pour augmenter la précision du calcul que vous avez effectué à l’étape 1.
Si l’espace disque dur restant est approprié, analysez un peu plus de contenu. Sinon, ajoutez le cas échéant de l’espace disque dur ou réévaluez la quantité de contenu que vous souhaitez analyser.
Répétez les étapes 3 à 5 jusqu’à ce que tout le contenu soit analysé.
Une fois que vous avez analysé la totalité du corpus, nous vous conseillons de conserver un enregistrement de la taille de l’index de contenu et de la base de données de recherche pour chaque analyse afin que vous puissiez déterminer un taux de croissance moyen. Étant donné qu’un corpus a tendance à augmenter au fur et à mesure des ajouts de contenu à la batterie de serveurs, vous devez surveiller l’espace disque disponible afin de disposer systématiquement d’une capacité adéquate pour les opérations d’indexation.
Espace disque requis pour la base de données de recherche
La base de données de recherche, qui stocke les métadonnées et les informations de l’historique d’analyse du système de recherche, nécessite généralement plus d’espace disque que l’index. Cela est particulièrement le cas si vous analysez essentiellement des sites SharePoint, qui sont très riches en métadonnées.
| Remarque : |
|---|
Les métadonnées de tout le contenu indexé et l’historique d’analyse sont stockés dans la base de données de la recherche. Pour cette raison, la base de données de recherche requiert davantage d’espace de stockage que l’index de contenu. |
Utilisez la formule suivante pour calculer la quantité d’espace disque requise pour stocker la base de données de recherche :
Espace disque requis (en Go) = taille_totale_corpus (en Go) x modificateur_taille_fichier x 4
où modificateur_taille_fichier est un nombre appartenant à la plage suivante, basée sur la taille moyenne des fichiers de votre corpus :
1,0 si votre corpus contient de très petits fichiers (taille moyenne des fichiers = 1 Ko) ;
0,12 si votre corpus contient des fichiers de taille modeste (taille moyenne des fichiers = 10 Ko) ;
0,05 si votre corpus contient des fichiers volumineux (taille moyenne des fichiers = 100 Ko ou plus).
Par exemple, pour un corpus de 1 Go contenant principalement des fichiers dont la taille moyenne est 10 Ko, substituez les valeurs suivantes dans l’équation pour calculer la taille estimée du fichier d’index :
1 Go x 0,12 = 0,12 Go ou 120 Mo
Ensuite, multipliez la taille estimée du fichier d’index par 4 :
120 Mo x 4 = 480 Mo
Par conséquent, l’espace disque requis pour la base de données de recherche est 480 Mo ou 0,48 Go.
Déterminer les spécifications des serveurs d’index, de requête et de base de données
Dans Office SharePoint Server 2007, la recherche est un service partagé disponible au niveau du fournisseur SSP. Le système de recherche Office SharePoint Server 2007 se compose de deux rôles de serveur principaux : le serveur d’index et le serveur de requête.
L’analyse et l’indexation sont des opérations consommatrices de ressources. L’analyse du contenu est le processus par lequel le système accède au contenu et analyse ce contenu, ainsi que ses propriétés, pour créer un index de contenu qui permettra de traiter les requêtes de recherche. L’analyse consomme des ressources de traitement et de mémoire sur le serveur d’index, sur le ou les serveurs de requête qui traitent les opérations d’analyse, sur le ou les serveurs qui hébergent le référentiel de contenu en cours d’analyse et sur le serveur de bases de données qui sert la batterie de serveurs Office SharePoint Server 2007.
Les analyses ont une incidence sur les performances globales du système et, directement, sur le temps de réponse utilisateur et les performances des autres services partagés de la batterie de serveurs et du service Web sur le serveur de requête qui traite les opérations d’analyse. Vous pouvez dédier un serveur de requête aux opérations d’analyse pour réduire la charge qui pèse sur les autres serveurs de la batterie.
L’indexation du contenu analysé peut également toucher les performances globales du système si les opérations d’analyse ne sont pas affectées à un serveur de requête dédié. Si les opérations liées à la recherche constituent une partie importante des opérations de la batterie de serveurs, envisagez le déploiement d’un serveur de requête dédié. Pour plus d’informations, voir la section Serveur de requête dédié pour l’analyse dans cet article.
Déterminer les spécifications des serveurs d’index
Utilisez les informations de cette section pour définir la configuration requise des serveurs d’index de votre batterie de serveurs Office SharePoint Server 2007.
Processeur du serveur d’index
La vitesse du processeur du serveur d’index influe sur la vitesse d’analyse et sur le nombre de threads d’analyse qui peuvent être instanciées. Bien qu’aucun nombre ou type spécifique de processeurs ne soit recommandé, vous devez évaluer la quantité de contenu à analyser lorsque vous déterminez la configuration requise du serveur d’index. Dans un environnement d’entreprise, il est nécessaire que le serveur d’index possède plusieurs processeurs afin de pouvoir gérer une charge d’indexation importante.
Le tableau suivant montre la hausse de la vitesse d’analyse en fonction du nombre de processeurs disponibles sur le serveur d’index.
| Nombre de processeurs | Pourcentage d’amélioration de la vitesse d’analyse |
|---|---|
1 |
0,00 |
2 |
10,89 |
4 |
19,77 |
8 |
30,77 |
Mémoire du serveur d’index
Sur le serveur d’index, les documents sont chargés dans des mémoires tampons en vue d’être traités par le moteur du robot. Dans une batterie de serveurs comportant un corpus d’environ 1 million de documents, le serveur d’index requiert environ 1,5 Go de mémoire. Une fois qu’un document est traité dans la mémoire, il est écrit sur le disque. Plus la capacité de la mémoire est grande, plus le robot peut traiter de documents en parallèle, améliorant ainsi la vitesse d’analyse.
Nous recommandons un minimum de 4 Go de RAM sur le serveur d’index pour l’analyse d’un corpus comportant plus d’un million de documents.
Vitesse de disque des serveurs d’index
Il est recommandé de spécifier une configuration RAID 10 offrant des temps d’accès de 2 millisecondes (ms) et des taux d’écriture supérieurs à 150 Mo/s afin que les écritures disque soient effectuées rapidement.
Index unique et pertinence
Dans SharePoint Portal Server 2003, il était possible de fractionner l’index de contenu sur plusieurs serveurs pour créer des sous-ensembles du contenu indexé et mieux prendre en charge la croissance. Bien qu’Office SharePoint Server 2007 prenne en charge l’utilisation de plusieurs serveurs d’index pour la montée en puissance parallèle, chaque serveur d’index requiert un fournisseur SSP distinct et il est impossible de combiner les différents index.
Nombre de serveurs d’index
Vous pouvez déployer plusieurs serveurs d’index sur une batterie de serveurs lorsqu’il est opportun d’isoler les fournisseurs SSP ou pour soumettre votre système à une montée en puissance parallèle. Bien qu’il n’existe aucune limite physique quant au nombre de serveurs d’index d’une batterie de serveurs, les tests ont été effectués avec un maximum de quatre serveurs d’index dans une même batterie de serveurs.
Le nombre de serveurs d’index à utiliser dans une batterie de serveurs dépend de la méthode voulue pour cibler les fonctions de recherche. Si les fonctions de recherche imposent que le contenu en cours d’analyse se trouve dans un jeu de résultats unique, vous devez déployer un seul fournisseur SSP avec un seul serveur d’index. La plupart des organisations souhaitent que la totalité du contenu analysé puisse être explorée par les utilisateurs et, par conséquent, ne nécessitent pas plusieurs étendues de recherche.
Si vous pouvez répartir les fonctions de recherche sur différentes étendues pour obtenir différents jeux de résultats de recherche pertinents couvrant plusieurs référentiels de contenu, vous pouvez utiliser plusieurs fournisseurs SSP et serveurs d’index. Un exemple de scénario dans lequel différentes étendues de recherche sont souhaitables est le cas d’une entreprise dont une division gère des documents confidentiels ne pouvant être explorés que par un groupe d’utilisateurs spécifique.
Selon vos impératifs d’échelle et de sécurité, vous pouvez associer tous les fournisseurs SSP au même serveur d’index ou chaque fournisseur SSP à un serveur d’index distinct.
| Remarque : |
|---|
L’interrogation sur plusieurs fournisseurs SSP pour obtenir un jeu de résultats pertinent unique n’est pas prise en charge dans Office SharePoint Server 2007. |
Un serveur d’index unique doté d’une configuration matérielle fiable peut prendre en charge jusqu’à 50 millions de documents. Si vous générez un index unique de cette taille, il est recommandé d’utiliser un seul serveur d’index dans une batterie de serveurs, car l’index est propagé à tous les serveurs de requête de celle-ci. Si un deuxième serveur d’index est ajouté, les index issus de celui-ci sont également propagés à tous les serveurs de requête de la batterie de serveurs, ce qui alourdit la charge qui pèse sur les serveurs de requête.
Pour augmenter la capacité de recherche en ajoutant des fournisseurs SSP, vous devez en outre procéder à une montée en puissance parallèle. Au minimum, vous devez ajouter un serveur d’index, un serveur de bases de données et un serveur Web dédié. Si votre configuration matérielle actuelle prend en charge l’indexation de 10 millions de documents dans un seul fournisseur SSP, vous pouvez procéder à une montée en puissance par unité afin d’héberger 20 fournisseurs SSP à l’aide du même matériel.
| Remarque : |
|---|
Dans Microsoft Office SharePoint Server 2007 for Search, vous ne pouvez utiliser qu’un seul fournisseur SSP. |
Cela vous permettra d’indexer environ 2 millions de documents par fournisseur SSP, pour un total d’environ 40 millions de documents.
| Remarque : |
|---|
Un fournisseur SSP est toujours associé à un seul serveur d’index. Toutefois, un serveur d’index peut prendre en charge plusieurs fournisseurs SSP. |
Serveur de requête dédié pour l’analyse
Il est conseillé de dédier un serveur de requête aux opérations d’analyse.
Dans une batterie de serveurs prenant en charge les recherches, par défaut, tous les serveurs de requête traitent les opérations d’analyse. Lorsqu’une opération d’analyse commence, le serveur d’index envoie une demande aux serveurs de requête qui, à leur tour, extraient le contenu à analyser et le remettent au serveur d’index. Lorsque la charge utilisateur est élevée, une opération d’analyse peut réduire la réactivité du système aux demandes des utilisateurs.
Pour atténuer l’impact des opérations d’analyse sur les performances de la batterie de serveurs, vous pouvez configurer un serveur de requête dédié à l’analyse. Ainsi, toutes les opérations d’analyse sont d’office traitées par le biais du serveur dédié, tandis que tous les autres serveurs de requête de la batterie de serveurs continuent de traiter les demandes utilisateur. Cette configuration est particulièrement utile pour les environnements dans lesquels les opérations d’analyse ne peuvent pas être effectuées en l’espace d’une nuit ou pour les environnements disséminés dans lesquels les utilisateurs établissent des demandes à toute heure.
Pour plus d’informations sur la façon de dédier un serveur de requête à l’analyse, voir Configurer un serveur Web frontal dédié pour l’analyse (Office SharePoint Server 2007).
| Remarque : |
|---|
Le fait de dédier un serveur de requête à l’analyse peut avoir une incidence sur les autres services en cours d’exécution sur le serveur. Un serveur de requête utilisé de cette manière ne peut pas faire l’objet d’un équilibrage de charge, ni servir les demandes de l’utilisateur final. |
Optimisation des performances du serveur d’index
Les opérations d’indexation augmentent la charge qui pèse sur le serveur de bases de données et peuvent réduire la réactivité de la batterie de serveurs. Les opérations d’indexation peuvent également avoir une incidence sur les autres services partagés situés sur le serveur d’application qui exécute le service Indexation de la recherche. Vous pouvez définir le niveau de performances de l’indexation pour chaque serveur d’index sur l’une des trois valeurs suivantes :
Réduit
Partiellement réduit
Maximal
La valeur par défaut est Réduit. Vous pouvez uniquement configurer ce paramètre pour un serveur d’index spécifique, pas pour le fournisseur SSP.
Les analyses ont un effet sur les performances du serveur de bases de données, car le service de recherche Office SharePoint Server écrit toutes les métadonnées recueillies à partir des documents analysés dans des tables de base de données. Il est possible que le ou les serveurs d’index génèrent les données à une vitesse susceptible d’entraîner une surcharge pour le serveur de bases de données.
Vous devez effectuer vos propres tests afin de trouver un point d’équilibre entre la vitesse d’analyse, le temps de réponse du réseau, la charge des bases de données et la charge qui pèse sur les référentiels de contenu en cours d’analyse.
Le tableau suivant montre la relation, révélée par les tests, entre le paramètre du niveau de performances et l’utilisation du processeur sur les serveurs d’index et de base de données.
| Paramètre du niveau de performances | Pourcentage d’utilisation processeur du serveur d’index | Pourcentage d’utilisation processeur du serveur de bases de données |
|---|---|---|
Réduit |
20 |
20 |
Partiellement réduit |
24 |
24 |
Maximal |
25 |
26 |
Tenez compte des scénarios et des recommandations pour le paramètre de niveau de performances indiqués ci-dessous :
Si le serveur d’index et les serveurs de base de données sont utilisés uniquement pour le service de recherche Office SharePoint Server, vous pouvez définir le niveau sur Maximal. Toutefois, il est souhaitable que l’augmentation de l’utilisation processeur du serveur de bases de données liée à l’activité du serveur d’index ne soit pas supérieure à 30 pour cent. Si l’augmentation dépasse 30 pour cent lorsque le niveau de performances est défini sur Maximal, il est conseillé de définir le niveau de performances sur la valeur inférieure suivante.
Si le serveur d’application et le serveur de bases de données sont répartis sur plusieurs services partagés tels que le service de recherche Office SharePoint Server et les services de calcul Excel, il est conseillé de sélectionner un paramètre de niveau de performances inférieur. Cependant, la réduction de l’activité d’indexation maximale autorisée réduit la vitesse d’indexation des éléments, ce qui peut mener à des résultats de recherche obsolètes. Surveillez les performances du serveur local afin de déterminer le niveau de performances approprié pour le serveur d’index.
Procédez comme suit pour spécifier le paramètre de niveau de performances sur le serveur d’index.
Ajuster les performances du serveur d’index
Cliquez sur Démarrer, pointez sur Tous les programmes, pointez sur Microsoft Office Server, puis cliquez sur Administration centrale de SharePoint 3.0.
Dans la page d’accueil de l’Administration centrale, cliquez sur Opérations.
Dans la page Opérations, dans la section Topologie et services, cliquez sur Services sur le serveur.
Dans la page Services sur le serveur, dans le menu Serveur, sélectionnez le serveur d’index que vous souhaitez gérer.
Dans la section Démarrer les services dans le tableau ci-dessous, cliquez sur Service de recherche Office SharePoint Server.
Dans la page Configurer les paramètres du service Office SharePoint Server Search, dans la section Performances de l’indexeur, sélectionnez le niveau de performances à appliquer.
Cliquez sur OK pour enregistrer vos modifications.
Règles d’impact du robot
Les règles d’impact du robot sont des paramètres de configuration de recherche au niveau de la batterie de serveurs qui spécifient le nombre de demandes simultanées générées par le service de recherche Office SharePoint Server lorsqu’il effectue une analyse à l’aide d’une source de contenu spécifiée. La vitesse d’analyse est d’autant plus rapide que le nombre de demandes simultanées est élevé. Notez que la fréquence des demandes spécifiée dans une règle d’impact du robot a une incidence directe sur les charges qui pèsent sur le serveur de bases de données et sur le serveur qui héberge le contenu en cours d’analyse. Si vous augmentez la fréquence des demandes pour un site donné, vous devez surveiller avec soin les serveurs en cours d’analyse afin de déterminer si la charge supérieure est acceptable.
La valeur par défaut correspond au nombre de processus sur le serveur d’index. Par conséquent, pour un ordinateur quadruple processeur, la valeur par défaut est huit. Il est recommandé de régler la valeur et de mesurer la charge pesant sur le serveur cible pour déterminer le nombre optimal de demandes simultanées. Vous pouvez sélectionner le nombre de demandes simultanées parmi les valeurs disponibles suivantes : 1, 2, 4, 8, 16, 32, 64.
Vous pouvez également créer une règle permettant de demander un seul document à la fois et instituant entre les demandes un délai spécifique en secondes. Une telle règle peut être utile pour l’analyse d’un site qui présente une charge utilisateur constante.
Le tableau suivant montre la relation entre le nombre de demandes simultanées et l’utilisation processeur sur les serveurs d’index et les serveurs de base de données.
| Nombre de threads d’analyse | Pourcentage d’utilisation processeur sur le serveur d’index | Pourcentage d’utilisation processeur sur les serveurs de base de données |
|---|---|---|
4 |
35 |
12 |
8 |
40 |
15 |
12 |
45 |
15 |
16 |
60 |
20 |
Vous pouvez créer une règle d’impact du robot en procédant comme suit.
Créer une règle d’impact du robot
Cliquez sur Démarrer, pointez sur Tous les programmes, pointez sur Microsoft Office Server, puis cliquez sur Administration centrale de SharePoint 3.0.
Dans la page d’accueil de l’Administration centrale, cliquez sur Gestion des applications.
Sur la page Gestion des applications, dans la section Recherche, cliquez sur Gérer le service de recherche.
Dans la page Gérer le service de recherche, dans la section Paramètres de recherche au niveau de la batterie, cliquez sur Règles d’impact du robot.
Dans la page Règles d’impact du robot, cliquez sur Ajouter une règle.
Dans la page Ajouter une règle d’impact du robot, dans la section Site, tapez le nom du site où créer une règle. N’incluez pas le protocole (par exemple, n’incluez pas http://)
Dans la section Fréquence des demandes, spécifiez la façon dont le robot demandera des documents sur ce site.
Pour demander plusieurs documents simultanément, sélectionnez Demander le nombre spécifié de documents simultanément sans attendre entre les demandes, puis sélectionnez la valeur de votre choix dans la liste Demandes simultanées.
Pour demander un document à la fois, sélectionnez Demander un document à la fois et attendre le temps spécifié entre les demandes, puis tapez le nombre de secondes d’attente entre les demandes dans la zone Délai d’attente (en secondes).
Cliquez sur OK pour créer la règle.
Déterminer les spécifications des serveurs de requête
Utilisez les informations de cette section pour déterminer les spécifications des serveurs de requête de votre batterie de serveurs Office SharePoint Server 2007.
Mémoire des serveurs de requête
Plus la mémoire disponible est importante, moins le service de recherche Office SharePoint Server a besoin d’accéder au disque dur pour exécuter une requête donnée. En outre, une quantité de mémoire adéquate renforce l’efficacité de la mise en cache. Dans l’idéal, il est conseillé d’installer suffisamment de mémoire sur les serveurs de requête pour que la totalité de l’index soit prise en charge.
La figure suivante illustre la relation entre la taille de l’index sur les serveurs de requête et le temps de réponse utilisateur par requête.
.gif "Analyse des performances et de la capacité pour la recherche")
Vitesse de disque des serveurs de requête
Il est recommandé d’utiliser une configuration RAID 10 pour des écritures disque rapides.
Nombre de serveurs de requête
Vous pouvez déployer plusieurs serveurs de requête dans la batterie de serveurs à des fins de redondance et d’équilibrage de charge. Le nombre de serveurs de requête que vous utilisez dépend du nombre d’utilisateurs présents dans la batterie de serveurs et de la charge maximale escomptée. Nous avons testé jusqu’à huit serveurs de requête par batterie de serveurs.
La figure suivante illustre le débit des requêtes, le pourcentage d’utilisation processeur sur le serveur de bases de données pour la base de données de recherche et le pourcentage d’utilisation processeur sur les serveurs de requête en fonction du nombre de serveurs de requête dans la batterie de serveurs. Dans le test dont sont issues ces données, le serveur de bases de données utilisé était partagé entre les bases de données de contenu et les bases de données de service.
.gif "Graphique des performances du serveur de recherche")
Latence du serveur distant
La latence du serveur est un facteur important qui se répercute sur les performances d’analyse. Les performances des différentes batteries de serveurs doivent être équilibrées afin que les performances d’analyse globales soient optimisées. Par exemple, un serveur d’index puissant peut fonctionner à hauteur de 25 % de sa capacité si le serveur de bases de données en cours d’analyse n’est pas capable de répondre suffisamment rapidement. Dans ce cas, vous pouvez soumettre le serveur de bases de données à une montée en puissance par unité, ce qui se traduira par l’augmentation des vitesses d’analyse dans l’ensemble de la batterie de serveurs.
Vous devez effectuer vos propres tests pour évaluer la réactivité des serveurs dans votre environnement. Le serveur de bases de données servant la batterie de serveurs cible est souvent à l’origine des performances d’analyse médiocres. Pour améliorer les performances d’analyse, vous pouvez :
soumettre la configuration matérielle du serveur de bases de données à une montée en puissance par unité en ajoutant des processeurs, en mettant à niveau les processeurs existants, en ajoutant de la mémoire et en effectuant une mise à niveau vers des disques durs dont les temps d’accès et d’écriture sont plus rapides ;
augmenter la mémoire sur les serveurs de requête de la batterie de serveurs ;
effectuer l’analyse en dehors des heures de pointe, afin que le serveur de bases de données en cours d’analyse puisse traiter le trafic utilisateur au cours de la journée et répondre aux analyses pendant les heures creuses.
Déterminer les spécifications des serveurs de base de données
Le système de recherche Office SharePoint Server 2007 analyse à la fois les données de texte et les métadonnées associées au contenu. Dans Office SharePoint Portal Server 2003, toutes les métadonnées recueillies par le système d’indexation étaient stockées dans une banque de propriétés de base de données Jet. Dans Office SharePoint Server 2007, l’index inversé de recherche en texte intégral est stocké sur le serveur d’index, tandis que les métadonnées sont stockées dans la base de données de recherche. Le serveur d’index écrit les métadonnées dans la base de données et les serveurs de requête lisent ces données pour traiter les requêtes basées sur les propriétés émises par les utilisateurs.
Utilisez les informations de cette section pour déterminer les spécifications des serveurs de base de données dans votre batterie de serveurs Office SharePoint Server 2007.
Débit de base de données
Le magasin des métadonnées de la base de données est partagé par le serveur d’index et tous les serveurs de requête de la batterie de serveurs. Le serveur d’index écrit toutes les métadonnées, tandis que les serveurs de requête lisent ces données pour traiter les demandes de recherche. Le débit de requête dépend en grande partie de la réactivité du magasin des métadonnées.
À mesure que le nombre de serveurs de requête augmente dans la batterie de serveurs, la charge sur le serveur de bases de données augmente également et touche le débit de requête global. Vous devez soigneusement surveiller le serveur de bases de données lors de l’ajout de serveurs d’index ou de serveurs de requête à la batterie de serveurs pour vous assurer que les performances de la base de données restent adéquates.
Distribution des données sur les disques durs du serveur de bases de données
Étant donné que le service de recherche Office SharePoint Server écrit une grande quantité de données dans la base de données de recherche pendant les analyses, il est recommandé d’utiliser des piles différentes pour les bases de données SharedServices_Search_Db, SharedServices_Db et TempDb afin d’obtenir de meilleures performances dans les scénarios où l’index contient plus de 5 millions d’éléments.
Vitesse de disque des serveurs de base de données
Il est recommandé d’utiliser une configuration RAID 10 pour des écritures disque rapides.
Télécharger ce livre
Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :
Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.
Voir aussi
Concepts
Configurer un serveur Web frontal dédié pour l’analyse (Office SharePoint Server 2007)