Planification de la capacité pour Microsoft SharePoint Server 2010 Résumé

Transcription

1 Planification de la capacité pour Microsoft SharePoint Server 2010 Microsoft Corporation Date de publication : janvier 2011 Auteur: équipe Microsoft Office System and Servers (itspdocs@microsoft.com) Résumé Ce document fournit des informations sur la planification de la capacité et des performances pour le déploiement de Microsoft SharePoint Server Il traite de sujets tels que le dimensionnement, les tests de performances et les limites logicielles et présente des études de cas de capacité. Il est destiné aux spécialistes en applications de gestion, aux spécialistes en applications métiers, aux concepteurs de systèmes d information, aux responsables de programmes, aux spécialistes en infrastructures et aux informaticiens en général qui planifient une solution basée sur SharePoint Server Il fait partie d une série de quatre guides de planification qui offrent des informations complètes sur la planification informatique de SharePoint Server. Pour plus d informations sur la planification de l architecture d un déploiement SharePoint Server 2010, voir le Guide de planification des batteries et des environnements de serveurs pour Microsoft SharePoint Server 2010 (éventuellement en anglais) ( Pour plus d informations sur la planification des sites et solutions créés à l'aide de SharePoint Server, voir le Guide de planification des sites et solutions pour Microsoft SharePoint Server 2010, Première partie (éventuellement en anglais) ( et le Guide de planification des sites et solutions pour Microsoft SharePoint Server 2010, Deuxième partie (éventuellement en anglais) ( Le contenu de ce guide est extrait de la bibliothèque technique SharePoint Server 2010 ( arrêté à la date de publication. Pour bénéficier des dernières mises à jour du contenu, utilisez la bibliothèque technique sur le Web.

2 Ce document est fourni en l état. Les informations et les éléments visuels contenus dans ce document, y compris les URL et les autres références à des sites Internet, peuvent faire l objet de modifications sans préavis. Vous assumez tous les risques liés à son utilisation. Certains exemples décrits dans ce document sont fournis à titre d illustration uniquement et sont fictifs. Aucune association ou connexion réelle n est voulue ni ne doit être inférée. Ce document ne vous accorde aucun droit de propriété intellectuelle quant à des produits Microsoft. Vous pouvez copier et utiliser ce document à des fins internes de référence Microsoft Corporation. Tous droits réservés. Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath, Internet Explorer, Outlook, PerformancePoint, PowerPoint, SharePoint, Silverlight, Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server et Windows Vista sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation aux États-Unis d'amérique et/ou dans d'autres pays.

3 Sommaire Planification de la capacité pour Microsoft SharePoint Server Accès à l aide Gestion de la performance et de la capacité (SharePoint Server 2010) Capacity management and sizing for SharePoint Server 2010 (en anglais) Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Glossaire À qui s adressent les articles sur la gestion de la capacité? Les quatre concepts de base des performances Gestion de la capacité et planification de la capacité Surdimensionnement et sous-dimensionnement Limitations et frontières logicielles Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server Différenciateurs clés d un déploiement SharePoint Server Architectures de référence Voir aussi Planification de la capacité pour SharePoint Server

4 Étape 1: modéliser Étape 2: concevoir Étape 3: piloter, tester et optimiser Étape 4: déployer Étape 5: analyser et assurer la maintenance Voir aussi Test de performances pour SharePoint Server Créer un plan de test Créer l environnement de test Créer des tests et des outils Voir aussi Surveillance et gestion de SharePoint Server Configuration de la surveillance Suppression des goulots d étranglement Voir aussi Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Vue d ensemble des frontières et des limites Limites et frontières Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) Environnement de publication intranet d entreprise Microsoft SharePoint Server 2010 : étude de cas technique

5 Informations préalables requises Introduction à cet environnement Spécifications Charge de travail Ensemble de données Données de performances et d intégrité Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais) Prerequisite information Introduction to this environment Specifications Health and Performance Data Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en anglais) Introduction to this environment Glossary Overview Specifications Results and Analysis Departmental collaboration environment technical case study (SharePoint Server 2010) (en anglais) Prerequisite information Introduction to this environment Specifications

6 Workload Dataset Health and Performance Data Divisional portal environment lab study (SharePoint Server 2010) (en anglais) Introduction to this environment Glossary Overview Specifications Results and analysis About the authors Social environment technical case study (SharePoint Server 2010) (en anglais) Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en anglais) Test farm characteristics

7 Test results Recommendations Troubleshooting Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en anglais) Test farm characteristics Test Results Recommendations Évaluer les besoins en performances et en capacité pour PerformancePoint Services Caractéristiques de la batterie de serveurs de test Scénarios et processus de test Configuration matérielle et topologie Résultats des tests Topologies 2M et 3M Résultats 4M+ pour l authentification de Compte de service autonome Résultats 4M+ pour l authentification par utilisateur Recommandations Analysis Services Goulets d étranglement courants et leurs causes Analyse des performances Voir aussi Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en anglais)

8 Introduction Hardware specifications and topology Capacity requirements Voir aussi Estimer les exigences de performances et de capacité pour la gestion de contenu Web dans SharePoint Server informations préalablement requises Détails et approche des tests Déploiements de la gestion de contenu Web Éléments à optimiser Résultats des tests et recommandations À propos des auteurs Estimate performance and capacity planning for workflow in SharePoint Server 2010 (en anglais) Test farm characteristics Test results Recommendations Troubleshooting Voir aussi Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Processus de conception et de configuration du niveau de stockage et de base de données des produits SharePoint Collecter les besoins d E/S, d espace SQL Server et de stockage Choisir la version et l édition de SQL Server

9 Concevoir l architecture de stockage en fonction des besoins de capacité et d E/S Estimation de la mémoire requise Recommandations pour la topologie du réseau Configurer SQL Server Valider et surveiller les performances de stockage et de SQL Server

10 Accès à l aide Les auteurs ont fait tout leur possible pour garantir la précision de ce livre. Ce contenu est également disponible en ligne dans la bibliothèque TechNet Office System. Par conséquent, en cas de problèmes, vous pouvez vérifier si des mises à jour ont été publiées à l adresse suivante : Si vous ne trouvez pas de réponse dans notre contenu en ligne, vous pouvez envoyer un message électronique à l équipe du contenu Microsoft Office System et serveurs à l adresse suivante : itspdocs@microsoft.com Si votre question concerne des produits Microsoft Office et qu elle ne porte pas sur le contenu de ce livre, consultez le centre Microsoft Aide et Support ou la Base de connaissances Microsoft à l adresse suivante : 10

11 Gestion de la performance et de la capacité (SharePoint Server 2010) La planification de la performance et de la capacité est le processus de mappage de la conception de votre solution pour Microsoft SharePoint Server 2010 avec une taille de batterie de serveurs et un ensemble de matériels qui prendra en charge vos objectifs métiers. Des articles pertinents de planification de capacité et de performance pour Project Server 2010 sont disponibles dans la bibliothèque de documents Project Server à l adresse Plan for performance and capacity (Project Server 2010). Les articles de cette section sont les suivants : Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Cet article vous présente les concepts impliqués dans la gestion et le dimensionnement de la capacité des batteries de serveurs SharePoint 2010, et fournit une vue d ensemble du processus de planification. Planification de la capacité pour SharePoint Server 2010 Cet article fournit des étapes et des procédures détaillées pour la planification de la capacité des batteries de serveurs SharePoint Surveillance et gestion de SharePoint Server 2010 Cet article contient des informations sur la façon de gérer et de surveiller la performance des batteries de serveurs SharePoint Test de performances pour SharePoint Server 2010 Cet article contient des directives pour le test de la performance des batteries de serveurs SharePoint Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Cet article fournit un point de départ pour la planification de la performance et de la capacité de votre système. Il comprend des résultats et des directives pour le test de performance et de capacité pour obtenir une performance acceptable. Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) Cet article fournit des liens vers des études de cas techniques clés contenant des détails quant à la performance et à la capacité pour des environnements spécifiques exécutant SharePoint Server

12 Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Cet article fournit des liens vers des articles contenant des résultats et des recommandations de test pour des ensembles de fonctionnalités spécifiques de SharePoint Server Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Cet article décrit un processus pour la planification de la capacité de stockage et de SQL Server pour un déploiement SharePoint Server Les ressources suivantes peuvent également être utiles pour la planification de la capacité : Determine hardware and software requirements (SharePoint Server 2010) Diagrammes techniques : Topologies pour SharePoint Server 2010 Architectures de recherche pour Microsoft SharePoint Server 2010 Concevoir des architectures de recherche pour Microsoft SharePoint Server 2010 Planification de l environnement de recherche pour Microsoft SharePoint Server 2010 Pour télécharger ces modèles, voir Technical diagrams (SharePoint Server 2010). 12

13 Capacity management and sizing for SharePoint Server 2010 (en anglais) The articles in this section help you to make the following decisions regarding the appropriate capacity for your Microsoft SharePoint Server 2010 environment: Understand the concepts behind effective capacity management. Define performance and capacity targets for your environment. Select the appropriate data architecture. Choose hardware to support the number of users and the features you intend to deploy. Test, validate, and adjust your environment to achieve your performance and capacity targets. Monitor and adjust your environment to match demand. In this section: Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Planification de la capacité pour SharePoint Server 2010 Test de performances pour SharePoint Server 2010 Surveillance et gestion de SharePoint Server

14 Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Cet article donne une vue d ensemble sur la façon de gérer et planifier de façon efficace la capacité des environnements Microsoft SharePoint Server Il explique également comment maintenir une bonne compréhension des besoins et des possibilités de capacité de votre déploiement, par l analyse des performances et du volume. Il passe également en revue les impacts des applications majeures sur la capacité, y compris les caractéristiques et l utilisation du contenu. La gestion de la capacité est un processus continu, puisqu aucune implémentation ne demeure statique en ce qui concerne son contenu et son utilisation. Vous devez planifier la croissance et le changement afin que votre environnement SharePoint Server 2010 puisse continuer à offrir une solution métier efficace. La planification de la capacité n est qu une partie du cycle de gestion de la capacité. C est l ensemble d activités initiales que l architecteconcepteur effectue pour bâtir l architecture initiale la plus adaptée d après lui au déploiement de SharePoint Server Le modèle de gestion de la capacité inclut des étapes supplémentaires pour pour valider et mettre au point l architecture initiale, et fournit une boucle de rétroaction pour replanifier et optimiser l environnement de production afin qu il puisse prendre en charge les objectifs de la conception avec les meilleurs choix en matière de matériel, de topologie et de configuration. Dans cet article : Glossaire À qui s adressent les articles sur la gestion de la capacité? Les quatre concepts de base des performances Gestion de la capacité et planification de la capacité Surdimensionnement et sous-dimensionnement Limitations et frontières logicielles Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007 Différenciateurs clés d un déploiement SharePoint Server 2010 Architectures de référence 14

15 Glossaire Les termes spécialisés suivants sont utilisés dans la documentation sur la gestion de la capacité de SharePoint Server RPS (Requests per second) Demandes par seconde. Nombre de requêtes reçues par une batterie de serveurs ou un serveur par seconde. C est une mesure courante de la charge d un serveur ou d une batterie de serveurs. Le nombre de requêtes traitées par une batterie de serveurs est supérieur au nombre de chargements de pages et d interactions des utilisateurs finals. En effet, chaque page contient plusieurs composants, qui créent chacun une ou plusieurs requêtes au chargement de la page. Certaines requêtes sont plus légères que d autres en termes de coût de transaction. Dans nos tests de labo et documents d étude de cas, nous éliminons 401 requêtes et réponses (établissements de liaison d authentification) sur les requêtes utilisées pour calculer RPS car elles ont un impact négligeable sur les ressources de la batterie de serveurs. Heures de pointe Heures de la journée durant lesquelles la charge de la batterie de serveurs est maximale. Charge maximale Charge quotidienne maximale moyenne de la batterie de serveurs, mesurée en RPS. Pic de charge Pics de charge temporaires qui se produisent en dehors des heures de pointe habituelles. Ils peuvent être causés par des accroissements non planifiés du trafic utilisateur, une diminution du débit de la batterie de serveurs à cause d opérations d administration, ou par une combinaison de ces facteurs. Augmenter en puissance Ajouter des ressources comme processeurs ou mémoire à un serveur. Étendre Ajouter des serveurs à une batterie de serveurs. À qui s adressent les articles sur la gestion de la capacité? Considérez les questions suivantes pour savoir si ce contenu vous concerne. Évaluation de SharePoint Server 2010 Je suis informaticien ou décideur d entreprise et je recherche une solution pour des problèmes métiers spécifiques. SharePoint Server 2010 est une option pour mon déploiement. Offre-t-il les fonctionnalités et l évolutivité qui répondent à mes exigences particulières? Pour savoir comment faire évoluer SharePoint Server 2010 pour satisfaire les exigences de solutions spécifiques et comment déterminer le matériel requis pour prendre en charge vos besoins, voir les sections suivantes de cet article : Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007 Limitations et frontières logicielles Pour savoir comment évaluer SharePoint Server 2010 pour vos besoins métiers spécifiques, voir les articles suivants : 15

16 Product evaluation for SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Mise à niveau à partir d Office SharePoint Server 2007 J utilise actuellement Office SharePoint Server Qu est-ce qui a changé dans SharePoint Server 2010 et que faut-il prendre en compte pour la mise à niveau? Quel impact aura la mise à niveau sur les performances et l évolutivité de ma topologie? Pour savoir en quoi les facteurs de performances et de capacité diffèrent pour Office SharePoint Server 2007 et SharePoint Server 2010, voir la section suivante plus loin dans cet article : Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007 Pour des considérations plus générales sur la mise à niveau et pour savoir comment planifier et exécuter une mise à niveau à partir d Office SharePoint Server 2007, voir l article suivant : Upgrading to SharePoint Server 2010 Réglage et optimisation d un environnement SharePoint actif J ai déployé SharePoint Server 2010 et je veux m assurer que j ai le matériel et la topologie appropriés en place. Comment valider mon architecture et la maintenir correctement? Pour des informations sur le suivi et les compteurs de performances sur les batteries de serveurs Microsoft SharePoint Server 2010, voir l article suivant : Surveillance et gestion de SharePoint Server 2010 Pour savoir comment utiliser les outils d analyse d intégrité intégrés à l interface Administration centrale, voir l article suivant : Health Monitoring (SharePoint Server 2010) J ai déployé SharePoint Server 2010 et je rencontre des problèmes de performances. Comment dépanner et optimiser mon environnement? Pour des informations sur le suivi et les compteurs de performances sur les batteries de serveurs Microsoft SharePoint Server 2010, voir l article suivant : Surveillance et gestion de SharePoint Server 2010 Pour des informations sur le dépannage à l aide des outils d analyse d intégrité intégrés à l interface Administration centrale, voir l article suivant : Solving Problems and Troubleshooting (SharePoint Server 2010) 16

17 Pour la liste des articles sur la gestion de la capacité disponibles sur de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d autres articles seront ajoutés au fur et à mesure), voir l article suivant : Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Pour des informations sur le dimensionnement et les performances des bases de données, voir l article suivant : Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Pour des informations sur le stockage BLOB distant (RBS), voir l article suivant : Plan for remote BLOB storage (RBS) (SharePoint Server 2010) De bout en bout Je veux tout savoir sur la gestion de la capacité de SharePoint Server Par où commencer? Pour des informations sur les concepts généraux de gestion de la capacité et des liens vers de la documentation et des ressources supplémentaires, voir l article suivant : Gestion de la performance et de la capacité (SharePoint Server 2010) Pour des informations supplémentaires sur la gestion de la capacité, voir les articles connexes suivants : Planification de la capacité pour SharePoint Server 2010 Test de performances pour SharePoint Server 2010 Surveillance et gestion de SharePoint Server 2010 Vous avez maintenant acquis une bonne compréhension des concepts. Pour des informations sur les limitations et frontières de SharePoint Server 2010, voir l article suivant : Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Lorsque vous êtes prêt à identifier une topologie de départ pour votre environnement SharePoint Server 2010, vous pouvez consulter la bibliothèque des études de cas techniques pour rechercher celui qui correspond le plus à vos besoins. Pour la liste des études de cas (d autres études de cas seront ajoutées au fur et à mesure), voir l article suivant : Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) Pour la liste des articles sur la gestion de la capacité disponibles pour de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d autres articles seront ajoutés au fur et à mesure), voir l article suivant : Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Pour des informations sur le dimensionnement et les performances des bases de données, voir l article suivant : 17

18 Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Pour des informations sur le stockage BLOB distant (RBS), voir l article suivant : Plan for remote BLOB storage (RBS) (SharePoint Server 2010) Pour des informations sur le contrôle et le dépannage d intégrité à l aide des outils d analyse d intégrité intégrés à l interface Administration centrale, voir les articles suivants : Health Monitoring (SharePoint Server 2010) Solving Problems and Troubleshooting (SharePoint Server 2010) Pour des instructions générales sur le réglage des performances et des informations sur divers sujets relatifs à des performances et des capacités spécifiques (d autres articles seront ajoutés au fur et à mesure), voir l article suivant : Use search administration reports (SharePoint Server 2010) Pour savoir comment virtualiser les serveurs SharePoint Server 2010, voir l article suivant : Virtualization planning (SharePoint Server 2010) Les quatre concepts de base des performances La gestion de la capacité est axée sur les quatre aspects majeurs du dimensionnement de votre solution suivants : Latence Pour les besoins de la gestion de la capacité, la latence est la durée entre le moment où un utilisateur lance une action, comme cliquer sur un lien hypertexte, et le moment où le dernier octet est transmis à l application cliente ou au navigateur Web. Débit Le débit est le nombre de requêtes simultanées qu un serveur ou une batterie de serveurs peut traiter. Échelle de données L échelle de données est la taille et le corpus de données du contenu que le système peut héberger. La structure et la répartition des bases de données de contenu ont un impact significatif sur le temps nécessaire pour le traitement des requêtes (latence) par le système et sur le nombre de requêtes simultanées que le système peut traiter (débit). Fiabilité La fiabilité est une mesure de la capacité du système à atteindre les objectifs de latence et de débit définis au fil du temps. Le but principal de la gestion de la capacité de votre environnement est d établir et maintenir un système qui satisfait les objectifs de votre organisation en termes de latence, débit, échelle des données et fiabilité. Latence La latence, également appelée latence perçue par l utilisateur final, est constituée des trois composants majeurs suivants : Le temps nécessaire au serveur pour recevoir et traiter la demande. 18

19 Le temps nécessaire au transfert via le réseau de la demande et de la réponse du serveur. Le temps nécessaire pour restituer la réponse dans l application cliente. Différentes organisations définissent différents objectifs de latence en fonction de leurs exigences et des attentes des utilisateurs. Certaines organisations peuvent se permettre une latence de quelques secondes, tandis que d autres requièrent des transactions très rapides. L optimisation en vue de transactions très rapides est généralement plus coûteuse, et nécessite souvent des clients et des serveurs plus puissants, des versions de navigateur et d application cliente plus récentes, des solutions de réseau à haut débit, et éventuellement des investissements de développement et l adaptation des pages. Certains des facteurs principaux qui contribuent à augmenter la latence perçue par l utilisateur final, et des exemples de problèmes courants, sont décrits dans la liste suivante. Ces facteurs sont surtout pertinents dans les scénarios où les clients sont géographiquement distants de la batterie de serveurs ou accèdent à celle-ci par une connexion réseau à faible bande passante. Les fonctionnalités, les services ou les paramètres de configuration qui ne sont optimisés peuvent retarder le traitement des demandes et avoir un impact sur la latence aussi bien pour les clients distants que locaux. Pour plus d informations, voir Débit et Fiabilité plus loin dans cet article. Les pages Web qui génèrent des requêtes inutiles auprès du serveur pour télécharger les données et ressources requises. L optimisation doit inclure le téléchargement du nombre minimum de ressources pour dessiner la page, en réduisant la taille des images, le stockage des ressources statiques dans des dossiers qui autorisent l accès anonyme, le clustering des requêtes et l activation de l interactivité des pages pendant le téléchargement asynchrone des ressources à partir du serveur. Ces optimisations sont importantes pour obtenir une expérience de navigation acceptable à la première visite. Le volume excessif de données transmises via le réseau contribue à la dégradation de la latence et du débit. Par exemple, les images et autres objets binaires figurant sur une page doivent utiliser un format compressé tel que.png ou.jpg au lieu de bitmap, autant que possible. Les pages Web qui ne sont pas optimisées pour le chargement en second accès. Le temps de chargement de page (PLT, Page Load Time) améliore le chargement en second accès car certaines ressources de la page sont mises en cache sur le client et le navigateur ne doit télécharger que le contenu dynamique non mis en cache. Les latences de chargement de page en second accès inacceptables sont souvent dues à une configuration incorrecte de cache des objets BLOB ou à une mise en cache du navigateur local désactivée sur les ordinateurs clients. Les optimisations doivent inclure la mise en cache correcte des ressources sur le client. Les pages Web qui contiennent du code JavaScript personnalisé non optimisé. Cela peut ralentir l affichage de la page sur le client. L optimisation doit différer le traitement JavaScript sur le client tant que le reste de la page n est pas chargé, et de préférence appeler des scripts au lien d ajouter du JavaScript incorporé. Débit 19

20 Le débit est le nombre de requêtes qu une batterie de serveurs peut traiter dans une unité de temps ; il est souvent utilisé pour mesurer l échelle des opérations que le système doit pouvoir soutenir en fonction de la taille de l organisation et de ses caractéristiques d utilisation. Chaque opération a un coût spécifique en termes de ressources de batterie de serveurs. Pour comprendre la demande et déployer une architecture de batterie de serveurs qui puisse constamment satisfaire la demande, il faut estimer la charge prévue et tester l architecture sous charge afin de vérifier que la latence ne tombe pas en dessous du seuil lorsque la simultanéité est élevée et que le système est chargé. Voici des exemples courants de conditions de faible débit : Ressources matérielles inadéquates Lorsque la batterie de serveurs reçoit plus de requêtes que ce qu elle peut traiter simultanément, des requêtes sont mises en file d attente, ce qui retarde de façon cumulée le traitement des requêtes suivantes tant que la demande est trop forte pour permettre une file d attente vide. Voici quelques exemples d optimisation d une batterie de serveurs pour soutenir un débit plus élevé : Assurez-vous que les processeurs des batteries de serveurs ne sont pas surutilisés. Par exemple, si l utilisation de l UC durant les heures de pointe ou les pics de charge dépasse constamment 80 %, ajoutez d autres serveurs ou redistribuez les services sur d autres serveurs de la batterie de serveurs. Assurez-vous que la mémoire sur les serveurs d applications et les serveurs Web est suffisante pour contenir le cache complet. Cela permet d éviter des appels à la base de données pour traiter les requêtes de contenu non mis en cache. Assurez-vous que les serveurs de bases de données sont exempts de goulots d étranglement. Si le nombre maximum d opérations d entrée/sortie par seconde (IOPS) sur l espace disque total disponible est insuffisant pour supporter la demande de pointe, ajoutez d autres disques ou redistribuez les bases de données sur les disques sous-utilisés. Voir la section Suppression des goulots d étranglement dans l article Suivi et maintenance des produits et technologies SharePoint Server 2010 pour plus d informations. Si l ajout de ressources sur les ordinateurs existants ne suffit pas à résoudre les problèmes de débit, ajoutez des serveurs et redistribuez les fonctionnalités et services affectés sur ces nouveaux serveurs. Pages Web personnalisées non optimisées L ajout de code personnalisé à des pages fréquemment utilisées dans un environnement de production est une cause courante des problèmes de débit. L ajout de code personnalisé peut générer des allerretour supplémentaires vers les serveurs de bases de données ou les services Web pour traiter les requêtes de données. La personnalisation des pages non fréquemment utilisées n a pas forcément un impact significatif sur le débit, mais du code même bien optimisé peut diminuer le débit de la batterie de serveurs s il est appelé des milliers de fois par jour. Les administrateurs de SharePoint Server peuvent activer le tableau de bord du développeur pour identifier le code personnalisé qui requiert une optimisation. Voici quelques exemples d optimisation du code personnalisé : 20

21 Réduisez le nombre de demandes de service Web et de requêtes SQL. Extrayez les données minimum requises à chaque accès au serveur de bases de données tout en réduisant le nombre d allerretour nécessaires. Évitez l ajout de code personnalisé sur les pages fréquemment utilisées. Utilisez les index pour extraire un volume de données filtré. Solutions non approuvées Le déploiement de code personnalisé dans des dossiers binaires peut nuire aux performances du serveur. Chaque fois qu une page contenant du code non approuvé est demandée, SharePoint Server 2010 doit effectuer des contrôles de sécurité avant de charger la page. Sauf s il existe un raison particulière de déployer du code non approuvé, vous devez installer des assemblys personnalisés dans le GAC pour éviter les contrôles de sécurité inutiles. Échelle de données L échelle de données est le volume de données que le serveur ou la batterie de serveurs peut stocker tout en atteignant les objectifs de latence et de débit. En règle générale, plus le volume de données sur la batterie de serveurs est élevé, plus l impact sur le débit global et sur l expérience utilisateur est important. La méthode utilisée pour distribuer les données sur les disques et les serveurs de bases de données peut également affecter la latence et le débit de la batterie de serveurs. Le dimensionnement des bases de données, l architecture des données et un matériel suffisant pour les serveurs de bases de données sont tous très importants dans une solution de bases de données optimale. Dans un déploiement idéal, les bases de données de contenu sont dimensionnées selon les consignes de limites et sont distribuées sur les disques physiques pour éviter la mise en file d attente des requêtes à cause de l utilisation excessive des disques et permettre aux serveurs de bases de données de supporter les charges maximales et les pointes imprévues sans dépasser les seuils d utilisation des ressources. D autre part, certaines opérations peuvent verrouiller des tables pendant leur exécution, par exemple la suppression d un site volumineux, qui peut causer le verrouillage des tables associées de la base de données de contenu où le site réside tant que la suppression n est pas terminée. Voici quelques exemples d optimisation d une batterie de serveurs pour des performances de données et de stockage : Assurez-vous que les bases de données sont correctement réparties sur les serveurs de bases de données et que les ressources de ces serveurs sont suffisantes pour supporter le volume et la distribution des données. Séparez les volumes de base de données en unités logiques (LUN) uniques, constituées de piles de disques physiques uniques. Utilisez plusieurs disques ayant un faible temps d accès et des configurations RAID appropriées pour satisfaire les demandes de stockage des serveurs de bases de données. 21

22 Vous pouvez utiliser le stockage BLOB distant (RBS) si votre corpus contient beaucoup d objets BLOB (Binary Large Object). RBS présente les avantages suivants : Les données BLOB peuvent être stockées sur des dispositifs de stockage moins onéreux configurés pour gérer le stockage simple. L administration du stockage BLOB est contrôlée par un système spécifiquement conçu pour exploiter des données BLOB. Les ressources des serveurs de base de données sont libérées pour les opérations de base de données. Ces avantages ne sont pas gratuits. Avant d implémenter RBS avec SharePoint Server 2010, vous devez déterminer si ces avantages potentiels compensent les coûts et les limitations de l implémentation et de la gestion de RBS. Pour plus d informations, voir Plan for remote BLOB storage (RBS) (SharePoint Server 2010). Pour plus d informations sur la planification de l échelle de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Fiabilité La fiabilité est la mesure consolidée de la capacité de la batterie de serveurs à atteindre les objectifs de latence, de débit et de capacité de données établis, au fil du temps. Une batterie de serveurs fiable est une batterie pour laquelle le temps de fonctionnement, la réactivité, le taux de défaillances, et la fréquence et l amplitude des pointes de latence respectent les objectifs et les exigences opérationnelles établis. Une batterie de serveurs fiable est capable également de constamment soutenir les objectifs de latence et de débit durant les heures de pointe ou de charge maximale, ou lorsque des opérations système telles que l analyse ou les sauvegardes quotidiennes se déroulent. Un facteur majeur de maintien de la fiabilité est l impact des opérations d administration courantes sur les objectifs de performance. Lors de certaines opérations, comme la reconstruction des index de base de données, les travaux de maintenance du minuteur, ou la suppression de plusieurs sites ayant un volume important de contenu, le système risque de ne pas pouvoir traiter les demandes des utilisateurs aussi rapidement. Dans ce cas, la latence et le débit des demandes des utilisateurs finals peuvent être affectés. L impact sur la batterie de serveurs dépend de la fréquence et du coût de transaction de telles opérations moins courantes, ainsi que du moment de leur exécution durant ou non les heures d exploitation normales. Voici quelques exemples de maintien d un système plus fiable : Planifiez les travaux de minuteur et les tâches administratives gourmands en ressources pendant les heures creuses. Augmentez la puissance matérielle des serveurs existants de la batterie, ou étendez la batterie en ajoutant des serveurs Web, des serveurs d applications ou des serveurs de base de données supplémentaires. 22

23 Répartissez les services et les fonctionnalités gourmands en ressources sur des serveurs dédiés. Vous pouvez également utiliser un équilibreur de charge matériel pour diriger le trafic spécifique à des fonctionnalités vers un serveur Web dédié à des fonctionnalités ou des services particuliers. Gestion de la capacité et planification de la capacité La gestion de la capacité étend le concept de planification de la capacité de manière à exprimer une approche cyclique dans laquelle la capacité d un déploiement de SharePoint Server 2010 est en permanence surveillée et optimisée en fonction de l évolution des conditions et des besoins. SharePoint Server 2010 offre une souplesse accrue et peut être configuré pour soutenir des scénarios d utilisation dans un large éventail d échelles différentes. Il n y a pas une architecture de déploiement unique. Par conséquent, les concepteurs et les administrateurs système doivent appréhender les exigences de leur environnement spécifique. Modèle de gestion de la capacité de SharePoint Server

24 24

25 Étape 1 : Modéliser La modélisation est le processus au cours duquel vous déterminez les solutions essentielles que votre environnement doit prendre en charge, et vous établissez tous les paramètres et mesures importants. Le résultat de cette étape est la liste de toutes les données fondamentales nécessaires pour concevoir votre environnement. Appréhendez la charge de travail et l ensemble de données attendus. Définissez les objectifs de performances et de fiabilité de la batterie de serveurs. Analysez les journaux IIS de SharePoint Server Étape 2 : Conception Après avoir rassemblé les données de l étape 1, vous pouvez concevoir la batterie de serveurs. Le résultat de cette étape est l architecture détaillée des données ainsi que les topologies physique et logique. Déterminez votre architecture de départ. Sélectionnez votre matériel. Étape 3 : Pilote, tester et optimiser Si vous avez conçu un nouveau déploiement, vous devez déployer un environnement pilote pour effectuer des tests avec la charge de travail et les caractéristiques d utilisation prévues. Pour une batterie de serveurs existante, les tests sont conseillés si des changements majeurs sont apportés à l infrastructure, mais une optimisation standard basée sur les résultats de l analyse peut s avérer nécessaire pour maintenir les objectifs de performances. Le résultat de cette phase est l analyse des résultat des tests par rapport aux objectifs et une architecture optimisée capable de soutenir les objectifs de performances et de capacité établis. Pilote Déployez un environnement pilote. Tester Testez par rapport aux objectifs de latence et de débit. Optimiser Rassemblez les résultats des tests et apportez les changements nécessaires aux ressources et à la topologie de la batterie de serveurs. Étape 4 : Déployer Cette étape décrit l implémentation de la batterie de serveurs ou le déploiement des modifications sur une batterie de serveurs existante. Le résultat pour une nouvelle conception est le déploiement terminé vers une production en ligne, y compris toutes les migrations de contenu et d utilisateurs. Le résultat pour une batterie de serveurs existante sont des configurations révisées et des mises à jour des plans de maintenance. Étape 5 : Surveiller et maintenir Cette étape décrit comment configurer le suivi, comment prévoir et identifier les goulots d étranglement, effectuer la maintenance régulière et les activités de limitation des goulots d étranglement. 25

26 Surdimensionnement et sous-dimensionnement Le surdimensionnement désigne une approche dans la conception d une batterie de serveurs où les objectifs sont atteints sans une pleine utilisation du matériel, et où les ressources de la batterie de serveurs SharePoint Server sont considérablement et constamment sousutilisées. Dans un déploiement surdimensionné, la mémoire, l UC et d autres indicateurs sur les ressources de la batterie de serveurs montrent que la batterie peut correctement traiter la demande avec moins de ressources. L inconvénient du surdimensionnement : des frais de matériel et de maintenance accrus et des besoins plus importants en énergie et en espace qui peuvent en découler. Le sous-dimensionnement désigne une approche dans la conception d une batterie de serveurs où les objectifs de performances et de capacité sont inatteignables car les ressources matérielles de la batterie de serveurs SharePoint Server sont sur-utilisées. Le sousdimensionnement d une batterie de serveurs est parfois dû à une volonté de réduire les coûts de matériel, mais produit généralement une latence élevée causant une expérience utilisateur médiocre, une faible satisfaction, de fréquentes escalades, des coûts d assistance élevés et des dépenses inutiles de dépannage et d adaptation de l environnement. Lorsque vous concevez votre batterie de serveurs, assurez-vous qu elle puisse soutenir les objectifs de performances et de capacité établis, aussi bien lors des charges maximales régulières que pendant les pointes imprévues. La conception, les tests et l optimisation vous permettront de vérifier si la batterie dispose du matériel adéquat. Pour maintenir les objectifs de performances et s adapter à la croissance, il est toujours préférable de disposer de plus de ressources que nécessaire pour atteindre les objectifs. Le coût du surinvestissement en matériel est généralement bien inférieur aux dépenses cumulées pour résoudre les problèmes dus au sous-dimensionnement. Vous devez systématiquement dimensionner le système pour répondre de façon adéquate à la demande de pointe, qui peut être différente pour des services spécifiques à différentes heures. Pour estimer effectivement les besoins en capacité, vous devez identifier la période de demande la pire pour toutes les ressources. Il peut y avoir des charges accrues pour certains services et fonctionnalités à certaines heures de la journée, par exemple en début de matinée ou après le déjeuner. La batterie de serveurs doit également pouvoir supporter les pics non planifiés, par exemple lors d annonces à l échelle de l organisation où un nombre exceptionnellement élevé d utilisateurs accèdent à un site en même temps. Durant de telles périodes de forte demande, les utilisateurs subissent une latence élevée ou n obtiennent pas de réponse du tout de la batterie de serveurs si les ressources disponibles sont insuffisantes pour satisfaire la charge accrue sur la batterie de serveurs. Il faut également revoir la capacité de la batterie de serveurs lorsque des utilisateurs supplémentaires sont mis en service dans l entreprise. Des situations comme une fusion ou une acquisition, caractérisées par de nouveaux employés ou membres qui accèdent à la batterie de serveurs, peuvent avoir des effets défavorables sur les performances si elles ne sont pas planifiées et estimées à l avance. États opérationnels : zone verte et zone rouge 26

27 Pour décrire la charge d un système de production, nous faisons référence à deux états opérationnels : la zone verte qui correspond aux situations durant lesquelles le système fonctionne avec une charge normale et prévue, et la zone rouge qui correspond aux situations durant lesquelles la batterie de serveurs subit une demande temporaire très élevée de ressources qui ne peut être soutenue que sur de courtes périodes avant que des pannes ou d autres problèmes de performances ou de fiabilité ne se produisent. Zone verte Correspond aux situations où le serveur ou la batterie de serveurs fonctionne dans des conditions de charge normale ou de charge maximale quotidienne prévue. Une batterie de serveurs dans cette plage doit pouvoir soutenir des temps de réponse et une latence acceptables. Zone rouge Plage opérationnelle où la charge est supérieure à la charge maximale normale, mais où les demandes peuvent être encore traitées sur une période limitée. Cet état se caractérise par une latence supérieure à la normale et par des défaillances possibles à cause de la saturation des goulots d étranglement du système. Le but ultime de la conception d une batterie de serveurs est de déployer un environnement qui puisse constamment supporter une charge de zone rouge sans défaillance du service et avec une latence et un débit acceptables. Limitations et frontières logicielles Dans SharePoint Server 2010, il existe certaines limites qui ne sont absolument pas franchissables et d autres qui sont définies sur des valeurs par défaut et qui peuvent être modifiées par l administrateur de la batterie de serveurs. Il existe également certaines limites qui ne sont pas représentées par une valeur configurable, telles que le nombre de collections de sites par application Web. Les frontières sont des limites absolues qui ne sont absolument pas franchissables. Il est important de comprendre ces limites afin de ne pas concevoir votre batterie de serveurs sur des hypothèses erronées. Un exemple de frontière est la taille limite de 2 Go pour les documents ; vous ne pouvez pas configurer SharePoint Server 2010 de manière à stocker des documents qui dépassent 2 Go. Il s agit d une valeur prédéfinie qui ne peut absolument pas être dépassée. Les seuils possèdent une valeur par défaut qui ne peut pas être dépassée, à moins de la modifier. Dans certaines circonstances, les seuils peuvent être dépassés si l évolution de la conception de votre batterie de serveurs le nécessite, mais il est important de comprendre que cela risque d avoir une incidence sur les performances de la batterie de serveurs et sur la valeur effective des autres limites. La valeur par défaut de certains seuils peut être dépassée, mais dans la limite d une valeur maximum absolue. La taille limite des documents en est un bon exemple. Par défaut, cette taille limite est définie sur 50 Mo, mais peut être remplacée par la valeur maximum de 2 Go. 27

28 Les limites supportées définissent la valeur testée pour un paramètre donné. Les valeurs par défaut de ces limites ont été définies à l aide de tests et représentent les limitations connues du produit. Le dépassement des limites supportées risque de produire des résultats inattendus, une dégradation significative des performances ou d autres effets nuisibles. Certaines limites supportées sont des paramètres configurables qui sont définis par défaut sur la valeur recommandée, tandis que d autres limites concernent des paramètres qui ne sont pas représentés par une valeur configurable. Un exemple de limite supportée est le nombre de collections de sites par application Web. Cette limite est , qui constitue le nombre le plus élevé de collections de sites par application Web ayant satisfait aux tests d évaluation des performances. Il est important de noter que de nombreuses valeurs limites fournies dans ce document représentent un point dans une courbe qui décrit une charge croissante sur les ressources et une dégradation concomitante des performances à mesure que la valeur augmente. Par conséquent, le dépassement de certaines limites, telles que le nombre de collections de sites par application Web, peut ne causer qu une faible diminution des performances de la batterie de serveurs. Toutefois, dans la plupart des cas, le fonctionnement sur une limite établie ou une valeur approchante n est pas une meilleure pratique, car les cibles de performances et de fiabilité acceptables sont d autant plus facilement atteintes que la conception d une batterie de serveurs prévoit un compromis raisonnable entre les valeurs limites. Les recommandations sur les seuils et les limites supportées sont déterminées par les performances. En d autres termes, vous pouvez dépasser les valeurs par défaut des limites, mais l augmentation d une valeur limite peut avoir une incidence sur les performances de la batterie de serveurs et sur la valeur effective des autres limites. De nombreuses limites dans SharePoint Server 2010 peuvent être modifiées, mais il est important de comprendre l impact que peut avoir la modification d une limite donnée sur les autres parties de la batterie de serveurs. Si vous contactez les services de support technique Microsoft à propos d un système de production qui ne satisfait pas la configuration matérielle minimale décrite dans Hardware and software requirements (SharePoint Server 2010), le support sera limité tant que le système n est pas mis à niveau vers la configuration requise. Mode d établissement des limites Dans SharePoint Server 2010, les seuils et les limites supportées sont établis par les tests et l observation du comportement de la batterie de serveurs en fonction de charges croissantes jusqu au point où les opérations et les services de la batterie atteignent leurs limites de fonctionnement effectives. Étant donné que certains services et composants de la batterie de serveurs peuvent accepter plus de charge que d autres, dans certains cas, vous devez affecter une valeur limite basée sur une moyenne de plusieurs facteurs. Par exemple, les observations du comportement de la batterie de serveurs testée lorsque des collections de sites sont ajoutées indiquent que certaines fonctionnalités présentent une latence anormalement élevée tandis que d autres affichent des paramètres de fonctionnement encore acceptables. Par conséquent, la valeur maximum affectée au nombre de collections de sites n est pas absolue, mais calculée en fonction d un ensemble attendu de caractéristiques d utilisation dans lequel les performances globales de la batterie de serveurs sont acceptables pour la limite donnée dans certaines circonstances. 28

29 Si d autres services fonctionnent avec des paramètres plus élevés que ceux utilisés pour les tests des limites, les limites effectives maximales des autres services seront réduites. Il est donc important d effectuer des tests d échelle et de gestion de capacité rigoureux pour des déploiements spécifiques afin d établir des limites effectives pour l environnement considéré. Pour plus d informations sur les limitations et frontières et sur leur impact sur la gestion de la capacité, voir Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles. Différences fondamentales : SharePoint Server 2010 / Office SharePoint Server 2007 SharePoint Server 2010 offre un ensemble plus riche de fonctionnalités et un modèle topologique plus souple que les versions antérieures. Avant d utiliser cette architecture plus complexe pour fournir aux utilisateurs des fonctionnalités et des possibilités de traitement plus puissantes, vous devez étudier avec soin leur impact sur les performances et la capacité de la batterie de serveurs. Dans Office SharePoint Server 2007, il y avait quatre services majeurs que vous pouviez activer dans des fournisseurs de services partagés (SSP) : le service de recherche, le service de calcul Excel, le service de profil utilisateur et le service de catalogue de données métiers. En outre, un ensemble relativement plus petit de clients pouvait s interfacer directement avec Office SharePoint Server Dans SharePoint Server 2010, il y a plus de services disponibles, appelés SSA (SharePoint Service Application), et SharePoint Server 2010 offre une gamme plus large d applications clientes pouvant interagir avec la batterie de serveurs, y compris plusieurs nouvelles applications Office, des appareils mobiles, des outils de conception et des navigateurs. Voici quelques exemples de l impact des interactions clientes étendues sur les considérations en matière de capacité : SharePoint Server 2010 inclut des applications de mise en réseau qui s intègrent avec Outlook, ce qui permet aux clients Outlook 2010 d afficher des informations sur les destinataires du courrier électronique qui sont extraites de la batterie de serveurs SharePoint Server lorsque les messages électroniques sont affichés dans le client Outlook. Cela introduit un nouvel ensemble de schémas de trafic et une charge sur le serveur qu il faut prendre en compte. Certaines nouvelles fonctionnalités de clients Microsoft Office 2010 actualisent automatiquement les données par rapport à la batterie de serveurs SharePoint Server, même si les applications clientes sont ouvertes sans être utilisées activement. De tels clients, comme SharePoint Workspace et OneNote, introduisent également des nouveaux schémas de trafic et une charge sur le serveur qu il faut prendre en compte. Les nouvelles possibilités d interactivité Web de SharePoint Server 2010, comme Office Web Apps, qui permettent d éditer des fichiers Office directement depuis le navigateur, utilisent des appels AJAX qui introduisent de nouveaux schémas de trafic et une charge sur le serveur qu il faut prendre en compte. 29

30 Dans Office SharePoint Server 2007, le client principal utilisé pour interagir avec le serveur était le navigateur Web. Étant donné l ensemble de fonctionnalités enrichi de SharePoint Server 2010, le nombre global de demandes par seconde (RPS) est censé croître. De plus, le pourcentage de demandes émanant du navigateur est censé être inférieur à celui dans Office SharePoint Server 2007, ce qui libère de la place pour le pourcentage croissant de nouveau trafic émanant d autres clients du fait de leur adoption élargie à toute l organisation. Par ailleurs, SharePoint Server 2010 introduit de nouvelles fonctionnalités comme la prise en charge des vidéos incorporées natives qui peuvent ajouter une charge supplémentaire à la batterie de serveurs. Certaines fonctionnalités ont été également étendues pour supporter une échelle plus grande que les versions précédentes. La section suivante décrit ces interactions, services et fonctionnalités des clients et leur impact sur les performances et la capacité globales du système que vous devez prendre en compte lors de la conception de votre solution. Pour plus d informations sur la mise à niveau vers SharePoint Server 2010, voir Upgrading to SharePoint Server Services et fonctionnalités Le tableau suivant donne un aperçu simplifié des besoins en ressources des différents services à chaque niveau. Les cellules vides signalent que le service ne s exécute pas ou n a pas d impact à ce niveau. X Indique un coût minime ou négligeable sur la ressource. Le service peut partager cette ressource avec d autres services. XX Indique un coût moyen sur la ressource. Le service peut partager cette ressource avec d autres services ayant un impact minime. XX Indique un coût élevé sur la ressource. Le service ne doit normalement pas partager cette ressource avec d autres services. Pour plus d informations sur la planification des bases de données SQL Server, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Pour la liste des articles sur la gestion de la capacité disponibles pour de nombreux services et fonctionnalités SharePoint Server 2010 spécifiques (d autres articles seront ajoutés au fur et à mesure), voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010). Application de service UC de serveur Web RAM de serveur Web UC de serveur d applications RAM de serveur d applications UC de serveur SQL IOPS de serveur SQL Stockage de serveur SQL Service SharePoint Foundation XXX XXX XX XXX XXX 30

31 Application de service UC de serveur Web RAM de serveur Web Service Administration centrale UC de serveur d applications RAM de serveur d applications UC de serveur SQL IOPS de serveur SQL XX XX X X X Service de journalisation* XX XX XX XXX XXX Service de recherche SharePoint Application de service d affichage Word* XXX XXX XXX XXX XXX XXX XXX X X XXX XX Service PowerPoint* XX XX XXX XX Service de calcul Excel XX X XX XXX Service Visio* X X XXX XXX X X X Service Access* X X XXX XX X X X Service de profil utilisateur X XX XX XX XXX XXX XX Stockage de serveur SQL Service de métadonnées gérées* X XX XX XX X X XX Service Web Analytics* X X XXX XXX XXX Business Connection Service* XX XX XXX XXX InfoPath Forms Service XX XX XX XX X X X Service de conversion Word X X XXX XX X X X Application de service XX XX XXX XXX X X X 31

32 Application de service UC de serveur Web RAM de serveur Web UC de serveur d applications RAM de serveur d applications UC de serveur SQL IOPS de serveur SQL Stockage de serveur SQL PerformancePoint* Service Project* X X X X XXX XXX XX Solutions en bac à sable* X X XXX XXX Fonctionnalités de flux de travail* XXX XXX Service minuteur XX XX XX XX PowerPivot* X X XXX XXX XX XX XXX Remarque : Un astérisque (*) signale un nouveau service dans SharePoint Server Service SharePoint Foundation Service SharePoint central pour la collaboration de contenu. Dans les grands déploiements SharePoint Server, il est recommandé d allouer des serveurs Web redondants en fonction de la charge de trafic prévue, de dimensionner correctement les ordinateurs SQL Server qui servent les bases de données de contenu, et d allouer correctement le stockage en fonction de la taille de la batterie de serveurs. Service Administration centrale Le service d administration. Les besoins en capacité de ce service sont relativement faibles. Il est recommandé d activer ce service sur plusieurs serveurs de la batterie pour assurer la redondance. Service de journalisation Service qui enregistre les indicateurs d utilisation et d intégrité à des fins de suivi. Ce service fait des accès en écriture intensifs et peut nécessiter un espace disque relativement important selon le nombre d indicateurs et leur fréquence de journalisation. Dans les grands déploiements SharePoint Server 2010, il est recommandé d isoler la base de données d utilisation des bases de données de contenu sur des ordinateurs SQL Server différents. 32

33 Application de service de recherche SharePoint L application de service partagé qui fournit les capacités d indexation et d interrogation. Généralement, ce service est relativement gourmand en ressources, puisqu il peut servir des déploiements de contenu très volumineux. Dans les grands déploiements SharePoint Server où la recherche d entreprise est très importante, il est recommandé d utiliser une batterie de serveurs distincte pour héberger les applications de service de recherche, avec des ressources dédiées aux bases de données, d utiliser plusieurs serveurs d applications pour traiter les fonctions spécifiques de recherche (analyse ou interrogation), et des serveurs Web cibles dédiés sur les batteries de serveurs de contenu pour assurer un débit acceptable pour l analyse ou l interrogation. Vous pouvez également activer l application FAST Service comme étant votre application de service de recherche. Créez un ou plusieurs connecteurs FAST Search pour indexer le contenu avec FAST Search Server 2010 for SharePoint et créez un autre service FAST Search Query (SSA) pour interroger le contenu analysé par les connecteurs FAST Search. Application de service d affichage Word L activation de ce service vous permet d afficher des documents Word directement à partir du navigateur. Ce service est ajouté lorsque vous installez Office Web Apps en complément de SharePoint Server Ce service requiert un serveur d applications pour préparer les fichiers d origine en vue de l affichage dans le navigateur. Dans les grands déploiements SharePoint Server, il est recommandé d étendre le service à plusieurs serveurs d applications à des fins de redondance et de débit. Remarque : L édition dans le navigateur pour Word et OneNote est activée si vous installez Office Web Apps sur la batterie de serveurs SharePoint Server Cependant, cette fonctionnalité s exécute sur les serveurs Web de la batterie et n utilise aucune application de service. Application de service PowerPoint Ce service permet d afficher et de modifier des fichiers PowerPoint directement dans le navigateur, et de diffuser et partager des présentations PowerPoint en direct. Ce service est ajouté lorsque vous installez Office Web Apps sur SharePoint Server Ce service requiert un serveur d applications pour préparer les fichiers d origine en vue de l affichage dans le navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de déployer plusieurs serveurs d applications pour assurer une redondance et un débit acceptables, et d ajouter des serveurs Web supplémentaires si la diffusion PowerPoint est également fréquemment utilisée. Application de service de calcul Excel Ce service affiche les feuilles de calcul Excel directement dans le navigateur et effectue les calculs Excel sur le serveur. Il permet également de modifier les feuilles de calcul directement à partir du navigateur si vous installez Office Web Apps sur SharePoint Server Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d allouer un nombre suffisant de serveurs d applications dotés de suffisamment de RAM pour assurer des performances et un débit acceptables. PowerPivot pour SharePoint Ce service permet d afficher la fonction PowerPivot dans des feuilles de calcul Excel où elle est activée, directement à partir du navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment 33

34 utilisée, il est recommandé d allouer un nombre suffisant de serveurs d applications dotés suffisamment en RAM et UC pour assurer des performances et un débit acceptables. Pour plus d informations, voir Configuration matérielle et logicielle requise (PowerPivot pour SharePoint). Application de service Visio Ce service permet d afficher des graphiques Visio dynamiques directement dans le navigateur. Il dépend de l application de service d état de session, qui requiert une base de données SQL Server relativement petite. Le service Visio requiert un serveur d applications pour préparer les fichiers Visio d origine en vue de leur affichage dans le navigateur. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d étendre le service à plusieurs serveurs d applications dotés suffisamment en RAM et UC pour assurer des performances et un débit acceptables. Application de service Access Ce service permet d héberger des solutions Access dans SharePoint Server Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d étendre le service à plusieurs serveurs d applications dotés de suffisamment de RAM pour assurer des performances et un débit acceptables. Le service Access utilise SQL Reporting Services, qui requiert une base de données SQL Server pouvant être hébergée avec d autres bases de données. Application de service de profil utilisateur Ce service permet de mettre en œuvre les scénarios de réseau social dans SharePoint Server 2010 et active les fonctionnalités Mes sites, Marquage, Notes, Synchronisation de profil avec les annuaires et autres fonctionnalités de réseau social. Le service de profil requiert trois bases de données relativement gourmandes en ressources : une pour la synchronisation, une pour les profils et une pour les liaisons de mise en réseau. Ce service dépend de l application de service de métadonnées gérées. Dans les grands déploiements SharePoint Server, il est recommandé de distribuer ce service sur une batterie de serveurs dédiée aux services partagés, et de dimensionner correctement le niveau des serveurs de bases de données pour garantir des performances acceptables pour les transactions courantes et les travaux de synchronisation d annuaires. Application de service de métadonnées gérées Ce service permet de mettre en œuvre le magasin central de métadonnées et autorise la syndication des types de contenu à travers l entreprise. Ce service peut être fédéré sur une batterie de serveurs dédiée aux services. Il requiert une base de données qui peut être hébergée avec d autres bases de données. Application de service Web Analytics Ce service agrège et stocke les statistiques des caractéristiques d utilisation de la batterie de serveurs. Les besoins en stockage et ressources SQL Server de ce service sont relativement élevés. Ce service peut être fédéré sur une batterie de serveurs dédiée aux services. Dans les grands déploiements SharePoint Server, il est recommandé d isoler les bases de données Web Analytics des autres bases de données très importantes ou gourmandes en ressources en les hébergeant sur des serveurs de bases de données différents. Application Business Connection Service Ce service permet l intégration de diverses applications métiers organisationnelles avec SharePoint Server Il requiert un service d application pour maintenir les connexions de données à des ressources externes. 34

35 Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d allouer un nombre suffisant de serveurs d applications dotés de suffisamment de RAM pour assurer des performances acceptables. Application InfoPath Forms Service Ce service autorise les formulaires basés sur navigateur dans SharePoint Server 2010 et permet l intégration de l application cliente InfoPath pour la création de formulaires. Ce service requiert un serveur d applications et dépend de l application de service d état de session, qui requiert une base de données relativement petite. Il peut être hébergé avec d autres services ; ses besoins en capacité sont relativement faibles et leur croissance dépend de la fréquence d utilisation de cette fonctionnalité. Application de service d automatisation Word Ce service permet la conversion des fichiers Word dans un format, comme.doc, vers un autre format, comme.docx ou.pdf. Ce service requiert un serveur d applications. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d étendre le service à plusieurs serveurs d applications dotés de ressources UC suffisantes pour assurer un débit de conversion acceptable. Ce service requiert également une base de données relativement petite pour maintenir la file d attente des travaux de conversion. Application de service PerformancePoint Ce service active les fonctionnalités d aide à la décision PerformancePoint dans SharePoint Server 2010 et vous permet de créer des visualisations analytiques. Il requiert un serveur d applications et une base de données. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d allouer suffisamment de RAM aux serveurs d applications pour assurer des performances et un débit acceptables. Application de service Project Ce service active toutes les fonctionnalités de planification et de suivi de Microsoft Project Server 2010 en plus de SharePoint Server Ce service requiert un serveur d applications et une base de données relativement gourmande en ressources. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de dédier un serveur de bases de données pour la base de données Project Server et éventuellement de dédier une batterie de serveurs SharePoint Server pour les solutions de gestion Project Server. Service minuteur Le processus responsable de l exécution des diverses tâches planifiées sur les différents serveurs de la batterie. Le système exécute divers travaux du minuteur, certains s exécutant sur tous les serveurs de la batterie et d autres seulement sur des serveurs spécifiques en fonction du rôle du serveur. Certains travaux du minuteur sont gourmands en ressources et sont susceptibles de créer de la charge aussi bien sur le serveur local que sur les serveurs de bases de données, selon leur activité et la quantité de contenu qu ils exploitent. Dans les grands déploiements SharePoint Server où les travaux du minuteur sont susceptibles d avoir un impact sur la latence de l utilisateur final, il est recommandé de dédier un serveur pour isoler l exécution des travaux les plus gourmands en ressources. Flux de travail Cette fonctionnalité active les flux de travail intégrés dans SharePoint Server 2010 et exécute les flux de travail sur le serveur Web. L utilisation des ressources dépend de la complexité des flux de travail et du nombre total d événements qu ils gèrent. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé d ajouter des 35

36 serveurs Web ou d isoler un serveur pour gérer uniquement le service du minuteur de flux de travail afin que le trafic de l utilisateur final ne soit pas affecté et que les opérations de flux de travail ne soient pas retardées. Solutions en bac à sable Ce service permet l isolation du code personnalisé sur des ressources dédiées de la batterie de serveurs. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, il est recommandé de dédier des serveurs Web supplémentaires si le code personnalisé commence à avoir un impact sur les performances des serveurs. Nouvelles interactions des applications clientes avec SharePoint Server 2010 Cette section décrit quelques unes des nouvelles interactions client-serveur prises en charge par SharePoint Server 2010 et leurs implications sur la planification de la capacité. Le tableau suivant donne un aperçu simplifié de la charge standard que ces nouvelles fonctionnalités introduisent sur le système : X Indique une charge minime ou négligeable sur les ressources du système. XX Indique une charge moyenne sur les ressources du système. XX Indique une charge élevée sur les ressources du système. Client Trafic Charge utile Office Web Apps XXX XX Diffusion PowerPoint XXX X Application cliente Word et PowerPoint 2010 XX X Application cliente OneNote XXX XXX Outlook Social Connector XX XX SharePoint Workspace XXX XX Office Web Apps L affichage et la modification des fichiers Word, PowerPoint, Excel et OneNote est un sous-ensemble des requêtes de navigateur, avec des caractéristiques de trafic légèrement différentes. Ce genre d interaction introduit une charge de trafic relativement élevée pour permettre les fonctionnalités comme la co-création. Dans les grands déploiements SharePoint Server où ces fonctionnalités sont activées, une charge supplémentaire est à prévoir sur les serveurs Web. 36

37 Diffusion PowerPoint L ensemble des requêtes associées à l affichage d une présentation PowerPoint en direct dans le navigateur Web est un autre sous-ensemble des requêtes de navigateur. Lors des sessions de diffusion PowerPoint en direct, les clients participants demandent des changements auprès du service. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web. Applications clientes Word et PowerPoint 2010 Les clients Word et PowerPoint 2010 ont de nouvelles fonctionnalités qui tirent parti de la batterie de serveurs SharePoint Server. La co-création de document en est un exemple, où toutes les applications clientes participant à une session de co-création effectuent fréquemment des opérations de chargement sur le serveur ou de téléchargement depuis ce dernier. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web. Application cliente OneNote 2010 Le client OneNote 2010 interagit avec la batterie de serveurs SharePoint Server, comme dans la version précédente de OneNote, et utilise SharePoint Server 2010 pour partager et permettre la co-création de blocs-notes OneNote. Ce scénario introduit de la charge sur SharePoint Server 2010 même si le client est ouvert sans être utilisé activement. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web. Application cliente Outlook 2010 Outlook 2010 a une nouvelle fonctionnalité, Outlook Social Connector, qui tire parti de la batterie SharePoint Server (ce composant peut être ajouté aux versions précédentes d Outlook également). Cette fonctionnalité vous permet d afficher l activité sociale demandée à partir de la batterie SharePoint Server directement dans les messages électroniques. Dans les grands déploiements SharePoint Server où cette fonctionnalité est activée, une charge supplémentaire est à prévoir sur les serveurs Web. SharePoint Workspace Les clients SharePoint Workspace 2010 ont de nouvelles fonctionnalités qui tirent parti de la batterie SharePoint Server et vous permettent de synchroniser des sites Web, des listes et des bibliothèques de documents sur le client pour une utilisation hors connexion. SharePoint Workspace 2010 effectue une synchronisation régulière avec les objets associés du serveur lorsque le client s exécute, qu il soit utilisé activement ou non. Dans les grands déploiements SharePoint Server où cette fonctionnalité est fréquemment utilisée, une charge supplémentaire est à prévoir sur les serveurs Web. Différenciateurs clés d un déploiement SharePoint Server 2010 Chaque déploiement de SharePoint Server 2010 a un ensemble de caractéristiques clés qui le rendent unique et différent par rapport à d autres batteries de serveurs. Ces différenciateurs clés peuvent être classés en quatre catégories principales : Spécifications Décrivent le matériel, la topologie et la configuration de la batterie de serveurs. 37

38 Charge de travail Décrit la demande sur la batterie de serveurs, y compris le nombre d utilisateurs et les caractéristiques d utilisation. Ensemble de données Décrit les tailles et la distribution du contenu. Intégrité et performances Décrit les performances de la batterie de serveurs par rapport aux cibles de latence et de débit. Spécifications Matériel Le matériel comprend les ressources physiques de l ordinateur comme les processeurs, la mémoire et les disques durs. Il inclut également des composants réseau physiques comme les cartes réseau, les câbles, les commutateurs, les routeurs et les équilibreurs de charge matériels. De nombreux problèmes de performances et de capacité peuvent être résolus en s assurant que le matériel correct est utilisé. À l inverse, une seule mauvaise application de ressource matérielle, par exemple une mémoire insuffisante sur un serveur, peut nuire aux performances de toute la batterie de serveurs. Topologie La topologie est la distribution et les relations mutuelles du matériel et des composants de la batterie de serveurs. Il y a deux sortes de topologie : Topologie logique La carte des composants logiciels tels que les services et les fonctionnalités dans une batterie de serveurs. Topologie physique La carte des serveurs et des ressources physiques. En règle générale, le nombre d utilisateurs et les caractéristiques d utilisation déterminent la topologie physique d une batterie de serveurs, et les besoins de l entreprise tels que la prise en charge de fonctionnalités spécifiques dans la charge prévue déterminent la topologie logique. Configuration Nous utilisons le terme configuration pour décrire les paramètres du logiciel et leur définition. La configuration fait également référence à la mise en cache, à RBS et à définition des limites configurables, ainsi qu à toute partie de l environnement logiciel pouvant être définie ou modifiée pour satisfaire des exigences particulières. Charge de travail La charge de travail définit les caractéristiques opérationnelles clés de la batterie de serveurs, notamment la base d utilisateurs, la simultanéité, les fonctionnalités utilisées et les agents ou les applications clientes de l utilisateur qui sont utilisés pour se connecter à la batterie de serveurs. Les différentes fonctionnalités SharePoint Server ont différents coûts associés sur les ressources de la batterie de serveurs. La popularité des fonctionnalités les plus coûteuses peut avoir un impact considérable sur les performances et l intégrité du système. Identifier la 38

39 demande et les caractéristiques d utilisation prévisibles vous permettra de dimensionner correctement votre implémentation et de réduire le risque de constamment exécuter le système dans un état non fiable. Base d utilisateurs La base d utilisateurs d une application basée sur SharePoint Server est la combinaison du nombre total d utilisateurs et de leur répartition géographique. Par ailleurs, dans la base globale d utilisateurs, il y a des sous-groupes d utilisateurs qui peuvent utiliser des fonctionnalités ou des services donnés de façon plus intensive que d autres groupes. La simultanéité des utilisateurs est le pourcentage total d utilisateurs utilisant activement le système à un moment donné. Les indicateurs qui définissent la base d utilisateurs incluent le nombre total d utilisateurs uniques et le nombre d utilisateurs simultanés. Caractéristiques d utilisation Les performances d une batterie de serveurs peuvent être affectées non seulement par le nombre d utilisateurs en interaction avec le système, mais aussi par leurs caractéristiques d utilisation. Deux organisations ayant le même nombre d utilisateurs peuvent avoir des besoins sensiblement différents en fonction de la fréquence d accès des utilisateurs aux ressources de la batterie, et de l activation ou non de fonctionnalités et de services gourmands en ressources sur la batterie de serveurs. Les indicateurs qui décrivent les caractéristiques d utilisation incluent la fréquence des opérations uniques, le rapport opérationnel global (ratio des opérations de lecture et d écriture et des opérations administratives), ainsi que les schémas d utilisation et la charge pour les nouvelles fonctionnalités qui sont activées sur la batterie de serveurs (comme les sites Web Mon site, la recherche, les flux de travail et Office Web Apps). Ensemble de données Le volume de contenu stocké sur le système et les caractéristiques de l architecture de stockage du contenu peuvent avoir un impact significatif sur les performances et l intégrité globales du système. L identification de la taille, de la fréquence d accès et de la distribution des données vous permettra de dimensionner correctement le stockage sur le système pour éviter qu il ne devienne un goulot d étranglement qui ralentit les interactions des utilisateurs avec les services de la batterie de serveurs et affecte l expérience de l utilisateur final. Pour correctement estimer et concevoir l architecture de stockage d une solution basée sur SharePoint Server, vous devez connaître le volume de données à stocker sur le système et le nombre d utilisateurs interrogeant des données provenant de différentes sources de données. Le volume du contenu est un élément important pour dimensionner la capacité des disques, car il peut avoir une influence sur les performances d autres fonctionnalités et est également susceptible d affecter la latence et bande passante disponible du réseau. Les indicateurs qui définissent l ensemble de données incluent le volume total du contenu, le nombre total de documents, le nombre total de collections de sites et les tailles moyenne et maximum des collections de sites. Intégrité et performances L intégrité d une batterie SharePoint Server est fondamentalement une mesure ou un score simplifié qui reflète la fiabilité, la stabilité et les performances du système. Le niveau de performances de la batterie par rapport aux objectifs dépend fondamentalement des trois 39

40 premiers différenciateurs. L intégrité et le score des performances peuvent être suivis au moyen de la consolidation d un ensemble d indicateurs. Pour plus d informations, voir Surveillance et gestion de SharePoint Server Ces indicateurs incluent le temps de fonctionnement du système, la latence perçue par l utilisateur final, le taux d échecs de page et les indicateurs d utilisation des ressources (UC, RAM). Tout changement significatif apporté au matériel, à la topologie, à la configuration, à la charge de travail ou à l ensemble de données peut considérablement affecter la fiabilité et la réactivité du système. Le score d intégrité permet de faire le suivi des performances au fil du temps et d évaluer l impact du changement des conditions de fonctionnement ou des modifications du système sur la fiabilité de la batterie de serveurs. Architectures de référence SharePoint Server 2010 est un produit complexe et puissant et il n existe pas une solution d architecture adaptée à toutes les situations. Chaque déploiement SharePoint Server est unique et défini par les caractéristiques de l utilisation et des données. Chaque organisation doit effectuer un un processus approfondi de gestion de la capacité et tirer efficacement avantage de la souplesse que le système SharePoint Server 2010 offre pour personnaliser une solution dimensionnée correctement qui remplit au mieux les besoins organisationnels. Le concept des architectures de référence est de décrire et illustrer les principales catégories de déploiements SharePoint Server, mais pas de fournir une recette que les architectes puissent utiliser pour concevoir leurs solutions. Cette section s attache à décrire les vecteurs à partir desquels les déploiements SharePoint Server sont généralement mis à l échelle. Les architectures répertoriées ici permettent de comprendre aisément les différences générales entre ces catégories génériques, et de les distinguer en fonction des facteurs généraux de coût et de niveau d effort. Déploiement sur un seul serveur L architecture du déploiement sur un seul serveur est constituée d un serveur unique qui exécute SharePoint Server 2010 et une version de SQL Server prise en charge. Cette architecture peut convenir à des fins d évaluation, pour des développeurs ou pour une implémentation isolée non critique dans un service n ayant que quelques utilisateurs. Cependant, elle n est pas recommandée pour un environnement de production. 40

41 Déploiement sur une petite batterie de serveurs Un déploiement sur une petite batterie de serveurs est constitué d un serveur ou d un cluster de bases de données unique et d un ou deux ordinateurs équipés de SharePoint Server Cette architecture se caractérise principalement par la redondance et le basculement limités et un ensemble minimal de fonctionnalités SharePoint Server activées. Une petite batterie de serveurs est utile seulement pour les déploiements limités, avec un ensemble minimal d applications de service activées, une base d utilisateurs relativement petite, une charge d utilisation relativement faible (de quelques demandes par minute à très peu de demandes par seconde), et un volume de données relativement petit (de l ordre de 10 gigaoctets). Déploiement sur une batterie de serveurs moyenne Cette architecture introduit la répartition de la topologie sur trois niveaux : les serveurs Web dédiés, les serveurs d applications dédiés, et un ou plusieurs serveurs ou clusters de bases de données. La séparation du niveau des serveurs frontaux et du niveau des serveurs d applications permet une plus grande souplesse pour l isolation des services et l équilibrage de la charge sur le système. 41

42 Cette architecture, qui est la plus courante, inclut un large spectre de topologies de services et de tailles de batterie de serveurs. Un déploiement sur batterie de serveurs moyenne convient dans les environnements caractérisés par : Plusieurs applications de service réparties sur plusieurs serveurs. Un ensemble standard de fonctionnalités pouvant inclure le service Office Web Apps, le service de profil utilisateur, le service de métadonnées gérées et le service de calcul Excel. Une base d utilisateurs contenant des dizaines de milliers d utilisateurs et une charge de 10 à 50 demandes par seconde. Un magasin de données de 1 à 2 téraoctets. 42

43 43

44 Déploiement sur une grande batterie de serveurs Les déploiements sur de grandes batteries de serveurs introduisent la répartition des services et des solutions sur plusieurs batteries de serveurs, et une extension supplémentaire des niveaux sur une batterie de serveurs unique. Plusieurs services SharePoint Server peuvent être déployés sur une batterie de serveurs dédiée aux services qui traite les demandes provenant de plusieurs batteries de serveurs consommatrices. Dans ces grandes architectures, il y a généralement des serveurs Web, de multiples serveurs d applications, en fonction des caractéristiques d utilisation de chacun des services locaux (non partagés), et de multiples serveurs SQL Server ou clusters SQL Server, en fonction du volume de contenu et des bases de données des services d application activées sur la batterie de serveurs. Ces architectures sont conçues pour les environnements caractérisés par : Plusieurs applications de service fédérées et utilisées par une batterie de serveurs dédiée aux services, généralement le service de profil utilisateur, le service de recherche, le service de métadonnées gérées et le service Web Analytics. La plupart des autres applications de service sont activées localement. Une base d utilisateurs constituée de centaines de milliers d utilisateurs. Une charge d utilisation de l ordre de centaines de demandes par seconde. Un ensemble de données de l ordre de 10 téraoctets ou plus. 44

45 45

46 Voir aussi Concepts Planification de la capacité pour SharePoint Server 2010 Test de performances pour SharePoint Server 2010 Surveillance et gestion de SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) Autres ressources Hardware and software requirements (SharePoint Server 2010) 46

47 Planification de la capacité pour SharePoint Server 2010 Cet article explique comment planifier la capacité d une batterie de serveurs Microsoft SharePoint Server Lorsque vous avez une bonne appréciation et une bonne compréhension de la planification et de la gestion de capacité, vous pouvez appliquer vos connaissances au dimensionnement du système. Le dimensionnement est le terme employé pour décrire la sélection et la configuration de l architecture de données appropriée, la topologie physique et logique, ainsi que le matériel d'une plateforme de solution. Il existe de nombreuses considérations relatives à l utilisation et à la gestion de capacité qui affectent la façon dont vous devez déterminer les options de configuration et de matériel les plus appropriées. Avant de lire cet article, vous devez lire l article intitulé Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Dans cet article, nous décrivons les étapes à suivre pour effectuer une gestion de capacité efficace pour votre environnement. Chaque étape nécessite de disposer de certaines informations et génère un ensemble de résultats que vous utiliserez lors de l étape suivante. Pour chaque étape, ces exigences et informations générées sont décrites dans des tableaux. Dans cet article : Étape 1: modéliser Étape 2: concevoir Étape 3: piloter, tester et optimiser Étape 4: déployer Étape 5: analyser et assurer la maintenance Étape 1: modéliser La modélisation de votre environnement SharePoint Server 2010 débute par l analyse de vos solutions existantes et l évaluation de la demande attendue et des cibles pour le déploiement que vous envisagez de configurer. Vous devez commencer par recueillir des informations sur votre base d utilisateurs, les exigences en matière de données, la latence et les cibles de débit, et documenter les fonctionnalités SharePoint Server que vous souhaitez déployer. Utilisez cette section pour identifier les données que vous devez recueillir, comprendre comment les recueillir et comment elle peuvent être utilisées lors des étapes suivantes. 47

48 Comprendre votre charge de travail attendue et le groupe de données Le dimensionnement correct d une implémentation de SharePoint Server 2010 nécessite d étudier et de comprendre les caractéristiques de demande que votre solution est censée gérer. Comprendre cette demande implique de pouvoir décrire les caractéristiques de charge de travail (telles que le nombre d utilisateurs et les opérations les plus fréquemment utilisées) et les caractéristiques de groupe de données (telles que la taille et la distribution du contenu). Cette section peut vous aider à comprendre certains paramètres et métriques spécifiques que vous devez recueillir, ainsi que les mécanismes de collecte à votre disposition. Charge de travail La charge de travail décrit la demande que le système devra prendre en charge, la base d utilisateurs et les caractéristiques d utilisation. Le tableau suivant propose quelques métriques clés utiles pour déterminer votre charge de travail. Vous pouvez l utiliser pour enregistrer ces métriques à mesure que vous les recueillez. Caractéristiques de charge de travail Moyenne quotidienne de demandes par secondes Moyenne de demandes par secondes aux heures de pointe Nombre total d utilisateurs uniques par jour Valeur Nombre moyen d utilisateurs simultanés quotidien Nombre maximal d utilisateurs simultanés aux heures de pointe Nombre total de demandes par jour Distribution de charge de travail attendue Nombre de demandes par jour % Navigateur Web - Analyse de recherche Navigateur Web - Interaction de collaboration générale 48

49 Caractéristiques de charge de travail Valeur Navigateur Web - Interaction sociale Navigateur Web - Interaction générale Navigateur Web - Office Web Apps Clients Office Client OneNote SharePoint Workspace Synchronisation des flux RSS Outlook Outlook Social Connector Autres interactions (applications personnalisées/services Web) Utilisateurs simultanés Il est plus courant de mesurer la simultanéité des opérations exécutées sur la batterie de serveurs que le nombre d utilisateurs distincts générant des requêtes dans un laps de temps donné. Les métriques clés sont la moyenne quotidienne et les utilisateurs simultanés au pic de charge. Demandes par seconde Le nombre de demandes par seconde est un indicateur courant permettant de décrire la demande sur la batterie de serveurs, exprimée en nombre de demandes traitées par la batterie de serveurs par seconde, mais sans aucune différenciation quant au type ou à la taille des demandes. La base d utilisateurs de chaque organisation génère une charge système à un taux qui dépend des caractéristiques d utilisation unique de l organisation. Pour plus d informations sur ce terme, voir le Glossaire dans Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Nombre total de demandes par jour Le nombre total de demandes par jour est un bon indicateur quant à la charge globale que le système devra gérer. Il est plus courant de mesurer toutes les demandes à l exception des demandes de négociation d authentification (état HTTP 401) sur une période de 24 heures. 49

50 Nombre total d utilisateurs quotidiens - Le nombre total d utilisateurs est un autre indicateur clé quant à la charge globale que le système devra gérer. Cette mesure correspond au nombre réel d utilisateurs uniques durant une période de 24 heures, et non au nombre total d employés dans l organisation. Remarque : Le nombre total d utilisateurs quotidiens peut indiquer le potentiel de croissance de la charge sur la batterie de serveurs. Par exemple, si le nombre d utilisateurs potentiels est de employés, une valeur de utilisateurs quotidiens indique que la charge est susceptible de croître sensiblement à mesure que l adoption par les utilisateurs augmente. Distribution de la charge de travail Comprendre la distribution des demandes en fonction des applications clientes qui interagissent avec la batterie de serveurs peut aider à prévoir la tendance et les modifications de charge après la migration vers SharePoint Server À mesure que les utilisateurs passent à des versions plus récentes de clients telles qu Office 2010 et commencent à utiliser les nouvelles fonctionnalités et de nouveaux modèles de charge, il est prévu que le nombre de demandes par seconde et le nombre total de demandes augmentent. Pour chaque client, nous pouvons décrire le nombre d utilisateurs distincts utilisant ce client dans un laps de temps d une journée et le nombre total de demandes générées par le client ou la fonctionnalité sur le serveur. Par exemple, le tableau ci-dessous présente un instantané d un environnement Microsoft interne actif servant une solution sociale standard. Dans cet exemple, on peut constater que la majeure partie de la charge est générée par le robot de recherche et la navigation Web standard des utilisateurs finaux. On peut également remarquer qu il existe une charge importante introduite par la nouvelle fonctionnalité Outlook Social Connector (6,2 % des demandes). 50

51 51

52 52

53 Évaluation de la charge de travail de production Lors de l évaluation du débit que votre batterie de serveurs doit être en mesure de prendre en charge, commencez par évaluer la combinaison de transactions qui seront utilisées dans votre batterie. Axez votre travail sur l analyse des transactions les plus fréquemment utilisées, sur leur fréquence d utilisation et sur le nombre d utilisateurs. Cela vous aidera à vérifier ultérieurement si la batterie de serveurs peut supporter cette charge lors des tests de préproduction. Le diagramme suivant décrit la relation entre la charge de travail et la charge sur le système : 53

54 54

55 Pour évaluer la charge de travail attendue, recueillez les informations suivantes : Identifiez les interactions utilisateur telles que les consultations de pages Web classiques, les chargements et téléchargements de fichiers, les affichages et modifications Office Web Application dans le navigateur, les interactions de co-création, les synchronisations de sites SharePoint Workspace, les connexions sociales Outlook, la synchronisation de flux RSS (dans Outlook ou autres visionneuses), les diffusions PowerPoint, les bloc-notes partagés OneNote, les classeurs partagés Excel Services, les applications partagées Excel Services et autres. Pour plus d informations, voir la section Services et fonctionnalités de l article Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Concentrez-vous sur l identification des interactions qui peuvent être propres à votre déploiement et recherchez l impact attendu d une telle charge (par exemple, utilisation significative de formulaires InfoPath, calculs Excel Services et solutions dédiées similaires). Identifiez les opérations système telles que les analyses de recherche incrémentielles, les sauvegardes quotidiennes, les travaux du minuteur de synchronisation des profils, le traitement des analyses Web, les travaux du minuteur de journalisation et autres. Évaluez le nombre total d utilisateurs par jour qui utiliseront chaque fonctionnalité, dérivez une estimation du nombre d utilisateurs simultanés et du niveau élevé de demandes par seconde. Vous prendrez comme base certaines hypothèses telles que la concurrence d accès existante et le facteur de demandes par seconde par utilisateur simultané qui diffère d une fonctionnalité à l autre. Pour vos estimations, utilisez le tableau de charge de travail proposé plus haut dans cette section. Il est important de se concentrer sur les heures de pointe plutôt que sur le débit moyen. La planification de l activité de pointe vous permettra de dimensionner correctement votre solution SharePoint Server Si vous avez une solution Office SharePoint Server 2007 existante, vous pouvez analyser les fichiers journaux des services Internet (IIS) ou tirer parti d autres outils d analyse Web à votre disposition afin de mieux comprendre certains des comportements attendus de la solution existante. Vous pouvez également consulter les instructions fournies dans la section ci-dessous pour plus d informations. Si vous ne migrez pas à partir d une solution existante, remplissez le tableau à l aide d estimations. Lors des étapes suivantes, vous devrez valider vos hypothèses et affiner le système. Analyse de vos journaux IIS SharePoint Server 2010 Pour découvrir les métriques clés concernant un déploiement SharePoint Server 2010 existant, telles que le nombre d utilisateurs actifs, l intensité de l utilisation du système, les types de demandes entrantes et le type de clients desquelles ces demandes proviennent, il est nécessaire d extraire les données des journaux ULS et IIS. L une des méthodes les plus simples pour obtenir ces données consiste à utiliser Log Parser, un outil puissant disponible gratuitement en téléchargement auprès de Microsoft. Log Parser peut lire et écrire dans plusieurs formats textuels et binaires, y compris tous les formats IIS. Pour plus d informations sur la façon d analyser l utilisation de SharePoint Server 2010 à l aide de Log Parser, voir Analyse de l utilisation des Produits et technologies Microsoft SharePoint (éventuellement en anglais) ( 55

56 Vous pouvez télécharger Log Parser 2.2 à l adresse (éventuellement en anglais). Groupe de données Le terme «groupe de données» décrit le volume de contenu stocké dans le système et comment il peut être distribué dans le magasin de données. Le tableau suivant propose quelques métriques clés utiles pour déterminer votre groupe de données. Vous pouvez utiliser ce tableau pour enregistrer ces métriques à mesure que vous les recueillez. Objet Taille de la base de données (en Go) Nombre de bases de données de contenu Nombre de collections de sites Nombre d applications Web Valeur Nombre de sites Taille d index de recherche (nombre d articles) Nombre de documents Nombre de listes Taille moyenne des sites Taille de site maximale Nombre de profils utilisateur Taille du contenu Comprendre la taille du contenu que vous comptez stocker dans le système SharePoint Server 2010 est important pour la planification et l architecture du stockage système et pour le dimensionnement correct de la solution de recherche qui analysera et indexera ce contenu. La taille du contenu est décrite en terme d espace disque total. Si vous migrez du contenu à 56

57 partir d un déploiement existant, il peut être plus simple d identifier la taille totale que vous déplacerez ; lors de la planification, vous devez prendre en compte la croissance ultérieure en fonction de la tendance prévue. Nombre total de documents Outre la taille du corpus de données, il est important d effectuer le suivi du nombre total d éléments. Le système réagit différemment si 100 Go de données sont composées de 50 fichiers de 2 Go plutôt que de fichiers de 1 Ko. Dans les déploiements à grande échelle, moins il y a de contrainte sur un élément, un document ou une zone de documents, meilleures sont les performances. Un contenu largement distribué, tel que plusieurs petits fichiers sur de nombreux sites et collections de sites, est plus facile à servir qu une bibliothèque de documents unique de grande taille contenant de très gros fichiers. Taille maximale de la collection de sites Il est important d identifier la plus grande unité de contenu que vous stockerez dans SharePoint Server 2010 ; en règle générale, il existe une exigence organisationnelle qui vous empêche de fractionner cette unité de contenu. La taille moyenne de toutes les collections de sites et l estimation du nombre total de collections de sites sont des indicateurs supplémentaires qui vous aideront à identifier votre architecture de données optimale. Caractéristiques des données des applications de service Outre les besoins en stockage du magasin de contenu, vous devez analyser et évaluer la taille d autres magasins SharePoint Server 2010, entre autres : Taille totale de l index de recherche Taille totale de la base de données de profils en fonction du nombre d utilisateurs dans le magasin de profils Taille totale de la base de données sociales en fonction du nombre prévu de liens de mise en réseau, de collègues et d activités Taille du magasin de métadonnées Taille de la base de données d utilisation Taille de la base de données Web Analytics Pour plus d informations sur la façon d évaluer les tailles des bases de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Définition des objectifs de performances et de fiabilité de la batterie de serveurs L un des livrables de l Étape 1 : modéliser est une bonne compréhension des cibles de performances et de fiabilité adaptées aux besoins de votre organisation. Une solution SharePoint Server à la conception correcte doit être en mesure d atteindre 99,99 % de disponibilité avec un temps de réponse serveur inférieur à une seconde. Les indicateurs utilisés pour décrire les performances et la fiabilité de la batterie de serveurs sont les suivants : Disponibilité du serveur Généralement décrite en terme de pourcentage du temps de fonctionnement global du système. Vous devez effectuer le suivi des temps d arrêt inattendus et comparer la disponibilité globale à l objectif organisationnel défini. Les cibles sont généralement décrites par un certain nombre de neuf (par exemple, 99 %, 99,9 %, 99,99 %). 57

58 Réactivité du serveur Le temps nécessaire à la batterie de serveurs pour traiter les demandes est un bon indicateur de suivi de l intégrité de la batterie de serveurs. Cet indicateur est généralement appelé «latence côté serveur» et il est courant d utiliser la valeur de latence moyenne ou médiane (50ème percentile) des demandes quotidiennes prises en charge. Les cibles sont généralement décrites en termes de secondes ou de valeurs inférieures à une seconde. Notez que si votre organisation a comme objectif de servir les pages de SharePoint Server 2010 en moins de deux secondes, l objectif côté serveur doit être inférieur à une seconde, afin de laisser à la page le temps d atteindre le client sur le réseau et de s afficher dans le navigateur. De plus, des temps de réponse serveur plus longs sont des signes qui traduisent une mauvaise intégrité de la batterie, ceci ayant généralement un impact sur le débit et le nombre de demandes par seconde pouvant rarement suivre si vous passez plus d une seconde sur le serveur sur la plupart des demandes. Pointes de serveur L un des autres indicateurs de latence côté serveur qu il est préférable d analyser est le comportement des 5 % de demandes les plus lentes. Les demandes les plus lentes sont généralement celles qui impactent le système lorsqu il est soumis à une charge élevée ou, ce qui est encore plus fréquent, celles affectées par une activité moins fréquente qui se produit pendant que des utilisateurs interagissent avec le système ; un système avec une bonne intégrité est un système dont vous contrôlez également les demandes les plus lentes. Ici, la cible est semblable à la réactivité du serveur, mais pour obtenir une réponse inférieure à une seconde vous devrez créer un système disposant de nombreuses ressources de secours afin de gérer les pics de charge. Utilisation des ressources système Parmi les autres indicateurs courants utilisés pour effectuer le suivi de l intégrité du système figurent un ensemble de compteurs système qui indiquent l intégrité de chaque serveur dans la topologie de batterie. Les indicateurs les plus fréquemment utilisés dont il faut effectuer le suivi sont le pourcentage d utilisation du processeur et la mémoire disponible ; toutefois, il existe plusieurs autres compteurs qui peuvent aider à identifier un système à l intégrité douteuse ; vous trouverez davantage de détails lors de l Étape 5 : analyser et assurer la maintenance. Étape 2: concevoir Maintenant que vous avez terminé la collecte des faits ou des estimations quant à la solution que vous avez besoin de fournir, vous êtes prêt pour l étape suivante : la conception d une architecture qui, selon vous, pourra prendre en charge la demande attendue. À la fin de cette étape, vous devriez avoir une conception pour votre topologie physique et une disposition pour votre topologie logique, ce qui devrait vous permettre de procéder aux achats nécessaires. Les spécifications matérielles et le nombre d ordinateurs utilisés sont étroitement liés. Pour gérer une charge spécifique, il existe plusieurs solutions. Il est courant d utiliser un petit ensemble d ordinateurs puissants (montée en puissance par unité) ou un plus grand ensemble de petits ordinateurs (montée en puissance parallèle) ; chaque solution a ses avantages et ses inconvénients en termes de capacité, de redondance, d alimentation, de coût, d espace et autres considérations. 58

59 Nous vous recommandons de commencer par déterminer votre architecture et votre topologie. Définissez comment vous envisagez de disposer les différentes batteries de serveurs et les différents services de chaque batterie, puis choisissez les spécifications matérielles de chacun des serveurs de votre conception. Vous pouvez également identifier les spécifications matérielles que vous êtes censé déployer (de nombreuses organisations sont contraintes de respecter certaines normes d entreprise), puis définir votre architecture et votre topologie. Utilisez le tableau suivant pour enregistrer vos paramètres de conception. Les données incluses sont des exemples de données et ne doivent pas être utilisées pour dimensionner votre batterie de serveurs. Elles ont pour but de montrer comment utiliser ce tableau pour vos propres données. Rôle Type (standard ou virtuel) Nombre d ordinateurs Processeurs RAM Besoin IOPS Taille de disque système d exploitation + journal Lecteur de données Serveurs Web Virtuel 4 4 cœurs 8 S/O 400 Go S/O Serveur de bases de données de contenu Standard 1 cluster 4 quad-core 2,33 (GHz) 48 2 k 400 Go 20 disques de K TPM Serveurs d applications Virtuel 4 4 cœurs 16 S/O 400 Go S/O Serveur Web cible d analyse de recherche Virtuel 1 4 cœurs 8 S/O 400 Go S/O Serveur de requête de recherche Serveur de robot de recherche Standard 2 2 quad-core 2,33 (GHz) Standard 2 2 quad-core 2,33 (GHz) 32 S/O 400 Go 500 Go Go S/O Serveur de bases de Standard 1 cluster 4 quad-core 48 4 k (réglé 100 Go 16 59

60 Rôle Type (standard ou virtuel) Nombre d ordinateurs Processeurs RAM Besoin IOPS Taille de disque système d exploitation + journal Lecteur de données données d analyse de recherche 2,33 (GHz) pour la lecture) disques de K TPM Base de données de magasin de propriétés de recherche + serveur de bases de données d administration Standard 1 cluster 4 quad-core 2,33 (GHz) 48 2 k (réglé pour l écriture) 100 Go 16 disques de K TPM Déterminer votre architecture de point de départ Cette section explique comment sélectionner une architecture de point de départ. Lorsque vous déployez SharePoint Server 2010, vous pouvez choisir parmi une gamme de topologies pour implémenter votre solution ; vous pouvez déployer un seul serveur ou de nombreux serveurs dans une batterie SharePoint Server avec des serveurs de bases de données en cluster ou en miroir et des serveurs d applications distincts pour divers services. Ultérieurement, vous sélectionnerez les configurations matérielles en fonction des exigences de chacun des rôles et en fonction de vos besoins en matière de capacité, de disponibilité et de redondance. Commencez par examiner les différentes architectures de référence et déterminer la structure de votre batterie de serveurs, puis décidez si vous devez fractionner votre solution sur plusieurs batteries ou fédérer certains services, tels que la recherche, sur une batterie de serveurs dédiée. Pour plus d informations, voir la section Architectures de référence dans Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Études de cas techniques SharePoint Server 2010 Les instructions d aide à la gestion de capacité pour SharePoint Server 2010 comprennent un certain nombre d études de cas techniques d environnements de production existants qui présentent une description détaillée d environnements de production SharePoint Server existants. D autres études de cas techniques seront publiées au fil du temps ; elles pourront servir de référence quant à la conception d un environnement SharePoint Server à des fins spécifiques. 60

61 Vous pouvez utiliser ces études de cas en guise de référence lors de la conception de l architecture de vos solutions SharePoint Server, en particulier si vous constatez que la description de ces caractéristiques de différentiation clés spécifiques au déploiement est semblable aux demandes et aux cibles de la solution dont vous concevez l architecture. Ces documents décrivent les informations suivantes pour chaque étude de cas documentée : Spécifications, telles que le matériel, la topologie de batterie de serveurs et la configuration Charge de travail, y compris la base d utilisateurs et les caractéristiques d utilisation Groupe de données, y compris les tailles de contenu, les caractéristiques de contenu et la distribution du contenu Intégrité et performances, y compris un ensemble d indicateurs enregistrés décrivant les caractéristiques de fiabilité et de performances de la batterie de serveurs Pour plus d informations, téléchargez les documents pertinents à partir de la page Web Études de cas techniques de performances et de capacité ( Sélectionner votre matériel La sélection des spécifications correctes pour les ordinateurs de votre batterie de serveurs est une étape cruciale pour garantir une fiabilité et des performances correctes pour votre déploiement. L un des concepts essentiels à retenir est que vous devez prévoir les pics de charge et les heures de pointe ; autrement dit, si votre batterie de serveurs fonctionne dans des conditions de charge moyenne, il doit y avoir suffisamment de ressources disponibles pour gérer la demande la plus élevée attendue tout en atteignant les objectifs de débit et latence. Les principales fonctionnalités matérielles de capacité et de performances des serveurs reflètent les quatre catégories principales suivantes : puissance de traitement, performances des disques, capacité réseau et capacité mémoire d un système. Il convient également d évaluer l utilisation d ordinateurs virtuels. Une batterie de serveurs SharePoint Server peut être déployée à l aide d ordinateurs virtuels. Bien qu il n ait pas été prouvé que cela augmente les performances, cela procure des avantages en matière de facilité de gestion. La virtualisation des ordinateurs SQL Server n est généralement pas recommandée, mais il peut y avoir certains avantages à virtualiser les couches de serveurs Web et de serveurs d applications. Pour plus d informations, voir Planification de la virtualisation( Conseils relatifs à la sélection du matériel Choix des processeurs SharePoint Server 2010 est disponible uniquement pour les processeurs 64 bits. En règle générale, une quantité plus élevée de processeurs vous permettra de répondre à une demande plus élevée. 61

62 Dans SharePoint Server 2010, les serveurs Web évoluent à mesure que vous ajoutez des cœurs (nous avons testé jusqu à 24 cœurs) ; plus le serveur possède de cœurs, plus la charge qu il peut soutenir est élevée (tous les autres paramètres étant égaux). Dans les grands déploiements de SharePoint Server, il est recommandé d allouer plusieurs serveurs Web à quatre cœurs (qui peuvent être virtualisés) ou moins de serveurs Web plus puissants (8, 16 ou 24 cœurs). Les besoins en capacité de traitement des serveurs d applications varient selon le rôle du serveur et les services qu il exécute. Certaines fonctionnalités de SharePoint Server exigent une puissance de traitement supérieure à d autres. Par exemple, le service de recherche de SharePoint dépend fortement de la puissance de traitement du serveur d applications. Pour plus d informations sur les besoins en ressources des fonctionnalités et services de SharePoint Server, voir Fonctionnalités et services plus haut dans ce document. Les besoins en capacité de traitement pour SQL Server dépendent également des bases de données de service hébergées par un ordinateur SQL Server. Pour plus d informations sur le comportement et les exigences par défaut de chaque base de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Choix de la mémoire Vos serveurs nécessiteront une quantité variable de mémoire, selon leur fonction et leur rôle. Par exemple, les serveurs exécutant les composants d analyse de recherche traiteront les données plus rapidement s ils disposent d une grande quantité de mémoire car les documents sont lus en mémoire pour le traitement. Les serveurs Web qui tirent parti des nombreuses fonctionnalités de mise en cache de SharePoint Server 2010 peuvent également nécessiter davantage de mémoire. En règle générale, les besoins en mémoire des serveurs Web dépendent fortement du nombre de pools d applications activés dans la batterie de serveurs et du nombre de requêtes simultanées satisfaites. Dans la plupart des déploiements de production SharePoint Server, il est recommandé d allouer au moins 8 Go de RAM sur chaque serveur Web, 16 Go étant la valeur recommandée pour les serveurs avec davantage de trafic ou pour les déploiements pour lesquels plusieurs pools d applications sont configurés pour l isolation. Les besoins en mémoire des serveurs d applications diffèrent également ; certaines fonctionnalités de SharePoint Server exigent davantage de mémoire sur la couche Application que d autres. Dans la plupart des déploiements de production SharePoint Server, il est recommandé d allouer au moins 8 Go de RAM sur chaque serveur d applications ; les serveurs d applications de 16 Go, 32 Go et 64 Go sont courants lorsque de nombreux services d applications sont activés sur le même serveur ou lorsque des services qui dépendent fortement de la mémoire, tels que le service de calcul Excel et le service de recherche SharePoint Server, sont activés. Les besoins en mémoire des serveurs de bases de données dépendent étroitement de la taille des bases de données. Pour plus d informations sur le choix de la mémoire pour vos ordinateurs SQL Server, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Choix des réseaux Outre les avantages offerts aux utilisateurs si les clients disposent d un accès rapide aux données par le biais du réseau, une batterie de serveurs distribuée doit disposer d un accès rapide pour la communication entre les serveurs. Ceci est particulièrement vrai lorsque vous 62

63 distribuez des services sur plusieurs serveurs ou lorsque vous fédérez certains des services à d autres batteries. Il existe un trafic important dans une batterie de serveurs sur la couche serveur Web, la couche serveur d applications et la couche serveur de bases de données ; le réseau peut donc facilement devenir un goulet d étranglement dans certaines conditions, par exemple en présence de gros fichiers ou de charges très élevées. Les serveurs Web et les serveurs d applications doivent être configurés avec au moins deux cartes d interface réseau (NIC) : une pour gérer le trafic des utilisateurs finaux et l autre pour gérer la communication entre les serveurs. La latence du réseau entre les serveurs peut avoir un impact significatif sur les performances ; il est donc important de conserver moins de 1 milliseconde de latence réseau entre le serveur Web et les ordinateurs SQL Server qui hébergent les bases de données de contenu. Les ordinateurs SQL Server qui hébergent chaque base de données d application de service doivent se trouver le plus proche possible du serveur d applications consommateur. Le réseau entre les serveurs de la batterie doit avoir au moins 1 Gbps de bande passante. Choix des disques et du stockage La gestion des disques ne consiste pas simplement à fournir suffisamment d espace pour vos données. Vous devez évaluer la demande en cours et la croissance et vous assurer que l architecture de stockage ne ralentit pas le système. Vous devez toujours vous assurer de disposer d au moins 30 pour cent de capacité supplémentaire sur chaque disque, au-delà de votre estimation en besoin de données la plus élevée, afin de pouvoir satisfaire la croissance future. En outre, dans la plupart des environnements de production, la vitesse de disque (IOps) est essentielle pour fournir un débit suffisant afin de répondre aux exigences de stockage des serveurs. Vous devez évaluer la quantité de trafic (IOps) qui sera requise par les principales bases de données dans votre déploiement et allouer suffisamment de disques pour satisfaire ce trafic. Pour plus d informations sur le choix des disques pour les serveurs de bases de données, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Les serveurs Web et serveurs d applications ont également des besoins en matière de stockage. Dans la plupart des environnements de production, il est recommandé d allouer au moins 200 Go d espace disque pour le système d exploitation et les fichiers temporaires et 150 Go d espace disque pour les journaux. Étape 3: piloter, tester et optimiser La phase de test et d optimisation est un élément critique pour l efficacité de la gestion de la capacité. Vous devez tester les nouvelles architectures avant de les déployer en production et mener des tests d acceptation en plus de respecter les meilleures pratiques d analyse suivantes, afin de vous assurer que les architectures que vous concevez répondent aux objectifs en matière de performances et de capacité. Cela vous permet d identifier et d optimiser les goulets d étranglement potentiels avant qu ils n affectent les utilisateurs dans un déploiement actif. Si vous effectuez une mise à niveau à partir d un environnement Office SharePoint Server 2007 et que vous prévoyez d apporter des modifications architecturales, ou si vous évaluez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server, 63

64 les tests revêtent une importance toute particulière si vous souhaitez vous assurer que votre environnement SharePoint Server répond aux objectifs de performances et de capacité. Une fois que vous avez testé votre environnement, vous pouvez analyser les résultats des tests pour déterminer quelles modifications doivent être apportées afin d atteindre les objectifs de performances et de capacité définis à l Étape 1 : modéliser. Voici la liste des sous-étapes recommandées pour la pré-production : Créer l environnement de test qui simule l architecture initiale que vous avez conçue à l Étape 2 : concevoir. Remplir le stockage avec le groupe de données ou la partie de groupe de données que vous avez identifié à l Étape 1 : modéliser. Appliquer une contrainte sur le système avec une charge synthétique qui représente la charge de travail identifiée à l Étape 1 : modéliser. Exécuter les tests, analyser les résultats et optimiser votre architecture. Déployer votre architecture optimisée dans votre centre de données et déployer un projet pilote avec un ensemble d utilisateurs de taille réduite. Analyser les résultats du pilote, identifier les goulets d étranglement potentiels et optimiser l architecture. Tester de nouveau si nécessaire. Déployer dans l environnement de production. Tester Les tests constituent un facteur critique en vue d établir la faculté de la conception de votre système à supporter votre charge de travail et les caractéristiques d utilisation. Pour plus d informations sur les tests de votre déploiement SharePoint Server 2010, voir Test de performances pour SharePoint Server Créer un plan de test Créer l environnement de test Créer des tests et des outils Déployer l environnement pilote Avant de déployer SharePoint Server 2010 dans un environnement de production, il convient tout d abord de déployer un environnement pilote et de tester soigneusement la batterie de serveurs pour vous assurer qu elle peut satisfaire les objectifs de capacité et de performances pour votre charge maximale attendue. Nous vous recommandons de tester au préalable l environnement pilote avec une charge synthétique, en particulier pour les déploiements à grande échelle, puis d appliquer une contrainte à l aide d un petit ensemble d utilisateurs et de contenu actifs. L analyse d un environnement pilote avec un petit ensemble d utilisateurs actifs offre l avantage de 64

65 pouvoir valider certaines des hypothèses que vous avez mises en avant concernant les caractéristiques d utilisation et la croissance du contenu avant de basculer totalement en production. Optimiser Si vous ne pouvez pas atteindre vos objectifs de capacité et de performances en faisant monter votre matériel de batterie de serveurs en puissance ou en apportant des modifications à la topologie, il peut s avérer nécessaire de modifier votre solution. Par exemple, si vos exigences initiales concernaient une seule batterie de serveurs pour la collaboration, la recherche et les fonctionnalités sociales, vous devrez peut-être fédérer certains des services (tels que la recherche) sur une batterie de serveurs de services dédiée ou répartir la charge de travail sur plusieurs batteries de serveurs. Une alternative consiste à déployer une batterie de serveurs dédiée pour les fonctionnalités sociales et une autre pour la collaboration d équipe. Étape 4: déployer Une fois que vous avez exécuté votre série de tests finale et confirmé que l architecture que vous avez sélectionnée peut répondre aux objectifs de performances et de capacité définis à l Étape 1 : modéliser, vous pouvez déployer votre environnement SharePoint Server 2010 en production. La stratégie de déploiement appropriée varie en fonction de l environnement et de la situation. Bien que le déploiement général de SharePoint Serverdépasse la portée de ce document, certaines activités peuvent être suggérées suite à l exercice de planification de capacité. Voici quelques exemples : Déploiement d une nouvelle batterie de serveurs SharePoint Server : l exercice de planification de la capacité doit avoir orienté et confirmé les plans pour une conception et un déploiement de SharePoint Server Dans ce cas, le déploiement sera le premier déploiement à grande échelle de SharePoint Server Il nécessitera le déplacement ou la reconstruction des serveurs et services qui ont été utilisés lors des exercices de planification de capacité vers l environnement de production. Il s agit du scénario le plus simple, car aucune modification ou mise à niveau de batterie existante n est nécessaire. Mise à niveau d une batterie de serveurs Office SharePoint Server 2007 vers SharePoint Server 2010: l exercice de planification de capacité doit avoir validé la conception d une batterie qui répond à la demande actuelle et peut monter en puissance de façon à satisfaire toute augmentation de demande et d utilisation d une batterie SharePoint Server Une partie de l exercice de planification de capacité doit avoir inclus des migrations tests afin de vérifier la durée nécessaire au processus de mise à niveau, de déterminer si aucun code personnalisé ne doit être modifié ou remplacé, si des outils tiers doivent être mis à jour, et ainsi de suite. À l issue de la phase de planification de capacité, vous devez disposer d une conception validée, connaître la durée nécessaire à la mise à niveau et posséder un plan détaillant le processus de mise à niveau le plus adéquat, par exemple une mise à niveau sur place ou une migration des bases de données de contenu dans une nouvelle batterie de serveurs. Si vous effectuez une mise à niveau sur 65

66 place lors de la planification de capacité, vous aurez peut-être identifié des considérations relatives aux temps d arrêt et constaté que du matériel supplémentaire ou mis à niveau est nécessaire. L exercice de planification doit avoir généré une liste des modifications matérielles nécessaires et un plan détaillé concernant le déploiement préalable des modifications matérielles dans la batterie de serveurs. Une fois que la plateforme matérielle validée lors de la planification de capacité est en place, vous pouvez passer au processus de mise à niveau vers SharePoint Server Amélioration des performances d une batterie de serveurs SharePoint Server 2010 existante : l exercice de planification de capacité doit vous avoir aidé à identifier les goulets d étranglement dans votre implémentation actuelle, à trouver des moyens de réduire ou d éliminer les goulets d étranglement et à valider une implémentation améliorée qui répond à vos besoins professionnels pour les services SharePoint Server. Il existe différentes façons par lesquelles les problèmes de performances peuvent avoir été résolus : de la simple réaffectation des services sur un matériel existant à la mise à niveau du matériel existant, en passant par l ajout de matériel supplémentaire et l ajout de services supplémentaires sur ce matériel. Les différentes approches doivent être testées et validées lors de l exercice de planification de capacité, puis un plan de déploiement doit être formulé en fonction des résultats de ces tests. Étape 5: analyser et assurer la maintenance Pour maintenir les performances du système, vous devez analyser votre serveur afin d identifier les goulets d étranglement potentiels. Une analyse efficace nécessite de bien comprendre les indicateurs clés qui vous indiqueront si une partie spécifique de votre batterie de serveurs nécessite une attention particulière et de savoir comment faire pour interpréter ces indicateurs. Si vous constatez que votre batterie de serveurs fonctionne en dehors des objectifs que vous avez définis, vous pouvez l ajuster en ajoutant ou en supprimant des ressources matérielles, en modifiant votre topologie ou en modifiant le mode de stockage des données. Pour obtenir la liste des paramètres que vous pouvez modifier pour analyser votre environnement lors des phases initiales, ce qui peut vous aider à déterminer si des modifications sont nécessaires, voir Surveillance et gestion de SharePoint Server Gardez à l esprit que l augmentation de vos capacités d analyse affecte la quantité d espace disque requis par votre base de données d utilisation. Une fois que l environnement est stable et que ce suivi détaillé n est plus nécessaire, vous souhaiterez peut-être rétablir les valeurs par défaut des paramètres ci-dessous. Pour plus d informations sur l analyse de l intégrité et sur le dépannage à l aide des outils d analyse d intégrité intégrés à l interface d Administration centrale de SharePoint Server, voir les articles suivants : Health Monitoring (SharePoint Server 2010) Résolution des problèmes et dépannage ( 66

67 Voir aussi Concepts Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Test de performances pour SharePoint Server 2010 Surveillance et gestion de SharePoint Server 2010 Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Autres ressources Health Monitoring (SharePoint Server 2010) 67

68 Test de performances pour SharePoint Server 2010 Cet article explique comment tester les performances de Microsoft SharePoint Server La phase de test et d optimisation est une partie essentielle de la gestion de la capacité. Vous devez tester les nouvelles architectures avant de les déployer vers l environnement de production et vous devez effectuer les tests d acceptation tout en adoptant les meilleures pratiques de surveillance suivantes afin que les architectures que vous concevez atteignent les objectifs de performances et de capacité. Cela permet d identifier et d optimiser les goulots d étranglement potentiels avant qu ils n affectent les utilisateurs dans un déploiement réel. Si vous effectuez une mise à niveau depuis un environnement Microsoft Office SharePoint Server 2007 et que vous envisagez d apporter des modifications architecturales, ou que vous estimez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server 2010, il est particulièrement important que vous effectuiez les tests afin de vous assurer que votre nouvel environnement SharePoint Server 2010 répond aux objectifs de performances et de capacité. Une fois que vous avez testé votre environnement, vous pouvez analyser les résultats des tests pour déterminer quelles modifications doivent être apportées afin d atteindre les objectifs de performances et de capacité définis dans la section Étape 1 : modèle de l article Planification de la capacité pour SharePoint Server Voici les sous-étapes qu il est recommandé de suivre pour l environnement de préproduction : Créez l environnement de test qui imite l architecture de départ conçue dans la section Étape 2 : conception. Remplissez le stockage avec le jeu de données ou une partie du jeu de données que vous avez identifié dans la section Étape 1 : modèle. Sollicitez le système avec une charge de synthèse qui représente la charge de travail que vous avez identifiée dans la section Étape 1 : modèle. Exécutez les tests, analysez les résultats et optimisez votre architecture. Déployez votre architecture optimisée dans votre centre de données et déployez un projet pilote avec un plus petit ensemble d utilisateurs. Analysez les résultats du pilote, identifiez les goulots d étranglement potentiels et optimisez l architecture. Renouvelez le test si nécessaire. Déployez vers l environnement de production. 68

69 Avant de lire cet article, vous devez lire l article Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Dans cet article : Créer un plan de test Créer l environnement de test Créer des tests et des outils Créer un plan de test Vérifiez que votre plan satisfait les points suivants : La configuration matérielle est conçue de manière à atteindre les objectifs de performance de production attendus. Mesurez toujours les performances des systèmes de test de manière à obtenir une estimation minimale. Si vous utilisez un code personnalisé ou un composant personnalisé, il est important de tester les performances de ces composants de manière isolée pour valider leurs performances et leur stabilité. Une fois qu ils sont stables, vous devez tester le système avec ces composants installés et comparer les performances à celles obtenues sur la batterie de serveurs sans ces composants. Les composants personnalisés sont souvent la cause principale des problèmes de performances et de fiabilité dans les systèmes de production. Vous devez connaître la finalité de vos tests. Définissez à l avance les objectifs des tests. S agit-il de valider les performances de certains nouveaux composants personnalisés qui ont été développés pour la batterie de serveurs? S agit-il de déterminer le temps nécessaire pour analyser et indexer un ensemble de contenus? S agit-il de déterminer combien de demandes par seconde votre batterie de serveurs peut prendre en charge? De nombreux objectifs différents peuvent être poursuivis pendant un test, et la première étape du développement d un plan de test efficace consiste à déterminer vos objectifs. Déterminez les paramètres que vous devez mesurer pour atteindre l objectif de vos tests. Si vos mesures doivent porter sur la capacité de débit de votre batterie de serveurs par exemple, vous devez mesurer le taux de demandes par seconde et la latence des pages. Si vos mesures portent sur les performances de recherche, vous devez mesurer le temps d analyse et les taux d indexation des documents. Le fait d établir avec précision l objectif de vos tests vous permet de définir clairement les indicateurs de performance clés que vous devez valider pour effectuer vos tests. 69

70 Créer l environnement de test Une fois que vous avez établi les objectifs de vos tests, défini vos mesures et déterminé les besoins en capacité de votre batterie de serveurs (à partir des étapes 1 et 2 de ce processus), l objectif suivant consiste à concevoir et à créer l environnement de test. L effort à fournir pour créer un environnement de test est souvent sous-estimé. Cet environnement doit dupliquer l environnement de production aussi fidèlement que possible. Les fonctions et fonctionnalités que vous devez prendre en compte lors de la conception de votre environnement de test comprennent notamment les suivantes : Authentification : déterminez si la batterie de serveurs utilise les services de domaine Active Directory (AD DS), l authentification par formulaire (et si tel est le cas avec quel annuaire), l authentification basée sur les revendications, etc. Indépendamment de l annuaire que vous utilisez, de combien d utilisateurs avez-vous besoin dans votre environnement de test et comment allez-vous les créer? De combien de groupes ou rôles aurez-vous besoin et comment allez-vous les créer et les remplir? Vous devez également vous assurer que vos services d authentification disposent de suffisamment de ressources pour ne pas devenir un goulot d étranglement pendant les tests. DNS : déterminez les espaces de noms dont vous aurez besoin pendant les tests. Identifiez les serveurs qui répondront à ces demandes et veillez à établir un plan prévoyant quelles adresses IP seront utilisées par les différents serveurs et quelles sont les entrées DNS que vous devrez créer. Équilibrage de charge : en supposant que vous utilisez plusieurs serveurs (ce qui est normalement le cas, à moins que la charge soit insuffisante pour justifier la réalisation d un test de charge), vous devrez recourir à une solution d équilibrage de charge. Il peut s agir d un périphérique d équilibrage de charge matériel, ou vous pouvez utiliser un équilibrage de charge logiciel tel que l équilibrage de charge réseau Windows. Déterminez ce que vous allez utiliser et notez toutes les informations de configuration dont vous aurez besoin pour que la solution choisie soit opérationnelle rapidement et efficacement. En outre, vous devez garder à l esprit que les agents de test de charge essaient de résoudre l adresse en une URL une fois toutes les 30 minutes. Cela signifie que vous ne devez pas utiliser un fichier d hôtes local ou un DNS cyclique pour l équilibrage de charge dans la mesure où les agents de test finiront probablement par solliciter le même serveur pour chaque demande, au lieu d effectuer un équilibrage entre tous les serveurs disponibles. Serveurs de test : lors de la planification de votre environnement de test, outre les serveurs de la batterie de serveurs SharePoint Server 2010, vous devez planifier les ordinateurs nécessaires à l exécution des tests. En règle générale, cela inclut 3 serveurs, voir plus si nécessaire. Si vous utilisez Visual Studio Team System (Team Test Load Agent) pour effectuer les tests, un ordinateur servira de contrôleur de test de charge. Deux ou plusieurs ordinateurs servent généralement d agents de test de charge. Les agents sont les ordinateurs qui récupèrent du contrôleur de test les instructions relatives aux éléments à tester et qui envoient les demandes à la batterie de serveurs SharePoint Server Les résultats des tests eux-mêmes sont stockés sur un ordinateur SQL Server. Vous ne devez pas recourir à l ordinateur SQL Server utilisé pour la batterie de serveurs SharePoint Server 2010, car l écriture des données 70

71 de test fausserait les ressources SQL Server disponibles pour la batterie de serveurs SharePoint Server En outre, vous devez surveiller vos serveurs de test lorsque vous exécutez vos tests, de la même façon que vous surveilleriez les serveurs de la batterie de serveurs SharePoint Server 2010, ou des contrôleurs de domaine, etc., pour vous assurer que les résultats des tests sont représentatifs de la batterie de serveurs que vous êtes en train de configurer. Parfois, le contrôleur ou les agents de test de charge peuvent eux-mêmes devenir le goulot d étranglement. Si cela se produit, le débit révélé dans votre test n est généralement pas le débit maximal que la batterie de serveurs peut prendre en charge. SQL Server : dans votre environnement de test, suivez les conseils indiqués dans les sections «Configurer SQL Server» et «Valider et surveiller les performances de stockage et de SQL Server» de l article Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Validation du jeu de données : lorsque vous déterminez le contenu à tester, n oubliez pas que, dans le meilleur des cas, vous allez utiliser des données issues d un système de production existant. Par exemple, vous pouvez sauvegarder vos bases de données de contenu à partir d une batterie de serveurs de production, les restaurer dans votre environnement de test, puis attacher les bases de données pour insérer le contenu dans la batterie de serveurs. Chaque fois que vous exécutez des tests par rapport à des données fictives ou à un échantillon de données, vous courez le risque d obtenir des résultats faussés en raison des différences dans votre corpus de contenu. Si vous êtes amené à créer un échantillon de données, vous devez prendre en compte certains éléments pendant la génération de ce contenu : Toutes les pages doivent être publiées ; rien ne doit être extrait. La navigation doit être réaliste ; ne générez pas plus de contenu que vous seriez susceptible d utiliser dans un environnement de production. Vous devez avoir une idée des personnalisations que le site de production utilisera. Par exemple, dans la mesure du possible, les pages maîtres, feuilles de style, JavaScript, etc. doivent tous être implémentés dans l environnement de test de la même manière que dans l environnement de production. Déterminez le nombre de niveaux d autorisation et/ou de groupes SharePoint dont vous aurez besoin et comment vous allez associer des utilisateurs à ceux-ci. Déterminez si vous devrez effectuer des importations de profils et évaluez la durée de ces opérations. Déterminez si vous aurez besoin d audiences et comment vous allez les créer et les remplir. Déterminez si vous avez besoin de sources de contenu de recherche supplémentaires et ce dont vous aurez besoin pour les créer. Si vous n avez pas besoin de les créer, déterminez si vous disposez d un accès réseau vous permettant de les analyser. 71

72 Déterminer si vous disposez de suffisamment de données d échantillonnage (documents, listes, éléments de liste, etc.). Dans le cas contraire, planifiez la création de ce contenu. Veillez à utiliser un contenu unique permettant de tester la recherche correctement. Une erreur courante consiste à télécharger le même document, peut-être des centaines ou même des milliers de fois, vers différentes bibliothèques de documents avec des noms différents. Cela peut affecter les performances de recherche dans la mesure où le processeur de requêtes consacre un temps conséquent à la détection des doublons, opération qu il n effectuerait pas dans un environnement de production comportant du contenu réel. Créer des tests et des outils Une fois que l environnement de test est fonctionnel, il est temps de créer et d affiner les tests qui permettront de mesurer la capacité des performances de la batterie de serveurs. Cette section fera parfois spécifiquement référence à Visual Studio Team System (Team Test Load Agent), mais la plupart des concepts sont applicables indépendamment de l outil de test de charge que vous utilisez. Pour plus d informations sur Visual Studio Team System, voir la rubrique Visual Studio Team System sur le site MSDN ( Vous pouvez également utiliser le kit SharePoint LTK (Load Test Kit) en association avec VSTS pour les tests de charge des batteries de serveurs SharePoint Le kit de test de charge génère un test de charge Visual Studio Team System 2008 basé sur les journaux IIS Microsoft Office SharePoint Server 2007 et Windows SharePoint Services 3.0. Le test de charge VSTS peut être utilisé pour générer une charge de synthèse par rapport à SharePoint Foundation 2010 ou SharePoint Server 2010 dans le cadre d un exercice de planification de la capacité ou d un test de contrainte préalable à la mise à niveau. Le kit de test de charge est inclus dans Microsoft SharePoint 2010 Administration Toolkit v1.0, disponible à partir du Centre de téléchargement Microsoft (éventuellement en anglais) ( 81c3-c9c3d84c456e&displaylang=fr-fr). Un critère clé pour la réussite des tests est la possibilité de simuler efficacement une charge de travail réaliste en générant des demandes sur une plage étendue des données de site de test, à l image des utilisateurs qui accèdent à une large gamme de contenu d une batterie de serveurs de production SharePoint Server Pour ce faire, vous devrez généralement construire vos tests de façon à ce qu ils soient pilotés par les données. Au lieu de créer des centaines de tests individuels codés en dur pour accéder à une page spécifique, vous devez utiliser seulement quelques tests qui utilisent des sources de données contenant les URL de ces éléments pour accéder dynamiquement à ce jeu de pages. Dans Visual Studio Team System (Team Test Load Agent), une source de données peut se présenter dans plusieurs formats, mais un format de fichier CSV est souvent plus facile à gérer et à transporter entre les environnements de développement et de test. N oubliez pas 72

73 que la création de fichiers CSV avec ce contenu peut nécessiter la création d outils personnalisés pour énumérer l environnement basé sur SharePoint Server 2010 et enregistrer les différentes URL en cours d utilisation. Vous devrez peut-être utiliser des outils pour des tâches telles que les suivantes : La création d utilisateurs et de groupes dans Active Directory ou un autre magasin d authentifications si vous utilisez l authentification par formulaire. L énumération d adresses URL de sites, de listes, de bibliothèques, d éléments de liste, de documents, etc. et leur insertion dans des fichiers CSV pour les tests de charge. Le téléchargement d exemples de documents vers un ensemble de bibliothèques de documents et de sites. La création de collections de sites, de sites Web, de listes, de bibliothèques, de dossiers et d éléments de liste. La création de sites Mon site. La création de fichiers CSV contenant les noms d utilisateur et les mots de passe des utilisateurs des tests ; ce sont les comptes d utilisateurs sous lesquels les tests de charge seront exécutés. Il doit y avoir plusieurs fichiers de manière à ce que, par exemple, certains contiennent uniquement les utilisateurs administrateurs, certains contiennent d autres utilisateurs avec des privilèges élevés (tels qu auteur/collaborateur, gestionnaire de hiérarchies, etc.) et d autres ne concernent que les lecteurs, etc. La création d une liste des exemples de mots clés et d expressions de recherche. Le remplissage des groupes et des niveaux d autorisation SharePoint avec des utilisateurs et des groupes Active Directory (ou des rôles si vous utilisez l authentification par formulaire). Lors de la création des tests Web, vous devez en outre observer et mettre en œuvre les meilleures pratiques suivantes : Enregistrez des tests Web simples comme point de départ. Ces tests comporteront des valeurs codées en dur pour les paramètres tels que l URL, les ID, etc. Remplacez ces valeurs codées en dur par des liens provenant de vos fichiers CSV. La liaison de données avec ces valeurs dans Visual Studio Team System (Team Test Load Agent) est extrêmement simple. Ayez toujours des règles de validation pour votre test. Par exemple, lors de la demande d une page, si une erreur se produit, vous obtenez souvent la page error.aspx en réponse. Du point de vue d un test Web, cela est assimilable à n importe quelle réponse positive, étant donné que vous obtenez le code d état HTTP 200 (réussite) dans les résultats des tests de charge. Bien évidemment, une erreur est quand même survenue, qui doit faire l objet d un suivi spécifique. La création d une ou de plusieurs règles de validation permet de capturer la situation dans laquelle du texte spécifique est envoyé en réponse, afin que la validation échoue et que la demande soit marquée comme ayant échoué. Par exemple, dans Visual Studio Team System (Team Test Load Agent), une règle de validation simple peut être une validation ResponseUrl : elle enregistre une erreur si la page affichée après la redirection n est pas la 73

74 même page de réponse que celle enregistrée dans le test. Vous pouvez également ajouter une règle FindText qui enregistre une erreur si elle trouve l expression «accès refusé», par exemple, dans la réponse. Utilisez plusieurs utilisateurs dans des rôles différents pour les tests. Certains comportements, tels que la mise en cache de sortie, fonctionnent différemment selon les droits de l utilisateur actuel. Par exemple, un administrateur de collection de sites ou un utilisateur authentifié disposant des droits de création ou d approbation n obtiendront pas de résultats mis en cache, car il est préférable qu ils disposent systématiquement de la version de contenu la plus récente. Les utilisateurs anonymes, cependant, obtiendront le contenu mis en cache. Vous devez vous assurer que les utilisateurs des tests appartiennent à une combinaison de ces rôles qui correspond approximativement à la combinaison des utilisateurs dans l environnement de production. Par exemple, il est probable que l environnement de production ne compte que deux ou trois administrateurs de collection de sites, si bien que vous ne devez pas créer de tests où 10 % des demandes de page sont effectuées par des comptes d utilisateurs qui sont des administrateurs de collection de sites pour le contenu des tests. Dans Visual Studio Team System (Team Test Load Agent), l analyse des demandes dépendantes est un attribut qui détermine si l agent de test doit tenter de récupérer uniquement la page ou la page et toutes les demandes associées qui font partie de la page, telles que les images, les feuilles de style, les scripts, etc. Lors du test de la charge, nous ignorons généralement ces éléments pour plusieurs raisons : Lorsqu un utilisateur accède à un site pour la première fois, ces éléments sont souvent mis en cache par le navigateur local. Ces éléments ne proviennent généralement pas de SQL Server dans un environnement SharePoint Server Lorsque la mise en cache BLOB est activée, ils sont en fait fournis par les serveurs Web et ne génèrent donc pas de charge pour SQL Server. Si vous avez régulièrement un pourcentage élevé d utilisateurs accédant à votre site pour la première fois, que vous avez désactivé la mise en cache du navigateur ou que pour une raison quelconque vous n envisagez pas d utiliser le cache BLOB, il peut être judicieux d activer l analyse des demandes dépendantes dans vos tests. Cependant, ceci est vraiment l exception, et non la règle de base, pour la plupart des implémentations. N oubliez pas que si vous activez cette fonctionnalité, cela peut entraîner une augmentation significative des nombres de demandes par seconde signalés par le contrôleur de test. Ces demandes sont prises en charge tellement rapidement que vous risquez de surestimer à tort la capacité réelle disponible dans la batterie de serveurs. En outre, n oubliez pas de modéliser l activité des applications clientes. Celles-ci, telles que Microsoft Word, PowerPoint, Excel et Outlook, génèrent également des demandes destinées aux batteries de serveurs SharePoint Server Elles ajoutent une charge à l environnement en envoyant les demandes serveur telles que l extraction de flux RSS, l acquisition d informations sociales, la demande de détails sur la structure de site et de liste, la synchronisation de données, etc. Ces types de demandes doivent être inclus et modélisés si ces clients figurent dans votre implémentation. Dans la plupart des cas, un test Web ne doit contenir qu une seule demande. Il est plus facile d optimiser l exploitation du test et de résoudre les problèmes liés aux différentes demandes si le test ne contient qu une seule demande. Les tests Web devront 74

75 généralement contenir plusieurs demandes si l opération qu ils simulent est composée de plusieurs demandes. Par exemple, pour tester cet ensemble d actions, vous aurez besoin d un test comportant plusieurs étapes : extraction d un document, modification, archivage et publication de celui-ci. Cela nécessite également la conservation d un état entre les opérations ; par exemple, le même compte d utilisateur doit être utilisé pour l extraction, la réalisation des modifications, puis l archivage. Ces opérations en plusieurs étapes nécessitant la conservation d un état entre chaque étape sont mieux gérées par plusieurs demandes dans un test Web unique. Testez chaque test Web individuellement. Assurez-vous que chaque test peut être accompli correctement avant de l exécuter dans un test de charge de plus grande ampleur. Vérifiez que tous les noms des applications Web sont résolus et que les comptes d utilisateur utilisés dans le test disposent de droits suffisants pour exécuter le test. Les tests Web comprennent les demandes de pages individuelles, le téléchargement de documents, l affichage d éléments de liste, etc. Tous ces éléments sont réunis dans les tests de charge. Un test de charge est l endroit où vous connectez tous les différents tests Web qui vont être exécutés. Chaque test Web peut se voir attribuer un pourcentage de temps d exécution ; par exemple, si vous constatez que 10 % des demandes dans une batterie de serveurs de production sont des requêtes de recherche, dans le test de charge, vous pouvez configurer un test Web de requête de telle sorte qu il s exécute pendant 10 % du temps. Dans Visual Studio Team System (Team Test Load Agent), les tests de charge concernent également la configuration d éléments tels que la combinaison de navigateurs, la combinaison de réseaux, les modèles de charge et les paramètres d exécution. Il existe certaines meilleures pratiques supplémentaires qui doivent être observées et mises en œuvre pour les tests de charge : Dans vos tests, utilisez un ratio de lecture/écriture raisonnable. Un nombre excessif d écritures dans un test peut avoir un impact significatif sur le débit global du test. Même sur des batteries de serveurs de collaboration, les ratios de lecture/écriture ont tendance à être beaucoup plus favorables au nombre de lectures. Pour plus d informations, voir la page Études de cas techniques sur les performances et la capacité ( Étudiez l impact de toutes les autres opérations gourmandes en ressources et déterminez si elles doivent se produire pendant le test de charge. Par exemple, les opérations telles que la sauvegarde et la restauration ne sont généralement pas effectuées pendant un test de charge. Il est naturel qu une analyse de recherche complète n ait pas lieu pendant un test de charge, contrairement à une analyse incrémentielle. Vous devez envisager la façon dont ces tâches seront planifiées dans l environnement de production : serontelles exécutées aux heures de charge maximale? Si ce n est pas le cas, elles doivent probablement être exclues pendant le test de charge, lorsque vous essayez de déterminer la charge d état stable maximale que vous pouvez prendre en charge pour le trafic de pointe. N utilisez pas le temps de réflexion. Le temps de réflexion est une fonctionnalité de Visual Studio Team System (Team Test Load Agent) qui vous permet de simuler la durée pendant laquelle les utilisateurs marquent une pause entre les clics effectués sur une page. Par exemple, un utilisateur peut charger une page, passer trois minutes à la lire, puis cliquer sur un lien sur la page pour accéder à un autre site. Il est presque impossible de modéliser ce comportement dans un environnement de test et une telle 75

76 modélisation n ajoute pratiquement aucune valeur aux résultats des tests. Il est difficile d effectuer une modélisation, car la plupart des organisations ne sont pas en mesure de surveiller différents utilisateurs et le temps qui s écoule entre chaque clic sur les différents types de sites SharePoint (tels que les sites de publication, de recherche ou de collaboration). En outre, cela n apporte pas de valeur dans la mesure où même si un utilisateur peut faire une pause entre les demandes de pages, les serveurs basés sur SharePoint Server 2010 ne marquent pas de pause. Ces derniers reçoivent simplement un flux continu de demandes qui peut présenter des pics et des creux au fil du temps, mais ils ne demeurent pas inactifs lorsque chaque utilisateur marque une pause entre les clics sur les liens d une page. Comprenez la différence entre utilisateurs et demandes. Visual Studio Team System (Team Test Load Agent) possède un modèle de charge qui vous invite à entrer le nombre d utilisateurs à simuler. Cela n a rien à voir avec les utilisateurs de l application ; il ne s agit en fait que du nombre de threads à utiliser pour générer des demandes sur les agents de test de charge. Une erreur courante consiste à penser que si le déploiement comprend utilisateurs, par exemple, c est ce nombre qui doit être utilisé dans Visual Studio Team System (Team Test Load Agent), ce qui n est pas le cas. C est l une des nombreuses raisons pour lesquelles lors de l estimation des besoins liés à la planification de la capacité, il est nécessaire d évaluer les contraintes d utilisation en fonction du nombre de demandes par seconde et non du nombre d utilisateurs. Dans un test de charge Visual Studio Team System (Team Test Load Agent), vous constaterez que vous pouvez souvent générer des centaines de demandes par seconde à l aide de seulement 50 à 75 «utilisateurs» de test de charge. Utilisez un modèle de charge constant pour les résultats des tests les plus fiables et reproductibles. Dans Visual Studio Team System (Team Test Load Agent), vous avez la possibilité de baser la charge sur un nombre constant d utilisateurs (threads, comme expliqué dans le point précédent), sur un modèle de charge d utilisateurs progressif ou sur un test d utilisation basé sur des objectifs. Un modèle de charge progressif consiste à démarrer avec un nombre réduit d utilisateurs, puis à ajouter progressivement des utilisateurs à quelques minutes d intervalle. Un test d utilisation basé sur des objectifs consiste à établir un seuil pour un certain compteur de diagnostic, tel que l utilisation du processeur, et à tester le pilotage de la charge en faisant en sorte que ce compteur demeure entre un seuil minimal et un seuil maximal définis par vos soins. Toutefois, si vous essayez simplement de déterminer le débit maximal que la batterie de serveurs SharePoint Server 2010 peut accepter au cours des pics de charge, il est plus efficace et précis de choisir simplement un modèle de charge constante. Cela vous permet d identifier plus facilement le volume de charge que le système peut accepter avant de commencer à dépasser régulièrement les seuils qui doivent être maintenus dans une batterie de serveurs en bon état. Chaque fois que vous exécutez un test de charge, souvenez-vous qu il modifie les données de la base de données. Qu il s agisse du téléchargement de documents, de la modification d éléments de liste ou simplement de l enregistrement d activités dans la base de données d utilisation, des données sont systématiquement écrites dans SQL Server. Pour obtenir un jeu de résultats des tests cohérent et valide à partir de chaque test de charge, vous devez disposer d une sauvegarde avant d exécuter le premier test de charge. À la fin de chaque test de charge, il est nécessaire d utiliser la sauvegarde pour restaurer le contenu tel qu il existait avant le démarrage du test. 76

77 Voir aussi Concepts Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Planification de la capacité pour SharePoint Server 2010 Surveillance et gestion de SharePoint Server 2010 Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Autres ressources Health Monitoring (SharePoint Server 2010) 77

78 Surveillance et gestion de SharePoint Server 2010 Cet article fournit des informations sur la surveillance et sur les compteurs de performance liés aux batteries de serveurs Microsoft SharePoint Server Pour gérer les performances système de SharePoint Server 2010, vous devez surveiller votre serveur afin d identifier les goulots d étranglement potentiels. Avant de passer à la surveillance proprement dite, vous devez comprendre les indicateurs clés qui vous révéleront si une partie de votre batterie de serveurs nécessite une attention particulière et savoir comment interpréter ces indicateurs. Si vous constatez que le fonctionnement de votre batterie de serveurs s écarte des cibles que vous avez définies, vous pouvez ajuster votre batterie de serveurs en ajoutant ou en supprimant des ressources matérielles, en modifiant votre topologie ou en modifiant le mode de stockage des données. Les informations de cette section visent à aider les administrateurs à configurer manuellement les compteurs de performance et d autres paramètres. Pour plus d informations sur la surveillance de l intégrité et sur la résolution des problèmes à l aide des outils de surveillance de l intégrité intégrés à l interface de l Administration centrale de SharePoint, lisez les articles suivants : Health Monitoring (SharePoint Server 2010) Solving Problems and Troubleshooting (SharePoint Server 2010) Avant de lire cet article, vous devez lire l article Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Dans cet article : Configuration de la surveillance Suppression des goulots d étranglement Configuration de la surveillance La liste ci-après répertorie les paramètres que vous pouvez modifier pour surveiller votre environnement à ses débuts, ce qui vous permettra de déterminer si des modifications sont nécessaires. Gardez à l esprit que l augmentation de vos capacités de surveillance aura une incidence sur la quantité d espace disque dont aura besoin votre base de données d utilisation. Une fois que l environnement est stable et que cette surveillance détaillée n est plus nécessaire, vous pouvez rétablir les valeurs par défaut des paramètres ci-après. 78

79 Paramètre Valeur Remarques Protection de flux du journal des événements Désactivé La valeur par défaut est Activé. Vous pouvez le désactiver afin de collecter autant d informations de surveillance que possible. Pour les opérations normales, il doit être activé. Planification des travaux du minuteur Importation des données d utilisation de Microsoft SharePoint Foundation 5 minutes La valeur par défaut est 30 minutes. La diminution de ce paramètre se traduit par une augmentation de la fréquence d importation des données dans la base de données d utilisation et est particulièrement utile lors de la résolution des problèmes. Pour les opérations normales, la valeur doit être de 30 minutes. Fournisseurs de diagnostic Activer tous les fournisseurs de diagnostic Activé La valeur par défaut est Désactivé sauf pour le fournisseur «Analyse du fonctionnement de la recherche - Suivi des 79

80 Paramètre Valeur Remarques Définir les intervalles de planification «travaildiagnostics-compteur-performance-wfe-fournisseur» et «travail-diagnostics-compteur-performance-sqlfournisseur» Divers événements». Ces fournisseurs collectent des données d intégrité pour différentes fonctionnalités et différents composants. Pour les opérations normales, vous pouvez rétablir la valeur par défaut. 1 minute La valeur par défaut est 5 minutes. La diminution de ce paramètre peut se traduire par une augmentation de la fréquence d interrogation des données et est particulièrement utile lors de la résolution des problèmes. Pour les opérations normales, la valeur doit être de 5 minutes. Activer le suivi de pile pour les demandes de contenu Activé La valeur par défaut est Désactivé. L activation de ce paramètre permet de diagnostiquer les échecs de demandes de contenu en utilisant la trace de pile 80

81 Paramètre Valeur Remarques de processus. Pour les opérations normales, ce paramètre doit être désactivé. Activer le tableau de bord des développeurs Activé La valeur par défaut est Désactivé. L activation de ce paramètre permet de diagnostiquer les pages lentes ou les autres problèmes en utilisant le tableau de bord des développeurs. Pour les opérations normales et une fois que la résolution des problèmes n est plus nécessaire, ce paramètre doit être désactivé. Collecte des données d utilisation Utilisation de l importation de contenu Utilisation de l exportation de contenu Demandes de page Utilisation de la fonctionnalité Utilisation de la requête de recherche Utilisation de l inventaire des sites Travaux du minuteur Utilisation de l évaluation Activé L activation de la journalisation de cet ensemble de compteurs vous permet de collecter davantage de données d utilisation dans l environnement et de mieux comprendre les modèles de trafic au sein de l environnement. 81

82 Compteurs de performance Si vous utilisez la base de données d utilisation, vous pouvez ajouter à celle-ci les compteurs de performance qui facilitent la surveillance et l évaluation des performances de votre batterie de serveurs, de manière à ce qu ils soient automatiquement journalisés selon un intervalle spécifique (30 minutes par défaut). Ainsi, vous pouvez interroger la base de données d utilisation pour récupérer ces compteurs et générer un graphique des résultats dans le temps. Voici un exemple d utilisation de l applet de commande PowerShell Add- SPDiagnosticsPerformanceCounter pour ajouter le compteur % temps processeur à la base de données d utilisation. Il n est nécessaire d exécuter cette commande que sur un seul serveur Web : Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" -WebFrontEnd Code de copie Pour tout système serveur, vous devez surveiller une série de compteurs de performance génériques. Le tableau suivant décrit ces compteurs de performance. Compteur de performance Processeur Description Vous devez surveiller les performances du processeur afin de vous assurer que la totalité de l utilisation du processeur ne demeure pas constamment élevée (plus de 80 %), car cela indique que le système ne pourrait pas prendre en charge une augmentation soudaine des activités. Cette surveillance a également pour objet d éviter un effet domino si la défaillance d un composant entraîne un dysfonctionnement des autres composants. Par exemple, si vous disposez de trois serveurs Web, vous devez vous assurer que l utilisation moyenne de l UC dans tous les serveurs est inférieure à 60 % de telle sorte qu en cas de défaillance de l un d eux, il soit toujours possible pour les deux autres de traiter la charge supplémentaire. 82

83 Compteur de performance Interface réseau Disques et cache Mémoire et fichier d échange Description Surveillez le taux auquel les données sont envoyées et reçues via la carte d interface réseau. Ce taux doit demeurer inférieur à 50 % de la capacité du réseau. Vous devez surveiller régulièrement une série d options de disque logique. L espace disque disponible est essentiel dans toute étude de capacité, mais vous devez également examiner la durée pendant laquelle le disque est inactif. Suivant les types d applications ou de services que vous exécutez sur vos serveurs, vous pouvez examiner les heures de lecture et d écriture sur disque. Une mise en file d attente prolongée des opérations d écriture ou de lecture aura une incidence sur les performances. Le cache a un impact majeur sur les opérations de lecture et d écriture. Vous devez déterminer si les échecs du cache sont en augmentation. Surveillez la quantité de mémoire physique pouvant être allouée. Une insuffisance de mémoire aboutit à une utilisation excessive du fichier d échange et à une augmentation du nombre de défauts de page par seconde. Compteurs système Le tableau suivant fournit des informations sur les objets et compteurs système que vous pouvez ajouter au jeu de compteurs surveillés dans la base de données d utilisation en utilisant la commande SPDiagnosticPerformanceCounter sur un serveur Web. Objets et compteurs Processeur 83 Description % temps processeur Ce paramètre indique l utilisation du processeur pendant une période de temps. Si cette valeur demeure constamment excessive,

84 Objets et compteurs Disque Longueur moyenne de la file d attente du disque Longueur moyenne de file d attente lecture disque Longueur moyenne de file d attente écriture disque Lectures disque/s Ecritures disque/s Description cela peut porter préjudice aux performances. Pensez à établir un décompte total dans les systèmes multiprocesseurs. Vous pouvez également mesurer l utilisation sur chaque processeur, afin que les performances soient équilibrées entre les cœurs. Ce paramètre indique le nombre moyen de demandes de lecture et d écriture mises en file d attente pour le disque sélectionné pendant l intervalle d échantillonnage. Une file d attente de disque plus longue n est pas nécessairement un problème, à condition que les lectures/écritures sur disque n en pâtissent pas et que le système fonctionne dans un état stable sans que la mise en file d attente n augmente indéfiniment. Nombre moyen de demandes de lecture mises en file d attente. Nombre moyen de demandes d écriture mises en file d attente. Nombre de lectures sur disque par seconde. Nombre d écritures sur disque par seconde. Mémoire Mégaoctets disponibles Défauts de cache/s Ce paramètre indique la quantité de mémoire physique pouvant être allouée. Une insuffisance de mémoire aboutit à une utilisation excessive du fichier d échange et à une augmentation du nombre de défauts de page par seconde. Ce compteur indique le taux auquel les défauts se produisent lorsqu une page est recherchée dans le cache du système de fichiers et qu elle demeure introuvable. Il peut s agir d un défaut logiciel, si la page se trouve dans la mémoire, ou d un défaut 84

85 Objets et compteurs Pages/s Description matériel, si la page se trouve sur le disque. L utilisation effective du cache pour les opérations de lecture et d écriture peut avoir un impact significatif sur les performances des serveurs. Vous devez déterminer si les défauts de cache sont en augmentation, ce qu indique une réduction de la valeur du compteur Lectures rapides async/s ou Lectures en avance/s. Ce compteur indique le taux auquel les pages sont lues à partir du disque et écrites sur celui-ci pour faciliter la résolution des défauts de page matériels. L augmentation de ce taux indique l existence de problèmes de performances à l échelle du système. Fichier d échange Pourcentage d utilisation et pourcentage de pic d utilisation Le fichier d échange du serveur contient des adresses mémoire «virtuelles» du disque. Les défauts de page se produisent lorsqu un processus doit s arrêter et attendre que des ressources «virtuelles» requises soient récupérées en mémoire à partir du disque. Ces erreurs sont d autant plus fréquentes que la mémoire physique est inappropriée. Carte réseau Octets totaux/s Il s agit du taux auquel les données sont envoyées et reçues via la carte d interface réseau. Vous pouvez être amené à approfondir l analyse afin de déterminer si ce taux est supérieur à % de la capacité du réseau. Pour affiner votre recherche, surveillez les compteurs Octets reçus/s et Octets envoyés/s. Processus Jeu de travail Ce compteur indique la taille actuelle (en octets) du jeu de travail pour un processus donné. Cette mémoire est réservée au 85

86 Objets et compteurs Description processus, même si elle n est pas en cours d utilisation. % temps processeur Ce compteur indique le pourcentage de temps processeur utilisé par un processus donné. Nombre de threads (_Total) ASP.NET Nb total de demandes Nb de demandes en attente Durée d attente de la demande Demandes rejetées Nb de demandes en cours d exécution (_Total) Nb de requêtes/s (_Total) Nombre actuel de threads. Nombre total de demandes depuis le démarrage du service. Microsoft SharePoint Foundation 2010 fournit les blocs de construction des pages HTML qui sont restituées dans le navigateur de l utilisateur via HTTP. Ce compteur indique le nombre de demandes en attente de traitement. Durée, en millisecondes, pendant laquelle la demande la plus récente est demeurée dans la file d attente avant d être traitée. Lorsque le nombre d événements d attente augmente, la restitution des pages est moins performante du point de vue de l utilisateur. Nombre total de demandes non exécutées en raison de ressources serveur insuffisantes. Ce compteur représente le nombre de demandes qui retournent un code d état HTTP 503, indiquant que le serveur est encombré. Nombre de demandes en cours d exécution. Nombre de demandes exécutées par seconde. Cette valeur représente le débit actuel de l application. Lorsque la charge est constante, ce nombre doit demeurer dans une certaine plage, à l exclusion des autres tâches de serveur (telles que le nettoyage de la mémoire, le thread de nettoyage du cache, les outils serveur externes, etc.). 86

87 Objets et compteurs Mémoire CLR.NET Nombre de collections de la génération 0 Nombre de collections de la génération 1 Description Affiche le nombre de fois que les objets de la génération 0 (c est-àdire les objets les plus jeunes et les plus récemment alloués) ont été récupérés par le garbage collector depuis le démarrage de l application. Ce nombre est utile en tant que rapport nombre de collections de la génération 0 : nombre de collections de la génération 1 : nombre de collections de la génération 2 pour vérifier que le nombre de collections de la génération 2 ne dépasse pas exagérément le nombre de collections de la génération 0, idéalement d un facteur de 2. Affiche le nombre de fois que les objets de la génération 1 ont été récupérés par le garbage collector depuis le démarrage de l application. Nombre de collections de la génération 2 Affiche le nombre de fois que les objets de la génération 2 ont été récupérés par le garbage collector depuis le démarrage de l application. Le compteur est incrémenté à la fin d un nettoyage de mémoire de la génération 2 (également appelé nettoyage de mémoire complet). % temps dans le GC Affiche le pourcentage de temps écoulé qui a été consacré à la réalisation d un nettoyage de mémoire depuis le dernier cycle de nettoyage de mémoire. En règle générale, ce compteur indique le travail qu a réalisé le garbage collector pour collecter et compacter la mémoire pour le compte de l application. Ce compteur n est mis à jour qu à la fin de chaque nettoyage de mémoire. Ce compteur n est pas une moyenne ; sa valeur reflète la dernière valeur observée. Il doit être inférieur à 5 % pendant une opération normale. 87

88 Compteurs SQL Server Le tableau suivant fournit des informations sur les objets et compteurs SQL Server. Objets et compteurs Statistiques générales Connexions utilisateur Bases de données Transactions/s Description Cet objet fournit les compteurs permettant d analyser l activité générale au niveau du serveur, notamment le nombre de connexions actuelles et le nombre d utilisateurs se connectant et se déconnectant par seconde d ordinateurs exécutant une instance de SQL Server. Ce compteur indique le volume de connexions utilisateur sur votre instance de SQL Server. Si vous constatez que ce nombre a augmenté de 500 % par rapport à votre ligne de base, une baisse des performances pourrait se faire ressentir. Cet objet fournit des compteurs pour analyser les opérations de copie en bloc, le débit des sauvegardes et des restaurations, ainsi que l activité des journaux des transactions. Surveillez les transactions et le journal des transactions pour déterminer l intensité de l activité de l utilisateur dans la base de données et le taux de remplissage du journal des transactions. Le volume d activité de l utilisateur peut déterminer les performances de la base de données et affecter la taille du journal, le verrouillage et la réplication. La surveillance de l activité du journal de bas niveau afin de mesurer l activité de l utilisateur et l exploitation des ressources peut permettre d identifier les goulots d étranglement des performances. Ce compteur indique le volume de transactions effectuées par seconde sur une base de données spécifique ou sur la totalité de l instance de SQL Server. Ce nombre est utile dans le cadre de la création d une ligne de base et de la résolution des problèmes. 88

89 Objets et compteurs Verrous Nombre d interblocages/s Temps d attente moyen (ms) Temps d attente des verrous (ms) Attentes de verrous/s Verrous internes Temps d attente moyen d un verrou interne (ms) Attentes de verrous internes/s Statistiques SQL Description Cet objet fournit des informations sur les verrous SQL Server sur des types de ressources individuels. Ce compteur affiche le nombre d interblocages sur le serveur SQL Server par seconde. Ce nombre doit normalement être égal à 0. Ce compteur affiche le temps d attente moyen pour chaque demande de verrouillage qui a provoqué une attente. Ce compteur affiche le temps d attente total des verrous au cours de la dernière seconde. Ce compteur affiche le nombre de verrous par seconde ne pouvant pas être satisfaits immédiatement et devant attendre des ressources. Cet objet fournit les compteurs permettant de surveiller les verrous de ressources SQL Server internes appelés verrous. L analyse des verrous pour déterminer l activité des utilisateurs et l utilisation des ressources peut vous aider à identifier les goulots d étranglement de performance. Ce compteur affiche le temps d attente moyen d un verrou pour les demandes en attente. Ce compteur affiche le nombre de demandes de verrous par seconde ne pouvant pas être satisfaites immédiatement. Cet objet fournit les compteurs pour l analyse de la compilation et du type de demandes envoyées à une instance de SQL Server. L analyse du nombre de compilations et recompilations des requêtes ainsi que le nombre de lots reçus par une instance de SQL Server 89

90 Objets et compteurs Compilations SQL/s Recompilations SQL/s Plan Cache Taux d accès au cache Gestionnaire de tampons Taux d accès au cache des tampons Description vous donnent une indication de la vitesse à laquelle SQL Server traite les requêtes utilisateur et de l efficacité avec laquelle l optimiseur de requêtes traite les requêtes. Ce compteur indique le nombre de saisies du chemin d accès du code de compilation par seconde. Ce compteur indique le nombre de recompilations des instructions déclenchées par seconde. Cet objet fournit des compteurs qui permettent de surveiller l utilisation de la mémoire par SQL Server pour stocker des objets tels que des procédures stockées, des instructions Transact-SQL ad hoc et préparées, ainsi que des déclencheurs. Ce compteur indique le rapport entre les accès au cache et les recherches de plans. Cet objet fournit des compteurs permettant de surveiller l utilisation de la mémoire par SQL Server pour stocker des pages de données, des structures de données internes et le cache de procédures, ainsi que des compteurs permettant de surveiller les E/S physiques lorsque SQL Server lit et écrit des pages de bases de données. Ce compteur affiche le pourcentage de pages trouvées dans le cache des tampons sans avoir eu à lire sur le disque. Le ratio correspond au nombre total d accès au cache divisé par le nombre total de recherches depuis le démarrage d une instance de SQL Server. 90

91 Suppression des goulots d étranglement Les goulots d étranglement du système représentent un point de conflit au niveau duquel il n y a pas suffisamment de ressources pour traiter les demandes de transaction utilisateur. Ces goulots peuvent être liés à la configuration matérielle, à l environnement d exploitation ou aux applications. Souvent, la raison du goulot d étranglement est liée à l inefficacité d un code personnalisé ou de solutions tierces, et un examen de ces derniers peut s avérer plus efficace que l ajout de matériel. Une autre cause courante des goulots d étranglement est une mauvaise configuration de la batterie de serveurs ou une implémentation de solution inefficace qui structure les données de telle sorte que la configuration obtenue requiert plus de ressources que nécessaire. Il est primordial qu un administrateur système gère les goulots d étranglement en surveillant les performances en permanence. Lorsque vous identifiez un problème de performances, vous devez évaluer la meilleure solution pour supprimer le goulot d étranglement. Les compteurs de performance et autres applications de surveillance des performances, telles que System Center Operations Manager (SCOM), sont les outils indispensables au suivi et à l analyse des problèmes, et par voie de conséquence au développement optimal d une solution. Résolution des goulots d étranglement physiques Les goulots d étranglement physiques sont liés à des conflits qui touchent le processeur, le disque, la mémoire et le réseau : le nombre de demandes est trop élevé par rapport aux ressources physiques. Les objets et compteurs décrits dans la rubrique Surveillance des performances indiquent où le problème de performances se situe, par exemple, au niveau du processeur matériel ou d ASP.NET. Pour résoudre les goulots d étranglement, vous devez identifier le problème de performances, puis apporter les modifications permettant de l atténuer. Les problèmes se produisent rarement de façon soudaine ; en règle générale, il existe une dégradation progressive des performances, dont vous pouvez effectuer le suivi si vous réalisez une surveillance régulière, à l aide de votre outil de surveillance des performances ou d un système plus élaboré, tel que SCOM. Pour ces deux options, à des degrés divers, vous pouvez incorporer des solutions dans une alerte, sous la forme de texte d avertissement ou de commandes scriptées. Vous pouvez être amené à résoudre les problèmes de goulot d étranglement en apportant des modifications aux configurations matérielle ou système, après avoir déterminé qu ils ne sont pas liés à une mauvaise configuration, à l inefficacité d un code personnalisé ou de solutions tierces ou à une implémentation de solution inefficace. Les tableaux suivants identifient les conditions d apparition des problèmes et les options possibles pour résoudre ces derniers. Certaines des options suggèrent des mises à niveau ou des modifications matérielles. Objets et compteurs Problème Options de résolution Processeur 91

92 Objets et compteurs Problème Options de résolution Processeur : Pourcentage de temps processeur Disque Longueur moyenne de la file d attente du disque Supérieur à % Augmentation progressive, système dans un état instable et sauvegarde de la file d attente Mettez à niveau le processeur. Augmentez le nombre de processeurs. Ajoutez un ou plusieurs serveurs. Augmentez le nombre ou la vitesse des disques. Modifiez la configuration pour réduire le volume. Déplacez une partie des données vers un autre serveur. % temps inactivité Supérieur à 90 % Augmentez le nombre de disques. Déplacez les données vers un autre disque ou serveur. % d espace libre Inférieur à 30 % Augmentez le nombre de disques. Déplacez les données vers un autre disque ou serveur. Mémoire Mégaoctets disponibles Moins de 2 Go sur un serveur Web. Ajoutez de la mémoire. Remarque : La mémoire disponible sur le serveur SQL Server est faible par défaut, et n indique pas toujours l existence d un problème. Défauts de cache/s Nombre supérieur à 1 Ajoutez de la mémoire. 92

93 Objets et compteurs Problème Options de résolution Pages/s Nombre supérieur à 10 Ajoutez de la mémoire. Fichier d échange Dans la mesure du possible, augmentez la vitesse ou la taille du cache. Déplacez les données vers un autre disque ou serveur. Pourcentage d utilisation et pourcentage de pic d utilisation Le fichier d échange du serveur contient des adresses mémoire «virtuelles» du disque. Les défauts de page se produisent lorsqu un processus doit s arrêter et attendre que des ressources «virtuelles» requises soient récupérées en mémoire à partir du disque. Ces erreurs sont d autant plus fréquentes que la mémoire physique est inappropriée. Ajoutez de la mémoire. Carte réseau Octets totaux/s Processus Taux supérieur à % de la capacité du réseau. Il s agit du taux auquel les données sont envoyées et reçues via la carte d interface réseau. Approfondissez l analyse en surveillant les compteurs Octets reçus/s et Octets envoyés/s. Réévaluez la vitesse de la carte d interface réseau. Vérifiez le nombre, la taille et l utilisation des mémoires tampons. Jeu de travail Supérieur à 80 % de la mémoire totale Ajoutez de la mémoire. % temps processeur Supérieur à % Augmentez le nombre de processeurs. 93

94 Objets et compteurs Problème Options de résolution ASP.NET Recyclages du pool d applications Plusieurs par jour, entraînant un ralentissement intermittent. Redistribuez la charge de travail vers des serveurs supplémentaires. Vérifiez que vous n avez pas défini des paramètres qui recyclent automatiquement le pool d applications tout au long de la journée alors que cela n est pas nécessaire. Nb de demandes en attente Durée d attente de la demande Des centaines ou des milliers de demandes en attente. Lorsque le nombre d événements d attente augmente, la restitution des pages est moins performante du point de vue de l utilisateur. Implémentez des serveurs Web supplémentaires. La valeur maximale par défaut de ce compteur est et vous pouvez modifier ce paramètre dans le fichier Machine.config. Implémentez des serveurs Web supplémentaires. Demandes rejetées Nombre supérieur à 0 Implémentez des serveurs Web supplémentaires. Voir aussi Concepts Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Test de performances pour SharePoint Server 2010 Planification de la capacité pour SharePoint Server 2010 Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) 94

95 Autres ressources Health Monitoring (SharePoint Server 2010) 95

96 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Ce document décrit les limitations et frontières logicielles de Microsoft SharePoint Server 2010, dont les catégories sont les suivantes : Frontières : limites statiques qui ne peuvent absolument pas être dépassées. Seuils : limites configurables qui peuvent être dépassées si des contraintes spécifiques l imposent. limites prises en charge : limites configurables qui ont été définies par défaut sur une valeur testée. Remarque : Les informations de planification de capacité qui figurent dans ce document sont exploitables dans votre planification. Elles s appuient sur des tests effectués par Microsoft sur des propriétés activées. Les résultats obtenus sont toutefois susceptibles de varier en fonction de l équipement utilisé et des fonctionnalités implémentées pour vos sites. Dans cet article : Vue d ensemble des frontières et des limites Frontières, seuils et limites prises en charge Mode d établissement des limites Limites et frontières Limites par hiérarchie Limites des applications Web Limites des serveurs Web et des serveurs d applications Limites des bases de données de contenu 96

97 Limites des collections de sites Limites des listes et des bibliothèques Limites des colonnes Limites des pages Limites par fonctionnalité Limites de la recherche Limites du service de profil utilisateur Limites du déploiement de contenu Limites des blogs Limites de Business Connectivity Services Limites du flux de travail Limites des magasins de termes (bases de données) de métadonnées gérées Limites de Visio Services Limites de PerformancePoint Services Limites de Word Automation Services Limites de SharePoint Workspace Limites de OneNote Limites des services d application Web Office Limites de Project Server Vue d ensemble des frontières et des limites Cet article contient des informations qui vous aident à comprendre les limites de performances et de capacité testées de SharePoint Server 2010 et indique des recommandations pour obtenir des performances acceptables par rapport aux limites considérées. Utilisez les informations contenues dans cet article pour déterminer si votre déploiement planifié s inscrit dans le cadre des limites de performances et de capacité acceptables et pour configurer correctement les limites dans votre environnement. 97

98 Les résultats des tests et les recommandations fournis dans cet article s appliquent à une batterie de serveurs SharePoint Server 2010 monoserveur. L ajout de serveurs à l installation peut ne pas augmenter les limites de capacité des objets répertoriés dans les tableaux de la section Limites et frontières plus loin dans cette rubrique. Par contre, l ajout d ordinateurs serveurs augmente le débit d une batterie de serveurs, ce qui peut s avérer nécessaire pour atteindre des performances acceptables si l environnement comprend de nombreux objets. Dans certains cas, la nécessité d un nombre élevé d objets dans une solution peut imposer un nombre plus élevé de serveurs dans la batterie de serveurs. Notez que de nombreux facteurs peuvent avoir une incidence sur les performances dans un environnement donné et que chacun de ces facteurs peut avoir un impact sur les performances dans différents secteurs. Certains des résultats des tests et certaines des recommandations indiqués dans cet article peuvent concerner des fonctionnalités ou des opérations utilisateur qui n existent pas dans votre environnement et qui, par conséquent, ne s appliquent pas à votre solution. Seuls des tests minutieux peuvent vous fournir des données précises sur votre propre environnement. Frontières, seuils et limites prises en charge Dans SharePoint Server 2010, il existe certaines limites qui ne peuvent absolument pas être dépassées et d autres qui sont définies sur des valeurs par défaut et qui peuvent être modifiées par l administrateur de la batterie de serveurs. Il existe également certaines limites qui ne sont pas représentées par une valeur configurable, telles que le nombre de collections de sites par application Web. Les frontières sont des limites qui ne peuvent absolument pas être dépassées. Il est important que vous compreniez ces limites afin de ne pas concevoir votre batterie de serveurs sur des hypothèses erronées. Un exemple de frontière est la taille limite de 2 Go pour les documents ; vous ne pouvez pas configurer SharePoint Server de manière à stocker des documents dont la taille est supérieure à 2 Go. Il s agit d une valeur prédéfinie qui ne peut absolument pas être dépassée. Les seuils possèdent une valeur par défaut qui ne peut être dépassée que si elle est modifiée. Dans certaines circonstances, les seuils peuvent être dépassés si l évolution de la conception de votre batterie de serveurs le nécessite, mais il est important de comprendre que ce dépassement risque d avoir une incidence sur les performances de la batterie de serveurs, outre l impact sur la valeur effective des autres limites. La valeur par défaut de certains seuils ne peut être dépassée que dans la limite d une valeur maximale absolue. Un bon exemple est la taille limite des documents. Par défaut, le seuil de la taille des documents est défini sur 50 Mo, mais peut être modifié pour prendre en charge la frontière maximale de 2 Go. Les limites prises en charge définissent la valeur testée pour un paramètre donné. Les valeurs par défaut de ces limites ont été définies à l aide de tests et représentent les limitations connues du produit. Le dépassement des limites prises en charge risque de produire des résultats inattendus, une diminution significative des performances ou d autres effets nuisibles. 98

99 Certaines limites prises en charge sont des paramètres configurables qui sont définis par défaut sur la valeur recommandée, tandis que d autres limites prises en charge concernent des paramètres qui ne sont pas représentés par une valeur configurable. Un exemple de limite prise en charge est le nombre de collections de sites par application Web. La limite prise en charge est , qui constitue le nombre le plus élevé de collections de sites par application Web ayant satisfait aux tests d évaluation des performances. Il est important de garder à l esprit que de nombreuses valeurs limites fournies dans ce document représentent un point dans une courbe qui décrit une charge croissante sur les ressources et une diminution concomitante des performances à mesure que la valeur augmente. Par conséquent, le dépassement de certaines limites, telles que le nombre de collections de sites par application Web, risque de n aboutir qu à une faible diminution des performances de la batterie de serveurs. Toutefois, dans la plupart des cas, l application d une limite établie ou d une valeur approchante n est pas une meilleure pratique, car les cibles de performances et de fiabilité acceptables sont d autant plus facilement atteintes que la conception d une batterie de serveurs prévoit un compromis raisonnable entre les valeurs limites. Les recommandations sur les seuils et les limites prises en charge sont déterminées par les performances. En d autres termes, vous pouvez dépasser les valeurs par défaut des limites, mais l augmentation d une valeur limite peut avoir une incidence sur les performances de la batterie de serveurs et sur la valeur effective des autres limites. De nombreuses limites dans SharePoint Server peuvent être modifiées, mais il est important de comprendre l impact que peut avoir la modification d une limite donnée sur les autres parties de la batterie de serveurs. Mode d établissement des limites Dans SharePoint Server 2010, les seuils et les limites prises en charge sont établis par le test et l observation du comportement de la batterie de serveurs en fonction de charges croissantes jusqu au point où les opérations et les services de la batterie de serveurs atteignent leurs limites de fonctionnement effectives. Étant donné que certains services et composants de la batterie de serveurs peuvent accepter plus de charge que d autres, dans certains cas, vous devez affecter une valeur limite basée sur une moyenne de plusieurs facteurs. Par exemple, les observations du comportement de la batterie de serveurs testée lorsque des collections de sites sont ajoutées indiquent que certaines fonctionnalités présentent une latence anormalement élevée tandis que d autres affichent des paramètres de fonctionnement acceptables. Par conséquent, la valeur maximale affectée au nombre de collections de sites n est pas absolue, mais elle est calculée en fonction d un ensemble attendu de caractéristiques d utilisation dans lequel les performances globales de la batterie de serveurs sont acceptables pour la limite donnée dans certaines circonstances. Si certains services fonctionnent avec des paramètres plus élevés que ceux utilisés pour le test des limites, les limites effectives maximales des autres services seront réduites. Il est donc important d effectuer des tests d échelle et de gestion de capacité rigoureux pour des déploiements spécifiques afin d établir des limites effectives pour l environnement considéré. Remarque : nous ne décrivons pas dans ce document le matériel qui a été utilisé pour la validation des limites, car celles-ci ont été collectées à partir de plusieurs batteries de serveurs et environnements. Pour des descriptions des batteries de serveurs utilisées pour les 99

100 tests, voir Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) et Performance and capacity technical case studies (SharePoint Server 2010) (en anglais). Métaphore de l égaliseur Vous pouvez considérer les seuils et les limites prises en charge comme les curseurs d un égaliseur graphique, chaque limite représentant une certaine fréquence. Dans cette métaphore, l augmentation de la valeur d une limite peut diminuer la valeur effective d une ou plusieurs autres limites. Imaginez qu un curseur représente le nombre maximum de documents par bibliothèque, en l occurrence une limite prise en charge dont la valeur testée maximale est d environ 30 millions. Toutefois, cette valeur dépend d un autre curseur, qui représente la taille maximale des documents dans la batterie de serveurs, en l occurrence un seuil dont la valeur par défaut est 50 Mo. Si vous définissez la taille maximale des documents sur 1 Go pour prendre en charge les vidéos ou autres objets volumineux, le nombre de documents que votre bibliothèque peut fournir efficacement aux utilisateurs est réduit en conséquence. Par exemple, la configuration matérielle et la topologie d une batterie de serveurs donnée peuvent prendre en charge 1 million de documents pouvant avoir une taille maximale de 50 Mo. Toutefois, comme la taille limite des fichiers a été définie sur 1 Go, la même batterie de serveurs avec le même nombre de documents ne peut pas satisfaire aux mêmes objectifs de latence et de débit si la taille moyenne des documents qu elle fournit est supérieure. Le degré auquel le nombre maximal de documents est réduit dans cet exemple est difficile à prévoir, car cela dépend du nombre de fichiers volumineux dans la bibliothèque, du volume de données qu ils contiennent, des caractéristiques d utilisation de la batterie de serveurs et de la disponibilité des ressources matérielles. Limites et frontières Cette section répertorie les objets qui peuvent faire partie d une solution et indique des recommandations permettant d obtenir des performances acceptables pour chaque type d objet. La notion de «performances acceptables» signifie que le système tel qu il a été testé peut prendre en charge le nombre d objets indiqué, mais que celui-ci ne peut être dépassé qu au prix d une diminution des performances ou d une réduction de la valeur des limites connexes. Les objets sont répertoriés par étendue et par fonctionnalité. Les données des limites sont indiquées, ainsi que des remarques qui décrivent les conditions dans lesquelles la limite est obtenue et, le cas échéant, des liens vers des informations complémentaires. Appuyez-vous sur les recommandations indiquées dans cet article pour passer en revue les plans de votre solution globale. Si ces derniers dépassent les recommandations pour un ou plusieurs objets, effectuez au moins l une des opérations suivantes : Évaluez la solution pour vous assurer que des compensations sont effectuées dans d autres secteurs. Marquez ces secteurs comme devant être testés et surveillés lors de la génération du déploiement. 100

101 Repensez ou fractionnez la solution pour vous assurer que vous ne dépassez pas les recommandations liées à la capacité. Limites par hiérarchie Cette section indique des limites triées en fonction de la hiérarchie logique d une batterie de serveurs SharePoint Server Limites des applications Web Le tableau suivant répertorie les recommandations pour les applications Web. Limite Valeur maximale Type de limite Remarques Base de données de contenu 300 par application Web Prise en charge Avec 300 bases de données de contenu par application Web, les opérations des utilisateurs finaux telles que l ouverture du site ou des collections de sites ne sont pas affectées. Par contre, les opérations d administration telles que la création d une collection de sites subissent une diminution des performances. Il est recommandé d utiliser Windows PowerShell pour gérer l application Web lorsque de nombreuses bases de données de contenu sont présentes, car l interface de gestion devient lente et difficile à parcourir. Zone 5 par application Web Frontière Le nombre de zones définies pour une batterie de serveurs est codé en dur sur 5. Les zones sont Par défaut, Intranet, Extranet, Internet et Personnalisée. 101

102 Limite Valeur maximale Type de limite Remarques Chemin d accès géré 20 par application Web Prise en charge Les chemins d accès gérés sont mis en cache sur le serveur Web, et les ressources processeur sont utilisées pour le traitement des demandes entrantes par rapport à la liste des chemins d accès gérés. 102 Le dépassement de 20 chemins d accès gérés par application Web accentue la charge imposée au serveur Web pour chaque demande. Si vous envisagez de dépasser vingt chemins d accès gérés dans une application Web donnée, il est recommandé de procéder à des tests afin de déterminer si le système peut atteindre des performances acceptables. Taille du cache des solutions 300 Mo par application Web Seuil Le service InfoPath Forms peut conserver les solutions dans le cache des solutions afin d accélérer leur récupération. Si la taille du cache est dépassée, les solutions sont récupérées du disque, ce qui peut ralentir les temps de réponse. Vous pouvez configurer la taille du cache des solutions à l aide de l applet de commande Windows PowerShell

103 Limite Valeur maximale Type de limite Remarques Set-SPInfoPathFormsService. Pour plus d informations, voir Set- SPInfoPathFormsService. Limites des serveurs Web et des serveurs d applications Le tableau suivant répertorie les recommandations pour les serveurs Web de la batterie de serveurs. Limite Valeur maximale Type de limite Remarques Pools d applications 10 par serveur Web Prise en charge Le nombre maximal est déterminé par les capacités matérielles. Cette limite dépend en grande partie : 103 de la quantité de mémoire RAM allouée aux serveurs Web ; de la charge de travail assurée par la batterie de serveurs, c est-à-dire des caractéristiques de la base des utilisateurs et de l utilisation (un

104 Limite Valeur maximale Type de limite Remarques seul pool d applications très actif peut atteindre 10 Go ou plus). Limites des bases de données de contenu Le tableau suivant répertorie les recommandations pour les bases de données de contenu. Limite Valeur maximale Type de limite Remarques Taille des bases de données de contenu 200 Go par base de données de contenu Prise en charge Il est fortement recommandé de limiter la taille des bases de données de contenu à 200 Go pour garantir les performances du système. Des tailles de base de données de contenu jusqu à 1 To sont prises en charge seulement pour les référentiels et les archives monosite volumineux avec des E-S et des schémas d utilisation non collaboratifs, tels que des Centres des enregistrements. Des tailles de base de données 104

105 Limite Valeur maximale Type de limite Remarques 105 plus importantes sont prises en charge pour ces scénarios car leurs schémas d E-S et les formats de leurs structures de données classiques ont été conçus et testés pour une plus grande échelle. Pour plus d informations sur les référentiels de documents à grande échelle, voir «Évaluer les exigences en matière de performances et de capacité pour les référentiels de documents à grande échelle», dans Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010), et «Scénarios classiques de gestion de contenu à grande échelle», dans Enterprise content storage planning (SharePoint Server 2010). Une collection de sites ne doit pas dépasser 100 Go sauf si c est la seule

106 Limite Valeur maximale Type de limite Remarques collection de sites de la base de données. Collections de sites par base de données de contenu (recommandé) (maximum) Prise en charge Nous avons vivement recommandé de limiter à le nombre de collections de sites dans une base de données de contenu. Toutefois, le nombre maximum de collections de sites pouvant être prises en charge dans une base de données est de Ces limites concernent la vitesse de la mise à niveau. Plus le nombre de collections de sites est élevé dans une base de données, plus la mise à niveau est lente. La limite du nombre de collections de sites dans une base de données est tributaire de la taille limite d une base de données de contenu qui comporte plusieurs collections de sites (200 Go). Par conséquent, à mesure qu augmente le nombre de 106

107 Limite Valeur maximale Type de limite Remarques 107 collections de sites dans une base de données, la taille moyenne des collections de sites qu elle contient doit diminuer. Le dépassement de la limite de collections de sites risque d entraîner des temps morts plus longs pendant les mises à niveau. Si vous envisagez de dépasser collections de sites, il est recommandé de mettre en œuvre une stratégie de mise à niveau précise et de renforcer la configuration matérielle pour accélérer les mises à niveau et les mises à jour logicielles qui ont un impact sur les bases de données. Pour définir le niveau d avertissement du nombre de sites dans une base de données de contenu, utilisez l applet de commande Windows PowerShell Set- SPContentDatabase avec le paramètre -

108 Limite Valeur maximale Type de limite Remarques WarningSiteCount. Pour plus d informations, voir Set-SPContentDatabase. Sous-système de stockage BLOB distant (RBS) sur le serveur NAS (Network Attached Storage) Le temps d attente du premier octet d une réponse en provenance du serveur NAS ne peut pas dépasser 20 millisecondes. Frontière Lorsque SharePoint Server 2010 est configuré pour utiliser RBS et que des objets BLOB résident sur le support de stockage NAS, envisagez la frontière suivante. Entre le moment où SharePoint Server 2010 demande un objet BLOB et le moment où il reçoit le premier octet de la part du serveur NAS, pas plus de 20 millisecondes ne peuvent s écouler. Limites des collections de sites Le tableau suivant répertorie les recommandations pour les collections de sites. Limite Valeur maximale Type de limite Remarques Site Web par collection de sites Prise en charge Le nombre recommandé maximal de sites et de soussites est de

109 Limite Valeur maximale Type de limite Remarques Vous pouvez créer un nombre total de sites Web très élevé en imbriquant des sous-sites. Par exemple, dans une hiérarchie peu profonde de 100 sites, comportant chacun soussites, vous disposez d un total de sites Web. De même, dans une hiérarchie profonde de 100 sites, comportant chacun 10 niveaux de sous-site, vous disposez également d un total de sites Web. Remarque : la suppression ou la création d un site ou d un sous-site peut avoir un impact significatif sur la disponibilité d un site. L accès au site et aux sous-sites est limité pendant la suppression du site. En outre, une tentative de créer de nombreux sous-sites en même temps peut échouer. Taille des collections de sites 100 Go par collection de sites Prise en charge Une collection de sites ne doit pas dépasser 100 Go sauf si c est la seule collection de sites de la base de données. Certaines actions sur les collections de sites, telles que 109

110 Limite Valeur maximale Type de limite Remarques la sauvegarde/restauration d une collection de sites ou l applet de commande Windows PowerShell Move- SPSite, entraînent des opérations Microsoft SQL Server d envergure qui peuvent avoir un impact sur les performances ou échouer si d autres collections de sites sont actives dans la même base de données. Pour plus d informations, voir Move- SPSite. Limites des listes et des bibliothèques Le tableau suivant répertorie les recommandations pour les listes et les bibliothèques. Pour plus d informations, voir le livre blanc «Conception de listes volumineuses et optimisation de la performance des listes» accessible dans Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010). Limite Valeur maximale Type de limite Remarques Taille des lignes des listes octets par ligne Frontière Chaque élément de liste ou de bibliothèque ne peut occuper que octets au total dans la base de données. 256 octets sont réservés pour les colonnes prédéfinies, ce qui laisse octets pour les colonnes des utilisateurs finaux. Pour plus d informations sur la quantité d espace consommée par chaque type de 110

111 Limite Valeur maximale Type de limite Remarques champ, voir Limites des colonnes. Taille des fichiers 2 Go Frontière La taille de fichier maximale par défaut est de 50 Mo. Cette valeur peut être augmentée jusqu à 2 Go ; toutefois, une quantité élevée de fichiers très volumineux peut avoir une incidence sur les performances de la batterie de serveurs. Documents par bibliothèque Prise en charge Vous pouvez créer des bibliothèques de documents très volumineuses en imbriquant des dossiers ou en utilisant une hiérarchie de site et des affichages standard. Cette valeur peut varier suivant la façon dont les documents et les dossiers sont organisés et en fonction du type et de la taille des documents stockés. Versions principales Prise en charge Éléments par liste Prise en charge Si vous dépassez cette limite, les opérations de base sur les fichiers, telles que l ouverture, l enregistrement, la suppression d un fichier et l affichage de l historique des versions, risquent d échouer. Vous pouvez créer des listes très volumineuses en utilisant la navigation par métadonnées, des hiérarchies de site et des affichages standard. Cette valeur peut varier suivant le nombre de colonnes dans la liste et l utilisation de celle-ci. Taille limite des lignes 6 lignes de table internes à la base de données utilisées pour un élément de liste ou de bibliothèque Prise en charge 111 Spécifie le nombre maximal de lignes de table internes à la base de données pouvant être utilisées pour un élément de liste ou de bibliothèque. Pour qu il soit possible de prendre en charge des listes volumineuses comportant de nombreuses colonnes, chaque élément

112 Limite Valeur maximale Type de limite Opérations en bloc 100 éléments par opération en bloc Frontière Remarques peut être réparti sur plusieurs lignes de table internes, dans la limite de six lignes par défaut. Ce paramétrage peut être configuré par les administrateurs de batterie par le biais du modèle objet uniquement. La méthode du modèle objet est SPWebApplication.MaxListItemRowStorage (éventuellement en anglais). L interface utilisateur permet de sélectionner au maximum 100 éléments pour les opérations en bloc. Seuil de recherche d affichage de liste 8 opérations de jointure par requête Seuil 112 Spécifie le nombre maximal de jointures autorisées par requête, telles que celles basées sur des colonnes de recherche, personne/groupe ou d état de flux de travail. Si la requête utilise plus de huit jointures, l opération est bloquée. Ceci ne s applique pas à des opérations sur un seul élément. Lors de l utilisation de l affichage maximal via le modèle objet (en ne spécifiant aucun champ d affichage), SharePoint retourne jusqu aux huit premières recherches. Seuil d affichage de liste Seuil Spécifie le nombre maximal d éléments de liste ou de bibliothèque qu une opération de base de données telle qu une requête peut traiter en même temps en dehors de la fenêtre de temps quotidienne définie par l administrateur, au cours de laquelle les requêtes ne sont pas limitées. Seuil d affichage de liste pour les auditeurs et les administrateurs Seuil Spécifie le nombre maximal d éléments de liste ou de bibliothèque qu une opération de base de données telle qu une requête peut traiter en même temps lorsqu elle

113 Limite Valeur maximale Type de limite Remarques est effectuée par un auditeur ou un administrateur ayant les autorisations appropriées. Ce paramètre fonctionne avec Autoriser le remplacement du modèle objet. Sous-site par affichage de site Seuil L interface permettant d énumérer les sous-sites d un site Web donné est moins performante dès que le nombre de sous-sites est supérieur à De même, les performances de la page Tout le contenu du site et du contrôle arborescence diminuent sensiblement à mesure que le nombre de sous-sites croît. Co-création dans Microsoft Word 10 éditeurs simultanés par et Microsoft PowerPoint pour des document fichiers.docx,.pptx et.ppsx Seuil Le nombre maximal recommandé d éditeurs simultanés est de 10. La frontière est 99. Si 99 co-auteurs travaillent simultanément sur un même document ouvert, tout utilisateur à partir du 100e utilisateur obtient l erreur «Fichier en cours d utilisation» et doit afficher une copie en lecture seule. Dès que le nombre de co-éditeurs est supérieur à 10, l expérience utilisateur se dégrade progressivement en raison du nombre croissant de conflits et les utilisateurs doivent s y prendre à plusieurs reprises pour que leurs modifications soient correctement téléchargées. Étendue de sécurité par liste Seuil Le nombre maximal d étendues de sécurité uniques défini pour une liste ne doit pas être supérieur à Une étendue constitue la frontière de sécurité pour un objet sécurisable et tous ses enfants pour lesquels une frontière de sécurité distincte n est pas définie. Une étendue contient une liste de contrôle d accès, mais à la différence des listes de contrôle d accès NTFS, une

114 Limite Valeur maximale Type de limite Remarques étendue peut inclure des principaux de sécurité spécifiques à SharePoint Server. Les membres d une liste de contrôle d accès pour une étendue peuvent comprendre des utilisateurs Windows, des comptes d utilisateur autres que des utilisateurs Windows (tels que des comptes basés sur des formulaires), des groupes Active Directory ou des groupes SharePoint. Limites des colonnes Les données SharePoint Server 2010 sont stockées dans des tables SQL Server. Pour autoriser le nombre maximal de colonnes possible dans une liste SharePoint, SharePoint Server crée plusieurs lignes dans la base de données lorsque les données ne contiennent pas dans une seule ligne. Cette opération s appelle «retour automatique à la ligne». À chaque retour à la ligne dans SQL Server, une charge de requête supplémentaire est soumise au serveur lorsque cet élément est interrogé, car une jointure SQL doit être incluse dans la requête. Pour que les charges ne soient pas excessives, par défaut, au maximum six lignes SQL Server sont autorisées pour un élément SharePoint. Cette limite se traduit par une limitation spécifique du nombre de colonnes de chaque type pouvant être incluses dans une liste SharePoint. Le tableau suivant décrit les limites pour chaque type de colonne. Le paramètre de retour automatique à la ligne peut être augmenté au-delà de six, mais cela risque de se traduire par des charges excessives sur le serveur. Il est recommandé de tester les performances avant de dépasser cette limite. Pour plus d informations, voir le livre blanc «Conception de listes volumineuses et optimisation de la performance des listes» accessible dans Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010). La valeur de la taille de chaque type de colonne est indiquée en octets. La somme de toutes les colonnes dans une liste SharePoint ne peut pas dépasser octets. Suivant l utilisation de la colonne, les utilisateurs peuvent atteindre la limite de octets avant d atteindre la limite de six lignes spécifique au retour automatique à la ligne. 114

115 Limite Valeur maximale Type de limite Taille par colonne Remarques Une seule ligne de texte 276 Seuil 28 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 64 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 384 colonnes de type Une seule ligne de texte par liste SharePoint (6 * 64 = 384). Toutefois, la limite par élément de liste SharePoint étant de octets, dont 256 réservés pour les colonnes SharePoint prédéfinies, la limite réelle est de 276 colonnes de type Une seule ligne de texte. Plusieurs lignes de texte 192 Seuil 28 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 32 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 192 colonnes de type Plusieurs lignes de texte par liste SharePoint (6 * 32 = 192). Choix 276 Seuil 28 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 64 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 384 colonnes de type Choix par liste SharePoint (6 * 64 = 384) ; toutefois, la limite par élément de liste SharePoint étant de octets, dont 256 réservés pour les colonnes SharePoint prédéfinies, la limite réelle doit être de 276 colonnes de type Choix. 115

116 Limite Valeur maximale Type de limite Taille par colonne Remarques Nombre 72 Seuil 12 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 12 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 72 colonnes de type Nombre par liste SharePoint (6 * 12 = 72). Devise 72 Seuil 12 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 12 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 72 colonnes de type Devise par liste SharePoint (6 * 12 = 72). Date et heure 48 Seuil 12 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 8 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 48 colonnes de type Date et heure par liste SharePoint (6 * 8 = 48). Recherche 96 Seuil 4 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 16 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 96 colonnes de type Recherche à valeur unique par liste SharePoint (6 * 16 = 96). Oui/Non 96 Seuil 5 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 16 colonnes dans une liste SharePoint. La valeur par défaut du 116

117 Limite Valeur maximale Type de limite Taille par colonne Remarques retour automatique à la ligne (6) autorise un maximum de 96 colonnes de type Oui/Non par liste SharePoint (6 * 16 = 96). Personne ou groupe 96 Seuil 4 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 16 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 96 colonnes de type Personne ou groupe par liste SharePoint (6 * 16 = 96). Lien hypertexte ou image 138 Seuil 56 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 32 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 192 colonnes de type Lien hypertexte ou image par liste SharePoint (6 * 32 = 192) ; toutefois, la limite par élément de liste SharePoint étant de octets, dont 256 réservés pour les colonnes SharePoint prédéfinies, la limite réelle doit être de 138 colonnes de type Lien hypertexte ou image. Calculé 48 Seuil 28 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 8 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 48 colonnes de type Calculé par liste SharePoint (6 * 8 = 48). 117

118 Limite Valeur maximale Type de limite Taille par colonne Remarques GUID 6 Seuil 20 octets Le retour automatique à la ligne SQL Server se produit après chaque colonne dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 6 colonnes de type GUID par liste SharePoint (6 * 1 = 6). Ent 96 Seuil 4 octets Le retour automatique à la ligne SQL Server se produit après chaque groupe de 16 colonnes dans une liste SharePoint. La valeur par défaut du retour automatique à la ligne (6) autorise un maximum de 96 colonnes de type Ent par liste SharePoint (6 * 16 = 96). Métadonnées gérées 94 Seuil 40 octets pour la première, 32 octets pour chacune des suivantes 118 Quatre colonnes sont allouées au premier champ Métadonnées gérées ajouté à une liste : Un champ Liste de choix pour la balise réelle Un champ de texte masqué pour la valeur de chaîne Un champ Liste de choix pour le fourre-tout Un champ Liste de choix pour les éléments n appartenant pas au fourre-tout Chaque ajout de champ Métadonnées gérées à une liste se traduit par l ajout de deux colonnes : Un champ Liste de choix pour la balise réelle Un champ de texte masqué pour la valeur de chaîne Le nombre maximal de colonnes de métadonnées

119 Limite Valeur maximale Type de limite Taille par colonne Remarques gérées est égal à (14 + (16 * (n-1))) où n représente la valeur du mappage de lignes (6 par défaut). Les colonnes de type Données externes présentent le concept de colonne principale et de colonnes secondaires. Lorsque vous ajoutez une colonne de données externes, vous pouvez sélectionner certains champs secondaires de type contenu externe en vue de les ajouter à la liste. Par exemple, dans le cas d un type de contenu externe «Client» qui possède des champs tels que les champs «ID», «Nom», «Pays» et «Description», lorsque vous ajoutez une colonne de données externes de type «Client» à une liste, vous pouvez ajouter des champs secondaires pour afficher les «ID», «Nom», «Pays» et «Description» du client. Dans l ensemble, les colonnes ajoutées sont les suivantes : Colonne principale : un champ texte. Colonne ID masqué : un champ texte multiligne. Colonnes secondaires : chaque colonne secondaire est un champ texte/nombre/booléen/texte multiligne basé sur le type de données de la colonne secondaire définie dans le modèle du catalogue de données métiers. Par exemple, ID peut être mappé sur une colonne Nombre, Nom sur une colonne Une seule ligne de texte et Description sur une colonne Plusieurs lignes de texte. Limites des pages Le tableau suivant répertorie les recommandations pour les pages. Limite Valeur maximale Type de limite Remarques Composants WebPart 25 par page Wiki ou page de composants WebPart Seuil Ce chiffre est une estimation basée sur des composants WebPart simples. La complexité des composants 119

120 Limite Valeur maximale Type de limite Remarques WebPart détermine le nombre de composants WebPart pouvant être utilisés sans que les performances soient affectées. Limites de sécurité Limite Valeur maximale Type de limite Remarques Nombre de groupes SharePoint auxquels un utilisateur peut appartenir Prise en charge Cette limite n est pas codée en dur, mais elle est cohérente avec les recommandations Active Directory. Plusieurs éléments ont une incidence sur ce nombre : La taille du jeton d utilisateur. Le cache des groupes : SharePoint Server 2010 possède une table qui met en 120

121 Limite Valeur maximale Type de limite Remarques 121 cache le nombre de groupes auxquels un utilisateur appartient dès que ces groupes sont utilisés dans des listes de contrôle d accès. La durée de la vérification de sécurité : lorsque le nombre de groupes dont un utilisateur est membre augmente, la durée nécessaire pour la vérification de l accès augmente également. Utilisateurs dans une collection de sites 2 millions par collection de sites Prise en charge Vous pouvez ajouter des millions de personnes à votre site Web à l aide de groupes de sécurité Microsoft Windows pour gérer la sécurité, au lieu d utiliser des utilisateurs individuels.

122 Limite Valeur maximale Type de limite Remarques Cette limite repose sur la facilité de gestion et de navigation dans l interface utilisateur. Lorsque la collection de sites comprend plus d un millier d entrées (groupes de sécurité d utilisateurs), vous devez utiliser Windows PowerShell pour gérer les utilisateurs, au lieu de l interface utilisateur. Cela procure une meilleure expérience en termes de gestion. Utilisateurs/principaux Active Directory dans un groupe SharePoint par groupe SharePoint Prise en charge SharePoint Server 2010 vous permet d ajouter des utilisateurs ou des groupes Active Directory à un groupe SharePoint. Vous pouvez obtenir des performances acceptables dans la limite de utilisateurs (ou utilisateurs ou groupes 122

123 Limite Valeur maximale Type de limite Remarques 123 Active Directory) dans un groupe SharePoint. Les activités les plus concernées par cette limite sont les suivantes : Extraction d utilisateurs pour valider les autorisations. Cette opération prend d autant plus de temps que le nombre d utilisateurs dans un groupe est élevé. Rendu de l appartenance de l affichage. Cette opération prend toujours du temps. Groupes SharePoint par collection de sites Prise en charge Au-delà de groupes, la durée d exécution des opérations augmente de manière significative. Cela est particulièrement vrai

124 Limite Valeur maximale Type de limite Remarques Principal de sécurité : taille de l étendue de sécurité pour l ajout d un utilisateur à un groupe existant, la création d un groupe et le rendu des affichages de groupes par liste de contrôle d accès Prise en charge La taille de l étendue a une incidence sur les données utilisées pour le calcul d une vérification de sécurité. Ce calcul est effectué chaque fois que l étendue change. Il n existe pas de limite codée en dur, mais plus l étendue est grande, plus la durée du calcul est longue. Limites par fonctionnalité Cette section répertorie les limites par fonctionnalité. Limites de la recherche Le tableau suivant répertorie les recommandations pour la recherche. 124

125 Limite Valeur maximale Type de limite Remarques Applications de service de recherche SharePoint 20 par batterie de serveurs Prise en charge Plusieurs applications de service de recherche SharePoint peuvent être déployées sur une même batterie de serveurs, car vous pouvez affecter des bases de données et des composants de recherche à différents serveurs. La limite recommandée de 20 est inférieure à la limite maximale pour toutes les applications de service dans une batterie de serveurs. Bases de données d analyse et éléments de base de données 10 bases de données d analyse par application de service de recherche 25 millions d éléments par base de données d analyse Seuil La base de données d analyse stocke les données d analyse (durée/statut, etc.) au sujet de tous les éléments qui ont été analysés. La limite prise en charge est de 10 bases de données d analyse par application de service de recherche SharePoint. La limite recommandée est de 25 millions d éléments par base de données d analyse (ou un total de quatre bases de données d analyse par application de service de recherche). Composants d analyse 16 par application de service de recherche Seuil La limite recommandée par application est de 16 composants 125

126 Limite Valeur maximale Type de limite Remarques d analyse au total, dont deux par base de données d analyse et deux par serveur, dans l hypothèse où le serveur possède au moins huit processeurs (cœurs). Le nombre total de composants d analyse par serveur doit être inférieur à 128/(nombre total de composants de requête) pour réduire au minimum la dégradation des opérations d E/S de propagation. Le dépassement de la limite recommandée peut ne pas se traduire par de meilleures performances d analyse ; en fait, celles-ci peuvent diminuer suivant la disponibilité des ressources sur le serveur d analyse, la base de données et l hôte du contenu. Partitions d index 20 par application de service de recherche ; 128 au total 126 Seuil La partition d index contient un sous-ensemble de l index de l application de service de recherche. La limite recommandée est de 20. Si vous augmentez le nombre de partitions d index, chaque partition contient un sousensemble plus petit de l index, ce qui réduit la mémoire RAM et

127 Limite Valeur maximale Type de limite Remarques l espace disque requis sur le serveur de requête qui héberge le composant de requête affecté à la partition d index. La frontière pour le nombre total de partitions d index est 128. Éléments indexés 100 millions par application de service de recherche ; 10 millions par partition d index Prise en charge La recherche SharePoint prend en charge les partitions d index, qui contiennent chacune un sousensemble de l index de recherche. Le maximum recommandé est de 10 millions d éléments par partition. Le nombre d éléments maximal recommandé global (par exemple, personnes, éléments de liste, documents, pages Web) est de 100 millions. Entrées du journal d analyse 100 millions par application de recherche Prise en charge Bases de données de propriétés 10 par application de service de recherche ;128 au Seuil total 127 Il s agit du nombre des différentes entrées du journal d analyse. Ce nombre suit la limite des éléments indexés. La base de données de propriétés stocke les métadonnées des éléments de chaque partition d index qui lui est associée. Une partition d index ne peut être associée qu à une seule banque de propriétés. La limite

128 Limite Valeur maximale Type de limite Remarques recommandée est de 10 bases de données de propriétés par application de service de recherche. La frontière pour les partitions d index est de 128. Composants de requête 128 par application de recherche ; 64/(nombre total de composants d analyse) par serveur Seuil Le nombre total de composants de requête est limité par la capacité des composants d analyse à copier les fichiers. Le nombre maximal de composants de requête par serveur est limité par la capacité des composants de requête à absorber les fichiers propagés à partir des composants d analyse. Règles d étendue 100 règles d étendue par étendue ; 600 au total par application de service de recherche 128 Seuil Le dépassement de cette limite réduit le caractère actualisé de l analyse et retarde les résultats potentiels des requêtes sur lesquelles porte la recherche. Étendues 200 par site Seuil Il s agit d une limite recommandée par site. Le dépassement de cette limite peut réduire l efficacité de l analyse et, si les étendues sont ajoutées au groupe d affichage, affecter la latence du navigateur de l utilisateur final. En outre, l affichage des étendues dans

129 Limite Valeur maximale Type de limite Remarques l interface de l administration de la recherche se dégrade dès que le nombre d étendues est supérieur à la limite recommandée. Groupes d affichage 25 par site Seuil Les groupes d affichage permettent d obtenir un affichage groupé des étendues par le biais de l interface utilisateur. Le dépassement de cette limite entraîne la dégradation de l expérience des étendues dans l interface utilisateur d administration de la recherche. Alertes par application de recherche Prise en charge Il s agit de la limite testée. Sources de contenu 50 par application de service de recherche Seuil La limite recommandée de 50 peut être dépassée jusqu à la frontière de 500 par application de service de recherche. Toutefois, vous devez utiliser moins d adresses de démarrage et suivre la limite du nombre d analyses simultanées. Adresses de démarrage 100 par source de contenu Seuil La limite recommandée peut être dépassée jusqu à la frontière de 500 par source de contenu. Toutefois, plus le nombre d adresses de démarrage est 129

130 Limite Valeur maximale Type de limite 130 Remarques élevé, moins vous devez utiliser de sources de contenu. Si le nombre d adresses de démarrage est élevé, il est recommandé de les placer sous la forme de liens dans une page html et de faire analyser celle-ci par le robot HTTP, en suivant les liens. Analyses simultanées 20 par application de recherche Seuil Il s agit du nombre d analyses en cours d exécution au même moment. Le dépassement de ce nombre peut entraîner une diminution du taux d analyse global. Propriétés analysées par application de recherche Prise en charge Il s agit des propriétés détectées pendant une analyse. Règle d impact de l analyse 100 Seuil La limite recommandée est de 100 par batterie de serveurs. La recommandation peut être dépassée ; toutefois, cela se traduit par une dégradation de l affichage des règles de fréquence d accès au site dans l interface d administration de la recherche. Lorsque le nombre de règles de fréquence d accès s élève à environ, la page Gérer les règles de fréquence

131 Limite Valeur maximale Type de limite Remarques d'accès au site devient illisible. Règles d analyse 100 par application de service de recherche Seuil Cette valeur peut être dépassée ; toutefois, cela se traduit par une dégradation de l affichage des règles d analyse dans l interface d administration de la recherche. Propriétés gérées par application de service de recherche Seuil Il s agit de propriétés qu utilise le système de recherche dans les requêtes. Les propriétés analysées sont mappées sur les propriétés gérées. Mappages 100 par propriété gérée Seuil Le dépassement de cette limite peut entraîner une diminution de la vitesse des analyses et des performances des requêtes. Suppressions d URL 100 suppressions par opération Prise en charge Pages de référence Une page de niveau supérieur et aussi peu que possible de pages de deuxième et troisième niveau par application de service de recherche 131 Seuil Il s agit du nombre recommandé maximal d URL à supprimer du système en une seule opération. La limite recommandée est une page de référence de niveau supérieur et aussi peu que possible de pages de deuxième et troisième niveau pour atteindre la pertinence désirée. La frontière est 200 par niveau de pertinence et par application de recherche, mais l ajout de pages

132 Limite Valeur maximale Type de limite Mots clés 200 par collection de sites Prise en charge 132 Remarques ne permet pas forcément d atteindre la pertinence désirée. Ajoutez le site clé au premier niveau de pertinence. Ajoutez d autres sites clés aux second ou troisième niveaux de pertinence, un à la fois, et évaluez la pertinence après chaque ajout pour vous assurer que l effet de pertinence désirée est obtenu. La limite recommandée peut être dépassée jusqu à la limite maximale de (imposée par ASP.NET) par collection de sites sur la base de cinq meilleurs résultats par mot clé. Si vous dépassez cette limite, l affichage des mots clés dans l interface utilisateur de l administration du site s en trouvera dégradé. Vous pouvez ajuster la limite imposée par ASP.NET en modifiant les fichiers Web.Config et Client.config (MaxItemsInObjectGraph). Propriétés de métadonnées reconnues par élément analysé Frontière Il s agit du nombre de propriétés de métadonnées pouvant être déterminées et éventuellement mappées ou utilisées pour des

133 Limite Valeur maximale Type de limite Remarques requêtes lorsqu un élément est analysé. Limites du service de profil utilisateur Le tableau suivant répertorie les recommandations pour le service de profil utilisateur. Limite Valeur maximale Type de limite Remarques Profils utilisateur par application de service Prise en charge Une application de service de profil utilisateur peut prendre en charge jusqu à 2 millions de profils utilisateur sans porter préjudice aux fonctionnalités de mise en réseau. Ce nombre représente le nombre de profils pouvant être importés dans le magasin de profils des personnes à partir d un service d annuaire, ainsi que le nombre de 133

134 Limite Valeur maximale Type de limite Remarques 134 profils qu une application de service de profil utilisateur peut prendre en charge sans entraîner de diminution des performances des fonctionnalités de mise en réseau. Liens de mise en réseau, notes et notations par base de données sociale Prise en charge Jusqu à 500 millions de liens de mise en réseau, de notes et de notations au total sont pris en charge dans une base de données sociale sans diminution significative des performances. Toutefois, les opérations de maintenance de la base de données telles que la sauvegarde et la restauration peuvent afficher une diminution des

135 Limite Valeur maximale Type de limite Remarques performances à ce niveau. Limites du déploiement de contenu Le tableau suivant répertorie les recommandations pour le déploiement de contenu. Limite Valeur maximale Type de limite Remarques travaux de déploiement de contenu en cours d exécution sur différents chemins d accès 20 Prise en charge L exécution simultanée de différents travaux sur des chemins d accès connectés à des collections de sites qui appartiennent à la même base de données de contenu source risque d entraîner des blocages au niveau de cette base de données. Pour les travaux qui doivent s exécuter simultanément, il est recommandé de déplacer les collections de sites dans différentes bases de données de contenu sources. Remarque : Des travaux ne peuvent pas s exécuter simultanément sur le même chemin d accès. 135 Si vous utilisez des captures instantanées SQL Server pour le déploiement de contenu, chaque chemin d accès crée une capture instantanée, ce qui accroît les besoins en termes d opérations

136 Limite Valeur maximale Type de limite Remarques d E/S pour la base de données source. Pour plus d informations, voir À propos des chemins d accès et travaux de déploiement. Limites des blogs Le tableau suivant répertorie les recommandations pour les blogs. Limite Valeur maximale Type de limite Remarques Billets de blog par site Prise en charge Le nombre maximal de billets de blog est de par site. Commentaires par billet Prise en charge Le nombre maximal de commentaires est de par billet. Limites de Business Connectivity Services Le tableau suivant répertorie les recommandations pour Business Connectivity Services. Limite Valeur maximale Type de limite Remarques Type de contenu externe (en mémoire) par serveur Web (par locataire) Frontière Nombre total de définitions de type de contenu externe 136

137 Limite Valeur maximale Type de limite Remarques 137 chargées en mémoire à un moment donné sur un serveur Web. Connexions au système externe 500 par serveur Web Frontière Nombre de connexions au système externe actives/ouvertes à un moment donné. La valeur par défaut maximale est 200 ; la frontière est 500. Cette limite est imposée au niveau de l étendue du serveur Web, indépendamment du type de système externe (par exemple, base de données, assembly.net, etc.). La valeur par défaut maximale permet de restreindre le nombre de connexions. Une application peut spécifier une limite plus élevée via le contexte d exécution ; la frontière applique alors la valeur maximale même si

138 Limite Valeur maximale Type de limite Remarques Éléments de base de données retournés par demande l application ne respecte pas la valeur par défaut par connecteur de base de données Seuil Nombre d éléments par demande pouvant être retournés par le connecteur de base de données La valeur par défaut maximale de permet au connecteur de base de données de restreindre le nombre de résultats pouvant être renvoyés par page. L application peut spécifier une limite plus élevée via le contexte d exécution ; la valeur maximale absolue applique la valeur maximale même si l application ne respecte pas la valeur par défaut. La frontière pour cette limite est de

139 Limites du flux de travail Le tableau suivant répertorie les recommandations pour le flux de travail. Limite Valeur maximale Type de limite Remarques Seuil d ajournement des activations des flux de du travail 15 Seuil Le nombre maximal de flux de travail pouvant s exécuter simultanément par rapport à une base de données de contenu est de 15, à l exclusion des instances en cours d exécution dans le service du minuteur. Lorsque ce seuil est atteint, les nouvelles demandes d activation de flux de travail sont mises en file d attente en vue de leur exécution ultérieure par le service du minuteur de flux de travail. Au fil de l exécution d opérations ne relevant pas du minuteur, les nouvelles demandes sont comptabilisées 139

140 Limite Valeur maximale Type de limite Remarques 140 par rapport à ce seuil. Vous pouvez configurer cette limite à l aide de l applet de commande Windows PowerShell Set- SPFarmConfig. Pour plus d informations, voir Set- SPFarmConfig. Remarque : cette limite ne fait pas référence au nombre total d instances de flux de travail éventuellement en cours d exécution. En fait, il s agit du nombre d instances en cours de traitement. L augmentation de cette limite accroît le débit des démarrages et des achèvements des tâches de flux de travail, mais accentue également la charge qui pèse sur la base de données de contenu et sur les

141 Limite Valeur maximale Type de limite Remarques ressources système. Taille de lot du minuteur de flux de travail 100 Seuil Nombre d événements que chaque exécution du travail du minuteur de flux de travail sélectionne et fournit aux flux de travail. Vous pouvez configurer ce nombre à l aide de Windows PowerShell. Pour autoriser des événements supplémentaires, vous pouvez exécuter des instances supplémentaires du service du minuteur de flux de travail Microsoft SharePoint Foundation. Limites des magasins de termes (bases de données) de métadonnées gérées Le tableau suivant répertorie les recommandations pour les magasins de termes (bases de données) de métadonnées gérées. 141

142 Limite Valeur maximale Type de limite Remarques Nombre maximal de niveaux de termes imbriqués dans un magasin de termes Nombre maximal d ensembles de termes dans un magasin de termes Nombre maximal de termes dans un ensemble de termes 7 Prise en charge Prise en charge Prise en charge Les termes d un ensemble de termes peuvent être représentés de façon hiérarchique. Un ensemble de termes peut comporter jusqu à sept niveaux de termes (un terme parent et six niveaux d imbrication inférieurs.) Un magasin de termes peut contenir jusqu à ensembles de termes. Le nombre maximal de termes dans un ensemble de termes est de Remarque : Une étiquette supplémentaire pour un terme donné, telle qu un synonyme ou une traduction, n est pas décomptée comme un terme. Nombre total d éléments dans un magasin de termes Prise en charge Un élément est un terme ou un ensemble de termes. La somme du nombre de termes et du nombre d ensembles de termes ne peut pas être supérieure à Une étiquette supplémentaire pour un terme donné, telle qu un synonyme ou une traduction, n est pas décomptée comme un terme. 142 Remarque : Un magasin de termes ne peut pas contenir

143 Limite Valeur maximale Type de limite Remarques simultanément le nombre maximal d ensembles de termes et le nombre maximal de termes. Limites de Visio Services Le tableau suivant répertorie les recommandations pour les instances de Visio Services dans Microsoft SharePoint Server Limite Valeur maximale Type de limite Remarques Taille de fichier des dessins Web Visio 50 Mo Seuil Visio Services possède un paramètre de configuration qui permet à l administrateur de modifier la taille maximale des dessins Web traités par Visio. Les grandes tailles de fichier entraînent les effets secondaires suivants : augmentation de l encombrement mémoire de Visio Services ; augmentation de l utilisation de l UC ; réduction du nombre de demandes par seconde adressées au serveur d applications ; augmentation de la latence globale ; augmentation de la charge réseau des batteries de serveurs SharePoint. Délai d expiration pour le recalcul des dessins Web Visio 120 secondes Seuil Visio Services possède un paramètre de configuration qui permet à l administrateur de 143

144 Limite Valeur maximale Type de limite Remarques modifier la durée maximale à consacrer au recalcul d un dessin après une actualisation des données. Un délai d attente élevé pour le recalcul entraîne les effets suivants : réduction de la disponibilité de l UC et de la mémoire ; réduction du nombre de demandes par seconde adressées à l'application ; augmentation de la latence moyenne dans tous les documents. Un délai d attente réduit pour le recalcul entraîne les effets suivants : réduction de la complexité des diagrammes pouvant être affichés ; augmentation des demandes par seconde ; diminution de la latence moyenne dans tous les documents. Âge minimum du cache Visio Services (diagrammes liés aux données) Âge minimum du cache : 0 à 24 heures Seuil L âge minimum du cache s applique aux diagrammes liés aux données. Il détermine le point le plus tôt auquel le diagramme actuel peut être supprimé du cache. La définition de l âge minimum du cache sur une valeur très petite entraîne une réduction du débit et une augmentation de la latence, car une invalidation trop fréquente du cache oblige Visio à procéder à de fréquents recalculs et à réduire la 144

145 Limite Valeur maximale Type de limite Remarques disponibilité de l UC et de la mémoire. Âge maximum du cache Visio Services (diagrammes non liés aux données) Âge maximum du cache : 0 à 24 heures Seuil L âge maximum du cache s applique aux diagrammes non liés aux données. Cette valeur détermine la durée de conservation du diagramme actuel en mémoire. L augmentation de l âge maximum du cache diminue la latence pour les dessins couramment demandés. Toutefois, la définition de l âge maximum du cache sur une valeur très élevée augmente la latence et ralentit le débit pour les éléments qui ne sont pas mis en cache, car les éléments se trouvant déjà dans le cache consomment et réduisent la mémoire disponible. Limites de PerformancePoint Services Le tableau suivant répertorie les recommandations pour PerformancePoint Services dans Microsoft SharePoint Server Limite Valeur maximale Type de limite Remarques Cellules par requête sur une source de données Excel Services Frontière Une carte de performance PerformancePoint qui appelle une source de données Excel 145

146 Limite Valeur maximale Type de limite Remarques Services est soumise à une limite absolue de cellules par requête. Colonnes et lignes 15 colonnes par lignes Seuil Nombre maximal de colonnes et de lignes lors du rendu d un objet de tableau de bord PerformancePoint qui utilise un classeur Microsoft Excel comme source de données. Le nombre de lignes peut changer en fonction du nombre de colonnes. Requête sur une liste SharePoint 15 colonnes par lignes Prise en charge Nombre maximal de colonnes et de lignes lors du rendu d un objet de tableau de bord PerformancePoint qui utilise une liste SharePoint comme source de données. Le nombre de lignes peut changer en fonction du nombre de colonnes. Requête sur une source de données SQL Server 15 colonnes par lignes Prise en charge Nombre maximal de colonnes et de lignes lors du rendu d un objet de tableau de bord 146

147 Limite Valeur maximale Type de limite Remarques PerformancePoint qui utilise une table SQL Server comme source de données. Le nombre de lignes peut changer en fonction du nombre de colonnes. Limites de Word Automation Services Le tableau suivant répertorie les recommandations pour Word Automation Services. Limite Valeur maximale Type de limite Remarques Taille du fichier d entrée 512 Mo Frontière Taille de fichier maximale pouvant être traitée par Word Automation Services. Fréquence d exécution des conversions (en minutes) 1 minute (fréquence recommandée) 15 minutes (fréquence par défaut) 59 minutes (frontière) Seuil Ce paramètre détermine la fréquence d exécution du travail du minuteur Word Automation Services. Plus le nombre est petit, plus le travail du minuteur s exécute rapidement. Nos tests montrent que la fréquence d exécution idéale de ce travail du minuteur est d une fois par minute. Nombre de conversions à démarrer par processus de conversion Pour les formats de sortie PDF/XPS : Seuil 30 x M ; pour tous les autres formats de sortie : 72 x M Où M est la valeur de la fréquence à laquelle démarrer les conversions (en minutes) 147 Le nombre de conversions à démarrer a une incidence sur le débit de Word Automation Services. Si ces valeurs sont définies à des niveaux supérieurs aux niveaux recommandés, certains éléments de conversion risquent de commencer à

148 Limite Valeur maximale Type de limite Taille des travaux de conversion éléments de conversion Prise en charge Nombre total de processus de conversion actifs N-1, où N représente le nombre de cœurs sur chaque serveur d applications 148 Seuil Remarques échouer par intermittence et les autorisations utilisateur risquent d arriver à expiration. Les autorisations utilisateur expirent 24 heures après le démarrage d un travail de conversion. Un travail de conversion comprend un ou plusieurs éléments de conversion, représentant chacun une conversion unique à exécuter sur un fichier d entrée spécifique dans SharePoint. Lorsqu un travail de conversion est démarré (à l aide de la méthode ConversionJob.Start), ce dernier et tous les éléments de conversion sont transmis à un serveur d applications qui stocke le travail dans la base de données Word Automation Services. Plus le nombre d éléments de conversion est élevé, plus la durée d exécution de la méthode Start est longue et plus le nombre d octets transmis au serveur d applications est élevé. Un processus de conversion actif peut consommer un cœur de traitement. Par conséquent, les clients ne doivent pas exécuter plus de processus de conversion qu il n existe de cœurs de traitement dans leurs serveurs d applications. Le travail du minuteur de conversion et les autres activités SharePoint nécessitent également le recours occasionnel à un cœur de traitement. Il est recommandé de laisser toujours un cœur disponible pour le travail du minuteur de

149 Limite Valeur maximale Type de limite Taille de la base de données Word Automation Services 2 millions d éléments de conversion Prise en charge Remarques conversion et SharePoint. Word Automation Services gère une file d attente permanente d éléments de conversion dans sa base de données. Chaque demande de conversion génère un ou plusieurs enregistrements. Étant donné que Word Automation Services ne dispose pas d une fonctionnalité lui permettant de supprimer automatiquement des enregistrements de la base de données, celle-ci peut croître indéfiniment sans opération de maintenance. Les administrateurs peuvent supprimer manuellement l historique des travaux de conversion à l aide de l applet de commande Windows PowerShell Remove-SPWordConversionServiceJobHistory. Pour plus d informations, voir Remove- SPWordConversionServiceJobHistory. Limites de SharePoint Workspace Le tableau suivant répertorie les recommandations pour Microsoft SharePoint Workspace Limite Valeur maximale Type de limite Remarques Synchronisation SharePoint Workspace éléments par liste Frontière SharePoint Workspace ne synchronise pas les listes qui contiennent plus de 149

150 Limite Valeur maximale Type de limite Remarques Synchronisation SharePoint Workspace Limite de documents dans SharePoint Workspace Frontière éléments. En effet, le temps nécessaire pour télécharger une liste qui contient plus de éléments est très long et implique une utilisation élevée des ressources. Les utilisateurs sont avertis dès qu ils possèdent plus de 500 documents dans SharePoint Workspace, mais ils peuvent continuer à en ajouter. Limites de OneNote Le tableau suivant répertorie les recommandations pour Microsoft OneNote Services. Limite Valeur maximale Type de limite Remarques Nombre de sections et de groupes de Voir la limite pour les documents dans les sections dans un bloc-notes OneNote (sur limites de liste et de bibliothèque SharePoint) 150 Chaque section représente un dossier et un document dans la liste. Il en va de même pour chaque groupe de sections. Taille maximale d une section Voir la limite pour la taille de fichier dans Cette valeur maximale exclut les

151 Limite Valeur maximale Type de limite Remarques les limites de liste et de bibliothèque images, les fichiers incorporés et les impressions XPS vers OneNote dont la taille est supérieure à 100 Ko. Les images et les fichiers incorporés dont la taille est supérieure à 100 Ko sont scindés en fichiers binaires spécifiques. Cela signifie qu une section contenant 100 Ko de données tapées et quatre documents Word incorporés ayant chacun une taille de 1 Mo est considérée comme une section de 100 Ko. Taille maximale d une image, d un fichier incorporé et d une impression XPS OneNote dans une section OneNote. Voir la limite pour la taille de fichier dans les limites de liste et de bibliothèque Chaque élément est stocké sous la forme d un fichier binaire distinct et, par conséquent, est soumis à des tailles limites de fichier. Chaque opération d impression vers OneNote aboutit à un fichier binaire d impression XPS, même si l impression contient plusieurs pages. Taille maximale de la totalité des images, La limite par défaut est le double de la des fichiers incorporés et des impressions limite «Taille des fichiers». XPS dans une même page OneNote. 151 Seuil Cela concerne le contenu incorporé dans une seule page OneNote, pas une section ou un bloc-notes. Si les utilisateurs sont confrontés à ce seuil, ils obtiennent le message d erreur suivant dans OneNote : jerrcstorageurl_hottablefull (0xE ). Les utilisateurs peuvent contourner ce problème en fractionnant le contenu incorporé en

152 Limite Valeur maximale Type de limite Remarques différentes pages et en supprimant les versions antérieures de la page. Si les utilisateurs doivent ajuster cette valeur («Taille maximale de table à chaud»), la limite effective est la moitié de la valeur absolue qu ils définissent (par exemple, la spécification d une taille maximale de table à chaud de 400 Mo signifie que la taille maximale de tout le contenu incorporé sur une page est limitée à 200 Mo). Opérations de fusion Une par cœur d UC et par serveur Web Frontière Les fusions OneNote combinent les modifications apportées par plusieurs utilisateurs lors de la co-création d un bloc-notes. Si aucun cœur d UC n est disponible pour exécuter une fusion, une page conflictuelle est générée, ce qui oblige l utilisateur à effectuer la fusion manuellement). Cette limite s applique, que OneNote s exécute en tant qu application cliente ou que Microsoft Office Web Apps. Limites des services d application Web Office Le tableau suivant répertorie les recommandations pour Office Web Apps. Les limites des applications clientes Office s appliquent également lorsqu une application s exécute en tant qu application Web. 152

153 Limite Valeur maximale Type de limite Remarques Taille du cache 100 Go Seuil Espace disponible pour le rendu des documents, créé dans le cadre d une base de données de contenu. Par défaut, le cache disponible pour restituer les documents est de 100 Go. Il n est pas recommandé d augmenter la taille du cache disponible. Rendus Un par document, seconde, cœur d UC et serveur d applications (maximum huit cœurs) Frontière Il s agit du nombre moyen mesuré de rendus de documents «classiques» pouvant être réalisés sur le serveur d applications pendant une période de temps. 153

154 Limites de Project Server Le tableau suivant répertorie les recommandations pour Microsoft Project Server. Pour plus d informations sur la planification de Project Server, voir Planning and architecture for Project Server Limite Valeur maximale Type de limite Remarques Fin du temps de projet Date : 31/12/2049 Frontière Les plans Project ne peuvent pas s étendre au-delà de la date du 31/12/2049. Livrables par plan de projet livrables Frontière Les plans Project ne peuvent pas contenir plus de livrables. Nombre de champs dans un affichage 256 Frontière Un utilisateur ne peut pas ajouter plus de 256 champs à un affichage qu il a défini dans Project Web App. Nombre de clauses dans un filtre pour un affichage 50 Frontière Un utilisateur ne peut pas ajouter un filtre à un affichage qui contient plus de 50 clauses. 154

155 Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) This section contains technical case studies that describe specific deployments of Microsoft SharePoint Server Compare the scenarios in these documents to your planned workload and usage characteristics. If your planned design is similar, you can use the documented deployment as a starting point for your own installation. These articles include information about environments, such as: Environment specifications, such as hardware, farm topology, and configuration The workload used for data generation, including the number and class of users, and farm usage characteristics Farm dataset, including database contents, Search indexes, and external data sources Health and performance data specific to the environment Performance data and recommendations for how to determine the hardware, topology, and configuration you need to deploy a similar environment, and how to optimize your environment for appropriate capacity and performance characteristics Before reading these articles, it is important that you understand the key concepts behind capacity management in SharePoint Server For more information, see Capacity management and sizing for SharePoint Server 2010 (en anglais). In this section: Publishing Environnement de publication intranet d entreprise Microsoft SharePoint Server 2010 : étude de cas technique Describes the published intranet environment used by employees at Microsoft. Enterprise Intranet Collaboration Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais) Describes an environment that hosts mission-critical team sites and publishing portals for internal organizations, teams, and projects. Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en anglais) 155

156 Describes lab testing performed on a similar environment to the enterprise Intranet collaboration environment. Departmental Collaboration Social Departmental collaboration environment technical case study (SharePoint Server 2010) (en anglais) Describes a departmental collaboration environment used by employees of one department inside Microsoft. Divisional portal environment lab study (SharePoint Server 2010) (en anglais) Describes lab testing performed on a similar environment to the departmental collaboration environment. Social environment technical case study (SharePoint Server 2010) (en anglais) Describes an environment that hosts My Sites that present employee information to the wider organization. The environment serves as a central location for personal sites and shared documents. Microsoft SharePoint Server 2010 social environment: Lab study Provides guidance on performance and capacity planning for a My Site and social computing portal based on SharePoint Server

157 Environnement de publication intranet d entreprise Microsoft SharePoint Server 2010 : étude de cas technique Ce document décrit un déploiement spécifique de Microsoft SharePoint Server 2010, notamment les aspects suivants : Caractéristiques de l environnement d étude de cas technique, notamment en matière de matériel, de topologie et de configuration de la batterie de serveurs Charge de travail, notamment le nombre et les types d utilisateurs ou de clients et les caractéristiques d utilisation de l environnement Ensemble de données de la batterie de serveurs de l étude de cas technique, qui inclut le contenu des bases de données et les index de recherche Données de performances et d intégrité spécifiques à l environnement Dans cet article : Informations préalables requises Introduction à cet environnement Spécifications Charge de travail Ensemble de données Données de performances et d intégrité Informations préalables requises Avant de lire ce document, assurez-vous de comprendre les concepts principaux sous-jacents à la gestion de la capacité de SharePoint Server La documentation suivante vous explique l approche recommandée pour la gestion de la capacité et fournit un contexte pour vous aider à comprendre comment utiliser efficacement ces informations ; elle définit également les termes utilisés dans ce document. 157

158 Pour des informations plus conceptuelles sur les performances et la capacité qui peuvent vous aider à comprendre le contexte des données de cette étude de cas technique, consultez les documents suivants : Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Introduction à cet environnement Ce livre blanc décrit un environnement SharePoint Server 2010 réel mis en place chez Microsoft. Utilisez-le pour faire la comparaison avec vos caractéristiques d utilisation et de charge de travail planifiées. Si la conception que vous avez planifiée est similaire, vous pouvez utiliser le déploiement décrit ici comme point de départ pour votre propre installation. Ce document comprend les rubriques suivants : Spécifications, incluant le matériel, la topologie et la configuration Charge de travail, qui correspond à la demande sur la batterie de serveurs, notamment le nombre d utilisateurs et les caractéristiques d utilisation Ensemble de données qui inclut les tailles des bases de données Intégrité et performances spécifiques à l environnement Ce document fait partie d une série d Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) sur les environnements SharePoint chez Microsoft. 158

159 L environnement SharePoint Server 2010 décrit dans ce document est un environnement de production d une entreprise de grande taille, géographiquement distribuée. Les employés affichent divers contenus, tels que des actualités, des articles techniques, des profils d employés, de la documentation et des ressources de formation. Les employés utilisent également cet environnement pour exécuter des requêtes de recherche sur tous les environnements SharePoint au sein de la société. Les employés reçoivent des messages électroniques quotidiens avec des liens vers les articles correspondants dans l environnement et beaucoup définissent cet environnement comme page d accueil de leur navigateur. Jusqu à utilisateurs uniques visitent l environnement lors d une journée occupée, générant jusqu à 345 demandes par seconde (RPS) aux heures de pointe. Dans la mesure où il s agit d un site intranet, tous les utilisateurs sont authentifiés. Bien que le contenu soit publié en utilisant un modèle unique d auteur sur place de l environnement, la procédure de publication de l environnement spécifie que tout le contenu de projet est publié à un seul moment pendant la nuit dans les heures creuses. Les informations fournies dans ce document reflètent l environnement de publication intranet de l entreprise pendant une journée normale. Spécifications Cette section fournit des informations détaillées sur le matériel, le logiciel, la topologie et la configuration de l environnement de l étude de cas. Matériel 159

160 Cette section fournit des détails sur les ordinateurs serveurs utilisés dans cet environnement. Remarque : Cet environnement est ajusté pour accueillir des versions précommerciales de SharePoint Server 2010 et d autres produits. Par conséquent, le matériel déployé a une capacité plus grande que nécessaire pour répondre à la demande habituellement rencontrée par cet environnement. Ce matériel est décrit uniquement pour fournir un contexte supplémentaire à cet environnement et servir de point de départ pour des environnements similaires. Il est important de mener votre propre gestion de la capacité en fonction de vos caractéristiques d utilisation et de charge de travail planifiées. Pour plus d informations sur le processus de gestion de la capacité, voir Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Serveurs Web Il existe quatre serveurs Web dans la batterie de serveurs, chacun avec un matériel identique. Trois servent du contenu et le quatrième est une cible d analyse dédiée à la recherche. Serveur Web Processeur(s) RAM Système d exploitation Taille du lecteur SharePoint WFE1-4 2 quadri-cœurs à 2,33 GHz 32 Go Windows Server 2008, 64 bits 300 Go Nombre de cartes réseau 2 Vitesse de carte réseau Authentification Type d équilibrage de la charge 1 Gigabit Windows NTLM Équilibrage matériel de la charge 160

161 Serveur Web Version logicielle Services s exécutant localement Services consommés à partir d une batterie de serveurs de services fédérés WFE1-4 SharePoint Server 2010(version préliminaire) Administration centrale Courrier électronique entrant Microsoft SharePoint Foundation Application Web Microsoft SharePoint Foundation Service du minuteur de flux de travail Microsoft SharePoint Foundation Service de requête de recherche et de paramètres de site SharePoint Server Search Service de profil utilisateur Service Web de Web Analytics Service Business Data Connectivity Service Web de métadonnées gérées Serveur d applications La batterie de serveurs ne contient aucun serveur d applications. Les services locaux sont hébergés sur les serveurs Web. Les autres services sont consommés à partir d une batterie de serveurs de services fédérés. Serveurs de bases de données Il y a un cluster SQL avec deux serveurs de bases de données, chacun avec un matériel identique. Un des serveurs est actif et l autre est passif pour assurer la redondance. Serveur de bases de données Processeur(s) RAM DB1-2 4 quadri-cœurs à 2,4 GHz 32 Go 161

162 Serveur de bases de données Système d exploitation Stockage et géométrie DB1-2 Windows Server 2008, 64 bits (1,25 To * 6) + 3 To Disques 1 à 4 : données SQL Disque 5 : journaux Disque 6 : base de données TempDB Nombre de cartes réseau 2 Vitesse de carte réseau Authentification 1 Gigabit Windows NTLM Version logicielle SQL Server 2008 Topologie Le diagramme suivant présente la topologie de cette batterie de serveurs. 162

163 163

164 Configuration Le tableau suivant énumère les paramètres qui ont été modifiés et qui affectent les performances ou la capacité de l environnement. Paramètre Valeur Remarques Administration de la collection de sites : Cache de sortie de la collection de sites Activé L activation du cache de sortie améliore l efficacité du serveur en réduisant les appels à la base de données pour les données fréquemment demandées. Profil de cache de la collection de sites (sélection) Intranet (site de collaboration) L option «Autoriser les auteurs à afficher le contenu en cache» est activée, contournant le comportement normal d empêcher la mise en cache des pages des personnes ayant des autorisations de modification. Cache d objets (désactivé n Mo) Service d utilisation : Journal de suivi jours de stockage des journaux (par défaut : 14) Seuil de connexion de requête : Base de données Microsoft SharePoint Foundation configurer QueryLoggingThreshold à 1 seconde Serveur de base de données Instance par défaut : activé 500 Mo La valeur par défaut est 100 Mo. L augmentation de ce paramètre permet le stockage de données supplémentaires dans la mémoire du serveur Web frontal. 5 jours La valeur par défaut est 14 jours. La réduction de ce paramètre peut économiser l espace disque sur le serveur où se trouvent les fichiers journaux. 1 seconde La valeur par défaut est 5 secondes. La réduction de ce paramètre peut économiser la bande passante et l UC sur le serveur de bases de données. 1 La valeur par défaut est 0. Pour garantir des performances optimales, nous recommandons fortement de définir le degré maximal de parallélisme à 1 pour les serveurs de bases de données hébergeant des bases de données SharePoint 164

165 Paramètre Valeur Remarques Degré max de parallélisme Server Pour savoir comment définir le degré maximal de parallélisme, voir Option Degré maximal de parallélisme( Charge de travail Cette section décrit la charge de travail, qui correspond à la demande sur la batterie de serveurs, notamment le nombre d utilisateurs et les caractéristiques d utilisation. Caractéristiques de la charge de travail Valeur Moyenne de demandes par seconde (RPS) 100 Moyenne RPS en heure de pointe (11:00-15:00) 226 Nombre total d utilisateurs uniques par jour Nombre moyen d utilisateurs simultanés 172 Nombre maximum d utilisateurs simultanés 376 Nombre total de demandes par jour Ce tableau indique le nombre de demandes pour chaque agent utilisateur. Agent utilisateur Demandes Pourcentage du total Navigateur ,09 % 165

166 Agent utilisateur Demandes Pourcentage du total DAV ,07 % Recherche (analyse) ,75 % OneNote ,05 % Outlook 961 0,03 % Word 449 0,01 % Ensemble de données Cette section décrit l ensemble de données de la batterie de serveurs de l étude de cas, notamment les tailles des bases de données et les index de recherche. Caractéristiques de l ensemble de données Taille des bases de données (combinée) Taille du BLOB Valeur 49,9 Go 22,2 Go Nombre de bases de données de contenu 3 Nombre d applications Web 3 Nombre de collections de sites 4 Nombre de sites 797 Taille d index de recherche (nombre d éléments)

167 Données de performances et d intégrité Cette section fournit les données d intégrité et de performances spécifiques à l environnement de l étude de cas. Compteurs d ordre général Mesure Valeur Disponibilité (temps de fonctionnement) 99,95 % Taux d échec 0,05 % Moyenne de mémoire utilisée Maximum de mémoire utilisée Analyse de recherche en % du trafic (demandes de recherche des clients/nombre total de demandes) 1,08 Go 2,60 Go 6 % Requêtes ASP.NET en file d attente 0,00 Les graphiques suivants montrent l utilisation moyenne de l UC et la latence pour cet environnement. 167

168 168

169 Dans ce document, la latence est divisée en quatre catégories. La latence 50ème centile est généralement utilisée pour mesurer le temps de réponse du serveur. Cela signifie que la moitié des demandes sont prises en charge dans ce délai de réponse. La latence 95ème centile est généralement utilisée pour mesurer les pics dans les temps de réponse du serveur. Cela signifie que 95 % des demandes sont prises en charge dans ce délai de réponse et par conséquent, 5 % des demandes obtiennent des temps de réponse plus lents. Compteurs de base de données Pour interpréter les statistiques de base de données dans cet environnement de publication d entreprise, sachez que la plupart des visiteurs disposent des autorisations de lecture seule. Mesure Valeur Ratio de lecture/écriture (E/S par base de données) 99,999 : 0,

170 Mesure Valeur Longueur moyenne de file d attente de disque 0,35 Longueur de file d attente de disque : lectures 34 Longueur de file d attente de disque : écritures 2,5 Lectures disque/s 131,33 Écritures disque/s 278,33 Compilations SQL/seconde 2,36 Recompilations SQL/seconde 94,80 Verrous SQL : Temps d attente moyen Verrous SQL : Temps d attente de verrouillage 0 ms 0 ms Verrous SQL : blocages par seconde 0 Verrous internes SQL : Temps d attente moyen 0,25 ms Taux de présence en cache SQL >99 % 170

171 Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais) This article describes a specific deployment of Microsoft SharePoint Server 2010, that includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration. The workload, that includes the number, and types, of users or clients, and environment usage characteristics. Technical case study farm dataset, that includes database contents and search indexes. Health and performance data that is specific to the environment. In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 171

172 Capacity management and sizing for SharePoint Server 2010 (en anglais) Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare to your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology, and configuration. Workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Dataset that includes database sizes. Health and performance data that is specific to the environment. This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) about SharePoint environments at Microsoft. 172

173 The SharePoint environment described in this document is a production environment at a large, geographically distributed company. The environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams, and projects. Sites created in this environment are used as communication portals, applications for business solutions, and general collaboration. Self-service site creation is used to provision site collections. Custom code is not permitted. As many as 88,900 unique users visit the environment on a busy day, generating up to 669 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the enterprise intranet publishing environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case study environment. Hardware This section provides details about the server computers that were used in this environment. Remarque : This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Capacity management and sizing for SharePoint Server 2010 (en anglais). Web Servers There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl target. Web Server Processor(s) WFE1-4 2 quad 2.33 GHz 173

174 Web Server RAM OS WFE GB Windows Server 2008, 64 bit Size of the SharePoint drive 205 GB Number of network adapters 2 Network adapter speed 1 Gigabit Authentication Windows NTLM Load balancer type Hardware load balancing Software version SharePoint Server 2010 (pre-release version) Services running locally Services consumed from a federated Services farm Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search User Profile Service Web Analytics Web Service Business Data Connectivity Service Managed Metadata Web Service Application Server There are four application servers in the farm, each with identical hardware. 174

175 Application Server Processor(s) RAM OS Size of the SharePoint drive APP1-4 4 six 2.40 GHz 64 GB Windows Server 2008, 64 bit 300 GB Number of network adapters 1 Network adapter speed Authentication Load balancer type Software version Services running locally 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Office Web Apps Excel PowerPoint Secure Store Usage and Health State Service Database Servers There is a SQL cluster with 2 database servers, each with identical hardware, one of the servers is active and the other is passive for redundancy. 175

176 Database Server Processor(s) RAM OS DB1-2 4 quad 2.4 GHz 32 GB Windows Server 2008, 64-bit Storage and geometry Number of network adapters 2 Network adapter speed Authentication (1.25 TB * 7) + 3 TB Disk 1-4: SQL Data Disk 5: Logs Disk 6: TempDB 1 Gigabit Windows NTLM Software version SQL Server 2008 Topology The following diagram shows the topology for this farm. 176

177 177

178 Configuration The following table enumerates settings that were changed that affect performance or capacity in the environment. Setting Value Notes Usage Service Trace Log days to store log files (default: 14 days) 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. QueryLoggingThreshold SharePoint Foundation Database change QueryLoggingThreshold to 1 second 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. Database Server Default Instance Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS) 157 Average RPS at peak time (11 AM-3 PM) 350 Total number of unique users per day 69,

179 Workload Characteristics Value Average concurrent users 420 Maximum concurrent users 1,433 Total # of requests per day 18,866,527 This table shows the number of requests for each user agent. User Agent Requests Percentage of Total Search (crawl) 6,384,488 47% DAV 2,446,588 18% Browser 730,139 5% OneNote 665,334 5% Office Web Applications 391,599 3% SharePoint Designer 215,695 2% Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Database size (combined) BLOB size Value 7.5 TB 6.8 TB 179

180 Dataset Characteristics Value Number of content databases 87 Number of Web applications 2 Number of site collections 34,423 Number of sites 101,598 Search index size (number of items) 23 million Health and Performance Data This section provides health and performance data that is specific to the Case Study environment. General Counters Metric Value Availability (uptime) 99.1% Failure Rate 0.9% Average memory used 3.4 GB Maximum memory used 16.1 GB Search Crawl % of Traffic (Search client requests / total requests) 47% ASP.NET Requests Queued 0.00 The following charts show the average CPU utilization and latency for this environment: 180

181 181

182 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore 5% of the requests experience slower response times. Database counters Metric Value Read/Write Ratio (IO Per Database) 99.8 : 0.2 Average Disk queue length 2.3 Disk Queue Length: Reads 2 182

183 Metric Value Disk Queue Length: Writes 0.3 Disk Reads/sec Disk Writes/sec SQL Compilations/second 9.9 SQL Re-compilations/second 0.07 SQL Locks: Average Wait Time 225 ms SQL Locks: Lock Wait Time 507 ms SQL Locks: Deadlocks Per Second 3.8 SQL Latches: Average Wait Time 14.3 ms SQL Server: Buffer Cache Hit Ratio 74.3% 183

184 Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en anglais) This article contains guidance on performance and capacity planning for an enterprise intranet collaboration solution that is based on Microsoft SharePoint Server It includes the following: Lab environment specifications, such as hardware, farm topology and configuration Test farm dataset Test results analysis which should help you determine the hardware, topology and configuration that you must have to deploy a similar environment, and optimize your environment for appropriate capacity and performance characteristics In this article: Introduction to this environment Glossary Overview Specifications Results and Analysis Introduction to this environment This document provides guidance about scaling out and scaling up servers in a SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing environment at Microsoft. Capacity planning informs decisions on purchasing hardware and making system configurations to optimize your solution. Different scenarios have different requirements. Therefore, it is important to supplement this guidance with additional testing on your own hardware and in your own environment. If your planned design and workload resembles the environment described in this document, you can use this document to draw conclusions about scaling your environment up and out. This document includes the following: 184

185 Specifications, which include hardware, topology, and configuration The workload, which is the demand on the farm, includes the number of users, and the usage characteristics The dataset, such as database sizes Test results and analysis for scaling out Web servers Test results and analysis for scaling up Web servers Test results and analysis for scaling out database servers Comparison between Microsoft Office SharePoint Server 2007 and SharePoint Server 2010 about throughput and effect on the web and database servers The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large company. The production environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams, and projects. Employees use that production environment to track projects, collaborate on documents, and share information within their organization. The environment includes a large amount of small sites used for ad-hoc projects and small teams. For details about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais). Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Also, we encourage you to read the following: Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions. RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of server and farm load. 185

186 Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements. Green Zone: This is the state at which the server can maintain the following set of criteria: The server-side latency for at least 75% of the requests is less than 1 second. All servers have a CPU Utilization of less than 50%. Remarque : Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search crawl load to 10% CPU. Failure rate is less than 0.01%. Red Zone (Max): This is the state at which the server can maintain the following set of criteria: HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned. Failure rate is less than 0. 1%. The server-side latency is less than 3 seconds for at least 75% of the requests. Database server CPU utilization is less than 80%, which allows for 10% to be reserved for the Search crawl load, limited by using SQL Server Resource Governor. AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For example, 8x1x2 means that this environment has 8 Web servers, 1 application server, and 2 database servers. MDF and LDF: SQL Server physical files. For more information, see Files and Filegroups Architecture. Overview This section provides an overview to our scaling approach, to the relationship between this lab environment and a similar case study environment, and to our test methodology. Scaling approach 186

187 This section describes the specific order that we recommend for scaling servers in your environment, and is the same approach we took for scaling this lab environment. This approach will enable you to find the best configuration for your workload, and can be described as follows: First, we scaled out the Web servers. These were scaled out as far as possible under the tested workload, until the database server became the bottleneck and was unable to accommodate any more requests from the Web servers. Second, we scaled out the database server by moving half of the content databases to another database server. At this point, the Web servers were not creating sufficient load on the database servers. Therefore, they were scaled out additionally. In order to test scale up, we tried another option which is scaling up the Web servers instead of scaling them out. Scaling out the Web servers is generally preferred over scaling them up because scaling out provides better redundancy and availability. Correlating the lab environment with a production environment The lab environment outlined in this document is a smaller scale model of a production environment at Microsoft, and although there are significant differences between the two environments, it can be useful to examine them side by side because both are enterprise collaboration environments where the patterns observed should be similar. The lab environment contains a subset of the data from the production environment, and also some modifications to the workload. This influences the test results with regard to Web server memory usage, because the object cache on the production environment receives a larger amount of hits on unique sites, and therefore uses more memory. The lab environment also has less data, and most of it is cached in memory as opposed to the production environment which carries over seven terabytes of data, so that the database server on the production environment is required to perform more disk reads than the database server in the lab environment. Similarly, the hardware that was used in the lab environment is significantly different from the production environment it models, because there is less demand on those resources. The lab environment relies on more easily available hardware. To get a better understanding of the differences between the environments, read the Specifications section in this document, and compare it to the specifications in the Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais). Methodology and Test Notes This document provides results from a test lab environment. Because this was a lab environment and not a production environment, we were able to control certain factors to show specific aspects of performance for this workload. In addition, certain elements of the production environment, listed here, were left out of the lab environment to simplify testing overhead. We do not recommend omitting these elements for production environments. Between test runs, we modified only one variable at a time, to make it easy to compare results between test runs. The database servers that were used in this lab environment were not part of a cluster because redundancy was not necessary for the purposes of these tests. 187

188 Search crawl was not running during the tests, whereas it might be running in a production environment. To take this into account, we lowered the SQL Server CPU utilization in our definition of Green Zone and Max to accommodate the resources that a search crawl would have consumed if it were running at the same time with our tests. To learn more about this, read Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Specifications This section provides detailed information about the hardware, software, topology, and configuration of the lab environment. Hardware The following sections describe the hardware that was used in this lab environment. Web and Application servers There are from one to eight Web servers in the farm, plus one Application server. Web Server Processor(s) RAM Operating system Size of the SharePoint drive Number of network adapters 2 Network adapter speed Authentication Load balancer type Services running locally WFE1-8 and APP1 2 quad-core 2.33 GHz processors 8 GB Windows 2008 Server R2 80 GB 1 Gigabit Windows NTLM Windows NLB WFE 1-8: Basic Federated Services. This included the following: Timer Service, Admin Service, and Trace Service. APP1: Word Automation Services, Excel Services and SandBoxed Code 188

189 Web Server WFE1-8 and APP1 Services. Database Servers There are from two to three database servers, up to two running the default SQL Server instance housing the content databases, and one running the logging database. The logging database is not tracked in this document. Remarque : If you enable usage reporting, we recommend that you store the logging database on a separate Logical Unit Number (LUN). For large deployments and some medium deployments, a separate LUN will not be sufficient, as the demand on the server s CPU may be too high. In that case, you will need a separate database server box for the logging database. In this lab environment, the logging database was stored in a separate instance of SQL Server, and its specifications are not included in this document. Database Server Default Instance Processor(s) RAM Operating system Storage and geometry DB1-2 4 dual-core 3.19 GHz processors 32 GB Windows 2008 Server R2 Direct Attached Storage (DAS) Internal Array with 5 x 300GB 10krpm disk External Array with 15 x 450GB 15krpm disk 6 x Content Data (External RAID0, 2 spindles 450GB each) 2 x Content Logs (Internal RAID0, 1 spindle 300GB each) 1 x Temp Data (Internal RAID0, 2 spindles 150GB each) 189

190 Database Server Default Instance Number of network adapters 1 Network adapter speed Authentication Software version DB1-2 1 x Temp Log (Internal RAID0, 2 spindles 150GB each) 2 x Backup drive (Internal RAID0, 1 spindle each, 300GB each) 1 Gigabit Windows NTLM SQL Server 2008 R2 (pre-release version) Topology The following diagram shows the topology in this lab environment: 190

191 191

192 Configuration To allow for the optimal performance, the following configuration changes were made in this lab environment. Setting Value Notes Site Collection Blob Caching On The default is Off. Enabling Blob Caching improves server efficiency by reducing calls to the database server for static page resources that may be frequently requested. Database Server Default Instance Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload The transactional mix for the lab environment described in this document resembles the workload characteristics of a production environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais). Here are the details of the mix for the lab tests run against SharePoint Server 2010 compared to the production environment. Although there are some minor differences in the workloads, both represent a typical transactional mix on an enterprise collaboration environment. 192

193 193

194 Dataset The dataset for the lab environment described in this document is a subset of the dataset from a production environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en anglais). Dataset Characteristics Database size (combined) BLOB size Value 130 GB GB Number of content databases 2 Number of site collections 181 Number of Web applications 1 Number of sites 1384 Results and Analysis The following results are ordered based on the scaling approach described in the Overview section of this document. Web Server Scale Out This section describes the test results that were obtained when we scaled out the number of Web servers in this lab environment. Test methodology Add Web servers of the same hardware specifications, keeping the rest of the farm the same. Measure RPS, latency, and resource utilization. Analysis In our testing, we found the following: 194

195 The environment scaled up to four Web servers per database server. However, the increase in throughput was non-linear especially on addition of the fourth Web server. After four Web servers, there are no additional gains to be made in throughput by adding more Web servers because the bottleneck at this point was the database server CPU Utilization. The average latency was almost constant throughout the whole test, unaffected by the number of Web servers and throughput. Remarque : The conclusions described in this section are hardware specific, and the same throughput might have been achieved by a larger number of lower-end hardware, or a smaller number of higher-end hardware. Similarly, changing the hardware of the database server would affect the results. To get an idea on how much of a difference the hardware of the Web servers can affect these results, see the Web Server Scale Up section. Results graphs and charts In the following graphs, the x axis shows the change in the number of Web servers in the farm, scaling from one Web server (1x1x1) to five Web servers (5x1x1). 1. Latency and RPS The following graph shows how scaling out (adding Web servers) affects latency and RPS. 195

196 2. Processor utilization The following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server. 196

197 3. SQL Server I/O operations per section (IOPs) for MDF and LDF files The following graphs show how the IOPs on the content databases change as the number of Web servers is scaled out. These are measured by looking at the following performance counters: PhysicalDisk: Disk Reads / sec 197

198 PhysicalDisk: Disk Writes / sec In this lab environment, we determined that our data on IOPs was not representative of a production environment because our dataset was so small that we could fit much more of it in cache than would be possible in the production environment we are modeling. We calculated projected reads by multiplying the value of the data we had from the lab for writes/second by the ratio of reads to writes in our production environment. The results in this section are averages. But there are also spikes that occur during certain operations which have to be accounted for. To learn more about how to estimate IOPs needed, see Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010). Maximum: 198

199 Green Zone: Example of how to read these graphs: An organization with a workload similar to that described in this document that expects 300 RPS to be their green zone, could use 3x1x1 topology, and would use approximately 600 Physical Disk reads/sec on the MDF file. Database Server Scale Out This section describes the test results that were obtained when we scaled out the number of database servers in this lab environment. 199

200 Test methodology Have two content databases on one database server, and then split them to two servers to effectively double the processor cores and memory available to the database servers in the environment. Keep the total IOPs capacity constant even while adding a database server. This means that the number of reads/sec and writes/sec that the disks could perform for each content database did not change despite splitting the content onto two database servers instead of one. Analysis The first bottleneck in the 4x1x2 environment was the database server CPU utilization. There was close to a linear scale when we added more processor and memory power. Scaling to four Web servers and 2 database servers did not provide much additional RPS because the CPU utilization on the Web servers was close to 100%. When we scaled out database servers (by adding one additional database server) and added four Web servers, performance scaled almost linearly. The bottleneck at that point shifted from being the database server CPU utilization to the content database disk IOPs. No additional tests were performed in this lab environment to scale out past 8x1x2. However we expect that additional IOPs capacity would additionally increase throughput. A correlation between the IOPs used and the RPS achieved by the tests was observed Results graphs and charts In the following graphs, the x axis is always showing four Web servers together with 1 application server and 1 database server (4x1x1) scaling out to eight Web servers together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2. 1. Latency and RPS The following graph shows how scaling out both Web servers and database servers affects latency and RPS. 200

201 2. Processor utilization The following graphs show how scaling out affects processor utilization. 201

202 3. Memory utilization at scale out Throughout our testing, we ve observed that the larger the number of site collections in an environment, the more the memory consumed. For example, in the tests here where 181 site collections were accessed, the main w3wp process used up 1.8 GB of RAM. For more examples, see the Performance and capacity technical case studies (SharePoint Server 2010) (en anglais). Additional content about memory requirements for increased numbers of site collections is under development. Check back for new and updated content. 202

203 4. SQL Server I/O operations per section (IOPs) for MDF and LDF files The following graphs show how the IOPs change as both the number of Web servers and the number of database servers is scaled out. Maximum RPS 203

204 Green Zone RPS Web server Scale Up This section describes the test results that were obtained when we scaled up the Web servers in this lab environment. Test methodology Add more Web server processors, but keep the rest of the farm the same. Analysis Scale is linear up to eight processor cores. 204

205 Tests show that the environment can take advantage of a twenty-four core box, although there is some degradation as twenty-four cores are approached. Results graphs and charts In the following graph, the x axis is the number of processors and the amount of RAM on the Web server. The following graph shows how scaling up (adding processors) affects RPS on the Web server. 205

206 Comparing SharePoint Server 2010 and Office SharePoint Server 2007 This section provides information about how the capacity testing for this workload varied between SharePoint Server 2010 and Microsoft Office SharePoint Server Workload To compare SharePoint Server 2010 with Office SharePoint Server 2007, a different test mix was used than the one outlined in the Specifications section, because some SharePoint Server 2010 operations were not available in Office SharePoint Server The test mix for Office SharePoint Server 2007 is inspired by the same production environment that the SharePoint Server 2010 tests follow. However this was recorded before the upgrade to SharePoint Server 2010 on that environment. The following graph shows the test mix for the lab and production environments for Office SharePoint Server

207 Test methodology The tests performed for this comparison were performed by creating an Office SharePoint Server 2007 environment, testing it with the workload outlined earlier in this section, and then upgrading the content databases to SharePoint Server 2010 without changing the clients using the environment, nor doing a visual upgrade. This upgraded environment was then re-tested for the SharePoint Server 2010 results with the same test mix which includes only Office SharePoint Server 2007 operations. The dataset was not modified after the content database upgrade for the SharePoint Server 2010 tests. The test mix for Office SharePoint Server 2007 excludes any new SharePoint Server 2010 specific operations, and resembles the enterprise intranet collaboration solution on the same production environment for Office SharePoint Server 2007, as described under the Workload section. Analysis When the same number of Web servers are stressed to their maximum throughput on SharePoint Server 2010 and Office SharePoint Server 2007, SharePoint Server 2010 achieves 20% less throughput compared to Office SharePoint Server When the Web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was able to achieve 25% better throughput compared to Office SharePoint Server This reflects the improvements that were made in SharePoint Server 2010 to sustain larger deployments. When the web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Office SharePoint Server 2007 was Lock bound on the database tier. This means that increasing the processing power available to the database servers enables SharePoint Server 2010 to achieve better throughput than would be possible with the same hardware using Office SharePoint Server This is caused by the locking mechanisms in the database in Office SharePoint Server 2007 which are unaffected by improved hardware so that we were unable to push the database server s CPU Utilization past 80%. As a result of these findings outlined earlier in this section, on Office SharePoint Server 2007 the maximum throughput possible was achieved in a 5x0x1 topology whereas in SharePoint Server 2010 the maximum throughput possible with the same workload was achieved in a 7x0x1 topology, and yielded a 25% increased total RPS. Results graphs and charts The following graph shows the throughput without scaling out Web servers. 207

208 The following graph shows the throughput when Web servers were at maximum scale out. 208

209 209

210 Departmental collaboration environment technical case study (SharePoint Server 2010) (en anglais) This document describes a specific deployment of Microsoft SharePoint Server It includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration The workload that includes the number, and types, of users or clients, and environment usage characteristics Technical case study farm dataset that includes database contents and Search indexes Health and performance data that is specific to the environment In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 210

211 Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology and configuration Workload, which is the demand on the farm that includes the number of users, and the usage characteristics Dataset that includes database sizes Health and performance data that is specific to the environment This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) about SharePoint environments at Microsoft. 211

212 The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. Employees use this environment to track projects, collaborate on documents, and share information within their department. This environment is also used for internal testing, and is frequently upgraded to the latest SharePoint Server pre-release versions as they become available. As many as 9,000 unique users visit the environment on a busy day, generating up to 470 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the departmental collaboration environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment. Hardware This section provides details about the server computers that were used in this environment. Remarque : This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Web Servers There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl target. 212

213 Web Server WFE1-2 WFE3-4 Processor(s) 2 quad 2.33 GHz 2 quad 2.33 GHz RAM 32 GB 16 GB Operating system Windows Server 2008, 64 bit Windows Server 2008, 64 bit Size of the SharePoint drive 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory Number of network adapters 2 2 Network adapter speed 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Load balancer type Hardware load balancing Hardware load balancing Software version SharePoint Server 2010 (pre-release version) SharePoint Server 2010 (pre-release version) Services running locally Search Query WFE3 No services WFE4 Search crawl target Application Server There are four application servers in the farm. 213

214 Web Server APP1-3 APP4 Processor(s) 2 quad 2.33 GHz 2 quad 2.33 GHz RAM 16 GB 16 GB Operating system Windows Server 2008, 64 bit Windows Server 2008, 64 bit Size of the SharePoint drive 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory 2x136GB 15K SAS (RAID 0) 4x60GB SSD, SATA (RAID 5) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory Number of network adapters 2 2 Network adapter speed 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Load balancer type Hardware load balancing Hardware load balancing Software version SharePoint Server 2010 (pre-release version) SharePoint Server 2010 (pre-release version) Services running locally APP1 Central Administration and all applications except for Office Web Applications APP2 All applications (including Office Web Applications) APP3 Office Web Applications Search Crawler 214

215 Database Servers There are three database servers, one running the default SQL Server instance housing the content databases, one running the Usage and Web Analytics databases, and one running the Search databases. Database DB1 Default Instance DB2 DB3 Processor(s) 4 quad 3.2 GHz 2 quad 3.2 GHz 2 quad 3.2 GHz RAM 32 GB 16 GB 32 GB Operating system Windows Server 2008 SP1, 64 bit Windows Server 2008 SP1, 64 bit Windows Server 2008 SP1, 64 bit Storage and geometry 5x146GB 15K SAS + SAN Disk 1: OS (2 disk RAID 10) Disk 2: Swap (2 disk RAID 10) Disk 3: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K Disk 4: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K Disk 5-15: SAN using fiber connection. When possible, one database per two disks. Separating logs and data between LUNs. 15K drives. 6x450GB 15K SAS Directly attached 14x146GB 15K SAS Disk 1: Usage logs and OS Disk 2: Usage data 2x136GB 15K SAS (RAID 0) 6x60GB SSD, SATA (RAID 5) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory. Solid state drives. 6-60GB Solid state drives (RAID 5) Number of network adapters

216 Database DB1 Default Instance DB2 DB3 Network adapter speed 1 Gigabit 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Windows NTLM Software version SQL Server 2008 SQL Server 2008 SQL Server 2008 R2 Topology The following diagram shows the topology for this farm. 216

217 217

218 Configuration The following table enumerates settings that were made that affect performance or capacity in the environment. Setting Value Notes Site collection: On Object Caching (On Off) Disabled Anonymous Cache Profile Disabled (select) On 100GB Anonymous Cache Profile 60 seconds (select) Object Cache (Off n MB) Cross List Query Cache Changes (Every Time Every n seconds) Enabling the output cache improves server efficiency by reducing calls to the database for data that is frequently requested. Site collection cache profile (select) Intranet (Collaboration Site) Allow writers to view cached content is checked, bypassing the ordinary behavior of not letting people with edit permissions to have their pages cached. Object Cache (Off n MB) On 500 MB The default is 100 MB. Increasing this setting enables additional data to be stored in the front-end Web server memory. Usage Service: Trace Log days to store log files (default: 14 days) Query Logging Threshold: Microsoft SharePoint Foundation Database configure 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. 218

219 Setting Value Notes QueryLoggingThreshold to 1 second Database Server Default Instance: Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option ( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS) 165 Average RPS at peak time (11 AM-3 PM) 216 Total number of unique users per day 9186 Average concurrent users 189 Maximum concurrent users 322 Total # of requests per day 7,124,943 This table shows the number of requests for each user agent. 219

220 User Agent Requests Percentage of Total Search (crawl) 4,373, % Outlook 897, % OneNote 456, % DAV 273, % Browser 247, % Word 94, % SharePoint Workspaces 70, % Office Web Applications 45, % Excel 8, % Access 1, % Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Value Database size (combined) 1.8 TB BLOB size 1.68 TB Number of content databases 18 Total number of databases

221 Dataset Characteristics Value Number of site collections 7,499 Number of Web applications 7 Number of sites 42,457 Search index size (number of items) 4.6 million Health and Performance Data This section provides health and performance data that is specific to the case study environment. General Counters Metric Value Availability (uptime) % Failure Rate % Average memory used 0.89 GB Maximum memory used 5.13 GB Search Crawl % of Traffic (Search client requests / total requests) 82.5% The following charts show the average CPU utilization and latency for this environment: 221

222 222

223 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the requests experience slower response times. 223

224 Database Counters Metric Value Average Disk queue length 1.42 Disk Queue Length: Reads 1.38 Disk Queue Length: Writes 0.04 Disk Reads/sec Disk Writes/sec SQL Compilations/second SQL Re-compilations/second 0.14 SQL Locks: Average Wait Time ms SQL Locks: Lock Wait Time ms SQL Locks: Deadlocks Per Second 1.87 SQL Latches: Average Wait Time 5.10 ms SQL Cache Hit Ratio 99.77% 224

225 Divisional portal environment lab study (SharePoint Server 2010) (en anglais) This document provides guidance on performance and capacity planning for a divisional portal based on Microsoft SharePoint Server It includes the following: Test environment specifications, such as hardware, farm topology and configuration Test farm dataset Test data and recommendations for how to determine the hardware, topology and configuration that you must have to deploy a similar environment, and how to optimize your environment for appropriate capacity and performance characteristics In this article: Introduction to this environment Glossary Overview Specifications Results and analysis Introduction to this environment This document outlines the test methodology and results to provide guidance for capacity planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010 deployment where teams mainly do collaborative activities and some content publishing. This document assumes a "division" to be an organization inside an enterprise with 1,000 to 10,000 employees. Different scenarios will have different requirements. Therefore, it is important to supplement this guidance with additional testing on your own hardware and in your own environment. If your planned design and workload resembles the environment described in this document, you can use this document to draw conclusions about scaling your environment up and out. When you read this document, you will understand how to do the following: 225

226 Estimate the hardware that is required to support the scale that you need to support: number of users, load, and the features enabled. Design your physical and logical topology for optimal reliability and efficiency. High Availability/Disaster Recovery are not covered in this document. Understand the effect of ongoing search crawls on RPS for a divisional portal deployment. The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large company. For details about the production environment, see Departmental collaboration environment technical case study (SharePoint Server 2010) (en anglais). Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Also, we encourage you to read the following: Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions. RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of server and farm load. Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements. Green Zone: This is the state at which the server can maintain the following set of criteria: The server-side latency for at least 75% of the requests is less than.5 second. All servers have a CPU Utilization of less than 50%. 226

227 Remarque : Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search crawl load to 10% CPU. Failure rate is less than 0.01%. Red Zone (Max): This is the state at which the server can maintain the following set of criteria: HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned. Failure rate is less than 0. 1%. The server-side latency is less than 1 second for at least 75% of the requests. Database server CPU utilization is less than or equal to 75%, which allows for 10% to be reserved for the Search crawl load, limited by using SQL Server Resource Governor. All Web servers have a CPU Utilization of less than or equal to 75%. AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For example, 2x1x1 means that this environment has 2 Web servers, 1 application server, and 1 database server. MDF and LDF: SQL Server physical files. For more information, see Files and Filegroups Architecture. Overview This section provides an overview to our assumptions and our test methodology. Assumptions For our testing, we made the following assumptions: In the scope of this testing, we did not consider disk I/O as a limiting factor. It is assumed that an infinite number of spindles are available. The tests model only peak time usage on a typical divisional portal. We did not consider cyclical changes in traffic seen with day-night cycles. That also means that timer jobs which generally require scheduled nightly runs are not included in the mix. There is no custom code running on the divisional portal deployment in this case. We cannot guarantee behavior of custom code/thirdparty solutions installed and running in your divisional portal. 227

228 For the purpose of these tests, all of the services databases and the content databases were put on the same instance of Microsoft SQL Server. The usage database was maintained on a separate instance of SQL Server. For the purpose of these tests, BLOB cache is enabled. Search crawl traffic is not considered in these tests. But to factor in the effects of an ongoing search crawl, we modified definitions of a healthy farm. (Green-zone definition to be 40 percent for SQL Server to allow for 10 percent tax from Search crawls. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.) Test methodology We used Visual Studio Team System for Test 2008 SP2 to perform the performance testing. The testing goal was to find the performance characteristic of green zone, max zone and various system stages in between for each topology. Detailed definitions of "max zone" and "green zone" are given in the Glossary as measured by specific values for performance counters, but in general, a farm configuration performing around "max zone" breakpoint can be considered under stress, whereas a farm configuration performing "green zone" breakpoint can be considered healthy. The test approach was to start by using the most basic farm configuration and run a set of tests. The first test is to gradually increase the load on the system and monitor its performance characteristic. From this test we derived the throughput and latency at various user loads and also identified the system bottleneck. After we had this data, we identified at what user load did the farm exhibit green zone and max zone characteristics. We ran separate tests at those pre-identified constant user loads for a longer time. These tests ensured that the farm configuration can provide constant green zone and max zone performance at respective user loads, over longer period of time. Later, while doing the tests for the next configuration, we scaled out the system to eliminate bottlenecks identified in previous run. We kept iterating in this manner until we hit SQL Server CPU bottleneck. We started off with a minimal farm configuration of 1 Web server /application server and 1 database server. Through multiple iterations, we finally ended at 3 Web servers, 1 application server, 1 database server farm configuration, where the database server CPU was maxed out. Below you will find a quick summary and charts of tests we performed on each iteration to establish green zone and max zone for that configuration. That is followed by comparison of green zone and max zone for different iterations, from which we derive our recommendations. The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit (LTK)" which is publically available for customers to download and use. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the lab environment. 228

229 Hardware The table that follows presents hardware specs for the computers that were used in this testing. Every Web server that was added to the server farm during multiple iterations of the test complies with the same specifications. Web server Application Server Database Server Processor(s) 3.19GHz RAM 8 GB 8 GB 32 GB Number of network adapters Network adapter speed 1 Gigabit 1 gigabit 1 Gigabit Load balancer type F5 - Hardware load balancer Not applicable Not applicable ULS Logging level Medium Medium Not applicable Software The table that follows explains software installed and running on the servers that were used in this testing effort. Web Server Application Server Database Server Operating System Windows Server 2008 R2 x64 Windows Server 2008 R2 x64 Windows Server 2008 x64 Software version SharePoint Server 2010 and Office Web Applications, pre-release versions 229 SharePoint Server 2010 and Office Web Applications, prerelease versions SQL Server 2008 R2 CTP3

230 Web Server Application Server Database Server Authentication Windows NTLM Windows NTLM Windows NTLM Load balancer type F5 - Hardware load balancer Not applicable Not applicable ULS Logging level Medium Medium Not applicable Anti-Virus Settings Disabled Disabled Disabled Services running locally Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search Central Administration Excel Services Managed Metadata Web Service Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service PowerPoint Services Search Query and Site Settings Service SharePoint Server Search Visio Graphics Services Word Viewing Service Not applicable The table indicates which services are provisioned in the test environment. Other services such as the User Profile service and Web Analytics are not provisioned. Topology and configuration The following diagram shows the topology used for the tests. We changed the number of Web servers from 1 to 2 to 3, as we moved between iterations, but otherwise the topology remained the same. 230

231 231

232 Dataset and disk geometry The test farm was populated with about 1.62 Terabytes of content, distributed across five different sized content databases. The following table explains this distribution: Content database Content database size 36 GB 135 GB 175 GB 1.2 terabytes 75 GB Number of sites Number of webs RAID configuration Number of spindles for MDF Number of spindles for LDF Transactional mix The following are important notes about the transactional mix: There are no My Sites provisioned on the divisional portal. Also, the User Profile service, which supports My Sites, is not running on the farm. The transactional mix does not include any My Site page/web service hits or traffic related to Outlook Social Connector. The test mix does not include any traffic generated by co-authoring on documents. The test mix does not include traffic from Search Crawl. However this was factored into our tests by modifying the Green-zone definition to be 40 percent SQL Server CPU usage instead of the standard 50 percent to allow for 10 percent for the search crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS. The following table describes the overall transaction mix. The percentages total

233 Feature or Service Operation Read/write Percentage of mix ECM Get static files r 8.93% View home page r 1.52% Microsoft InfoPath Display/Edit upsize list item and new forms r 0.32% Download file by using "Save as" r 1.39% Microsoft OneNote 2010 Open Microsoft Office OneNote 2007 file r 13.04% Search Search through OSSSearch.aspx or SearchCenter r 4.11% Workflow Start autostart workflow w 0.35% Microsoft Visio Render Visio file in PNG/XAML r 0.90% Office Web Applications - PowerPoint Render Microsoft PowerPoint, scroll to 6 slides r 0.05% Office Web Applications - Word Render and scroll Microsoft Word doc in PNG/Silverlight r 0.24% Microsoft SharePoint Foundation List Check out and then check in an item w 0.83% List - Get list r 0.83% List - Outlook sync r 1.66% List - Get list item changes r 2.49% List - Update list items and adding new items w 4.34% Get view and view collection r 0.22% Get webs r 1.21% 233

234 Feature or Service Operation Read/write Percentage of mix Browse to Access denied page r 0.07% View Browse to list feeds r 0.62% Browse to viewlists r 0.03% Browse to default.aspx (home page) r 1.70% Browse to Upload doc to doc lib w 0.05% Browse to List/Library's default view r 7.16% Delete doc in doclib using DAV w 0.83% Get doc from doclib using DAV r 6.44% Lock and Unlock a doc in doclib using DAV w 3.32% Propfind list by using DAV r 4.16% Propfind site by using DAV r 4.16% List document by using FPSE r 0.91% Upload doc by using FPSE w 0.91% Browse to all site content page r 0.03% View RSS feeds of lists or wikis r 2.03% Excel Services Render small/large Excel files r 1.56% Workspaces WXP - Cobalt internal protocol r 23.00% Full file upload using WXP w 0.57% 234

235 Results and analysis This section describes the test methodology and results to provide guidance for capacity planning of a typical divisional portal. Results from 1x1 farm configuration Summary of results On a 1 Web server and 1 database server farm, in addition to Web server duties, the same computer was also acting as application server. Clearly this computer (still called Web server) was the bottleneck. As presented in the data here, the Web server CPU reached around 86% utilization when the farm was subjected to user load of 125 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of Even at a small user load, Web server utilization was always too high to consider this farm as a healthy farm. For the workload and dataset that we used for the test, we do not recommend this configuration as a real deployment. Going by definition of "green zone", there is not really a "green zone" for this farm. It is always under stress, even at a small load. As for "max zone", at the smallest load, where the farm was in "max zone", the RPS was 75. Because the Web server was the bottleneck due to its dual role as an application server, for the next iteration, we separated out the application server role onto its own computer. Performance counters and graphs The following table presents various performance counters captured during testing a 1x1 farm at different steps in user load. User Load RPS Latency Web server CPU Application server CPU N/A N/A N/A N/A Database server CPU th Percentile (sec)

236 User Load th Percentile (sec) The following chart shows the RPS and latency results for a 1x1 configuration. 236

237 The following chart shows performance counter data in a 1x1 configuration. Results from 1x1x1 farm configuration Summary of results 237

238 On a 1 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in this section, the Web server CPU reached around 85% utilization when the farm was subjected to user load of 150 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of This configuration delivered "green zone" RPS of 99, with 75th percentile latency being 0.23 sec, and the Web server CPU hovering around 56 % utilization. This indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS delivered by this farm was 123 with latencies of 0.25 sec and the Web server CPU hovering around 85%. Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another the Web server for the next iteration. Performance counters and graphs The following table presents various performance counters captured during testing a 1x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) The following chart shows RPS and latency results for a 1x1x1 configuration. 238

239 The following chart shows performance counter data in a 1x1x1 configuration. 239

240 Results from 2x1x1 farm configuration Summary of results On a 2 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in this section, Web server CPU reached around 76% utilization when the farm was subjected to user load of 200 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of

241 This configuration delivered "green zone" RPS of 191, with 75th percentile latency being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around 75%. Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another Web server for the next iteration. Performance counters and graphs The following table presents various performance counters captured during testing a 2x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) th Percentile (sec) The following chart shows RPS and latency results for a 2x1x1 configuration. 241

242 The following chart shows performance counter data in a 2x1x1 configuration. 242

243 Results from 3x1x1 farm configuration Summary of results On a 3 Web server, 1 application server and 1 database server farm, finally, the database server CPU was the bottleneck. As presented in the data in this section, database server CPU reached around 76% utilization when the farm was subjected to user load of 226 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of

244 This configuration delivered "green zone" RPS of 242, with 75th percentile latency being 0.41 sec, and database server CPU hovering around 44% utilization. This indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS delivered by this farm was 318 with latencies of 0.5 sec and database server CPU hovering around 75%. This was the last configuration in the series. Performance counters and graphs The following table presents various performance counters captured during testing a 3x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) th Percentile (sec) The following chart shows RPS and latency results in a 3x1x1 configuration. 244

245 The following chart shows performance counter data for a 3x1x1 configuration. 245

246 Comparison From the iterative tests we performed, we found out the points at which a configuration enters max zone or green zone. Here s a table of those points. The table and charts in this section provide a summary for all the results that were presented earlier in this article. 246

247 Topology 1x1 1x1x1 2x1x1 3x1x1 Max RPS Green Zone RPS Not applicable Max Latency Green Zone Latency The following chart shows a summary of RPS at different configurations. 247

248 The following chart shows a summary of latency at different configurations. 248

249 A note on disk I/O Disk I/O based bottlenecks are not considered while prescribing recommendations in this document. However, it is still interesting to observe the trend. Here are the numbers: 249

250 Configuration 1x1 1x1x1 2x1x1 3x1x1 Max RPS Reads/Sec Writes/Sec Because we ran the tests in durations of 1 hour and the test uses only a fixed set of sites/webs/document libraries and so on, SQL Server could cache all the data. Thus, our testing caused very little Read IO. We see more write I/O operations that read. It is important to be aware that this is an artifact of the test methodology, and not a good representation of real deployments. Most of the typical divisional portals would have more read operations 3 to 4 times more than write operations. The following chart shows I/Ops at different RPS. 250

251 Tests with Search incremental crawl As we mentioned before, all the tests until now were run without Search crawl traffic. In order to provide information about how ongoing search crawl can affect performance of a farm, we decided to find out the max user RPS and corresponding user latencies with search crawl traffic in the mix. We added a separate Web server to 3x1x1 farm, designated as a crawl target. We saw a 17% drop in RPS compared to original RPS exhibited by 3x1x1. 251

252 In a separate test, on the same farm, we used Resource Governor to limit available resources to search crawl 10%. We saw that as Search uses lesser resources, the max RPS of the farm climbs up by 6%. Baseline 3x1x1 Only Incremental Crawl No Resource Governor RPS 318 N/A Percent RPS difference from baseline 0% N/A 83% 88% Database server CPU (%) SA Database server CPU (%) Web server CPU (%) Application server CPU (%) Crawl Web server CPU (%) % Resource Governor The following chart shows results from tests with incremental Search crawl turned on. 252

253 253

254 Important : Here we are only talking about incremental crawl, on a farm where there are not very many changes to the content. It is important to be aware that 10% resource utilization will be insufficient for a full search crawl. It may also prove to be less if there are too many changes. It is definitely not advised to limit resource utilization to 10% if you are running a full search crawl, or your farm generally sees a high volume of content changes between crawls. Summary of results and recommendations To paraphrase the results from all configurations we tested: With the configuration, dataset and test workload we had selected for the tests, we could scale out to maximum 3 Web servers before SQL Server was bottlenecked on CPU. The absolute max RPS we could reach that point was somewhere around 318. With each additional Web server, increase in RPS was almost linear. We can extrapolate that as long as SQL Server is not bottlenecked, you can add more Web servers and additional increase in RPS is possible. Latencies are not affected much as we approached bottleneck on SQL Server. Incremental Search crawl directly affects RPS offered by a configuration. The effect can be minimized by using Resource Governor. Using the results, here are few recommendations on how to achieve even larger scale if you must have more RPS from your divisional portal: 1x1 farm can deliver up to 75 RPS. However, it is usually stressed. It s not a recommended configuration for a divisional portal in production. Separate out content databases and services databases on separate instances of SQL Server: In the test workload used in tests, when SQL Server was bottlenecked on CPU, only 3% of the traffic was to the services databases. Thus this step would have achieved slightly better scale out than what we saw. But, in general, increase in scale out by separating out content databases and services databases is directly proportional to the traffic to services database in your farm. Separate out individual content databases on separate instances of SQL Server. In the dataset used for testing, we had 5 content databases, all located on the same instance of SQL Server. By separating them out on different computers, you will be spreading CPU utilization across multiple computers. Therefore, you will see much larger RPS numbers. Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server can increase RPS potential of the farm almost linearly. 254

255 How to translate these results into your deployment In this article, we discussed results as measured by RPS and latency, but how do you apply these in the real world? Here s some math based on our experience from divisional portal internal to Microsoft. A divisional portal in Microsoft which supports around 8000 employees collaborating heavily, experiences an average RPS of 110. That gives a Users to RPS ratio of ~72 (that is, 8000/110). Using the ratio, and the results discussed earlier in this article, we can estimate how many users a particular farm configuration can support healthily: Farm configuration "Green Zone" RPS Approximate number of users it can support 1x1x x1x x1x Of course, this is only directly applicable if your transactional mix and hardware is exactly same as the one used for these tests. Your divisional portal may have different usage pattern. Therefore, the ratio may not directly apply. However, we expect it to be approximately applicable. About the authors Gaurav Doshi is a Program Manager for SharePoint Server at Microsoft. Raj Dhrolia is a Software Test Engineer for SharePoint Server at Microsoft. Wayne Roseberry is a Principal Test Lead for SharePoint Server at Microsoft. 255

256 Social environment technical case study (SharePoint Server 2010) (en anglais) This document describes a specific deployment of Microsoft SharePoint Server It includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration The workload that includes the number, and types, of users or clients, and environment usage characteristics Technical case study farm dataset that includes database contents and Search indexes Health and performance data that is specific to the environment In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 256

257 Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010 Gestion de la capacité SharePoint Server 2010 : limitations et frontières logicielles Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology and configuration Workload, which is the demand on the farm that includes the number of users, and the usage characteristics Dataset that includes database sizes Health and performance data specific to the environment This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en anglais) about SharePoint environments at Microsoft. 257

258 The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. This environment hosts SharePoint My Sites that connect employees with one another and the information that they need. Employees use this environment to present personal information such as areas of expertise, past projects, and colleagues to the wider organization. The environment also hosts personal sites and documents for viewing, editing, and collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to provide a central location that can be accessed from the browser and various client applications. As many as 72,000 unique users visit the environment on a busy day, generating up to 180 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the enterprise social environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment. Hardware This section provides details about the server computers that were used in this environment. Remarque : This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Web Servers There are three Web servers in the farm, each with identical hardware. Two serve content, and the third is a dedicated search crawl target. 258

259 Web Server Processor(s) RAM Operating system Size of the SharePoint drive WFE1-3 2 quad 2.33 GHz 16 GB Windows Server 2008, 64 bit 400 GB Number of network adapters 2 Network adapter speed Authentication Load balancer type Software version Services running locally Services consumed from a federated services farm 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search User Profile Service Web Analytics Web Service Business Data Connectivity Service Managed Metadata Web Service 259

260 Application Server There are two application servers in the farm, each with identical hardware. Application Server Processor(s) RAM OS APP1-4 2 quad 2.33 GHz 16 GB Windows Server 2008, 64 bit Size of the SharePoint drive 400 GB Number of network adapters 1 Network adapter speed 1 Gigabit Authentication Windows NTLM Load balancer type Hardware load balancing Software version SharePoint Server 2010 (pre-release version) Services running locally Office Web Apps Excel PowerPoint Secure Store Usage and Health State Service Database Servers There is a SQL cluster with two database servers, each with identical hardware. One of the servers is active and the other is passive for redundancy. 260

261 Database Server Processor(s) RAM Operating system DB1-2 4 quad 2.4 GHz 64 GB Windows Server 2008, 64 bit Storage and geometry (1.25 TB * 6) Disk 1-4: SQL Data Disk 5: Logs Disk 6: TempDB Number of network adapters 2 Network adapter speed Authentication 100MB, 1GB Windows NTLM Software version SQL Server 2008 Topology The following diagram shows the topology for this farm. 261

262 262

263 Configuration The following table enumerates settings that were changed that affect performance or capacity in the environment. Setting Value Notes Usage Service: Trace Log days to store log files (default: 14 days) QueryLoggingThreshold Microsoft SharePoint Foundation Database configure QueryLoggingThreshold to 1 second Database Server Default Instance Max degree of parallelism 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS)

264 Workload Characteristics Value Average RPS at peak time (11 AM-3 PM) 112 Total number of unique users per day 69,814 Average concurrent users 639 Maximum concurrent users 1186 Total # of requests per day 4,045,677 This table shows the number of requests for each user agent. User Agent Requests Percentage of Total Outlook Social Connector Browser 1,808, % Search (crawl) 704, % DAV 459, % OneNote 266, % Outlook 372, % Browser 85, % Word 38, % Excel 30, % Office Web Applications 20, % SharePoint Workspaces 19, % 264

265 Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Value Database size (combined) 1.5 TB BLOB size 1.05 TB Number of content databases 64 Number of Web applications 1 Number of site collections 87,264 Number of sites 119,400 Search index size (number of items) 5.5 million Health and Performance Data This section provides health and performance data that is specific to the case study environment. General Counters Metric Value Availability (uptime) 99.61% Failure Rate 0.39% Average memory used 0.79 GB 265

266 Metric Value Maximum memory used 4.53 GB Search Crawl % of Traffic (Search client requests / total requests) 17.42% The following charts show average CPU utilization and latency for this environment. 266

267 267

268 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the requests experience slower response times. Database Counters Metric Value Read/Write Ratio (IO Per Database) : Average Disk queue length Disk Queue Length: Reads

269 Metric Value Disk Queue Length: Writes Disk Reads/sec Disk Writes/sec SQL Compilations/second SQL Re-compilations/second SQL Locks: Average Wait Time 125 ms SQL Locks: Lock Wait Time ms SQL Locks: Deadlocks Per Second 0 SQL Latches: Average Wait Time 0 ms SQL Cache Hit Ratio 20.1% 269

270 Résultats des tests de performances et de capacité et recommandations (SharePoint Server 2010) Cette section contient une série de livres blancs et d articles qui décrivent l impact des jeux de fonctionnalités spécifiques inclus dans Microsoft SharePoint Server 2010 sur les performances et la capacité. Ces livres blancs et articles comprennent des informations sur les caractéristiques de la fonctionnalité en termes de performances et de capacité et sur la façon dont la fonctionnalité a été testée par Microsoft. Ces informations abordent les points suivants : caractéristiques de la batterie de serveurs de test ; résultats des tests ; recommandations ; résolution des problèmes de performances et d évolutivité. Remarque : Les livres blancs sont mis à jour et republiés sous la forme d articles. Si vous téléchargez un livre blanc à partir de cette page, il est possible que des informations mises à jour soient disponibles lorsqu il est republié sous la forme d un article. Avant de lire ces livres blancs et articles, il est important de comprendre les concepts clés de la gestion de la capacité dans SharePoint Server Pour plus d informations, voir Capacity management and sizing for SharePoint Server 2010 (en anglais). Le tableau suivant décrit les livres blancs et articles disponibles. Si le contenu est disponible en tant que livre blanc, vous pouvez l obtenir sous la forme d un document Microsoft Word à partir de la page Résultats de tests et recommandations liés aux performances et à la capacité de SharePoint Server 2010 (éventuellement en anglais). 270

271 Sujet Access Services Business Connectivity Services Vue d ensemble des caches Excel Services dans Microsoft SharePoint Server 2010 InfoPath Forms Services Grandes listes Description Fournit des informations utiles sur l impact de l utilisation d Access Services sur les topologies exécutant SharePoint Server Consultez l article à la page Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en anglais). Fournit de l aide sur l empreinte de l utilisation de Business Connectivity Services concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (BCSCapacityPlanningDoc.docx). Fournit des informations sur la façon dont les trois caches SharePoint Server 2010 permettent au produit d évoluer et de croître de manière à répondre aux exigences de votre application métier. Téléchargez ce livre blanc (éventuellement en anglais) (SharePointServerCachesPerformance.docx). Fournit de l aide sur la planification pour Excel Services dans Microsoft SharePoint Server Consultez l article à la page Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en anglais). Fournit de l aide sur l empreinte de l utilisation d InfoPath Forms Services concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (InfoPath2010CapacityPlanningDoc.docx). Contient des directives quant à la performance des bibliothèques et des listes de documents volumineuses. Ce document est spécifique à SharePoint Server 2010, bien que les limitations et les limites abordées s appliquent également à Microsoft SharePoint Foundation Téléchargez ce livre blanc (éventuellement en anglais) 271

272 Sujet Référentiels de documents à grande échelle Sites Mon site et informatique sociale Office Web Apps PerformancePoint Services Recherche Visio Services Description (DesigningLargeListsMaximizingListPerformance.docx). Contient des directives quant à la performance des référentiels de documents à grande échelle concernant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (LargeScaleDocRepositoryCapacityPlanningDoc.docx). Fournit de l aide sur l empreinte de l utilisation de sites Mon site et d autres fonctionnalités d informatique sociale concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (MySitesSocialComputingCapacityPlanningDoc.docx). Fournit de l aide sur l empreinte de l utilisation d Office Web Apps concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (OfficeWebAppsCapacityPlanningDoc.docx). Fournit de l aide sur l empreinte de l utilisation de PerformancePoint Services concernant les topologies exécutant SharePoint Server Consultez l article à la page Évaluer les besoins en performances et en capacité pour PerformancePoint Services. Fournit des informations sur la planification de la capacité pour différents déploiements de la recherche dans SharePoint Server 2010, notamment pour des batteries de serveurs de taille petite, moyenne et grande. Téléchargez ce livre blanc (éventuellement en anglais) (SearchforSPServer2010CapacityPlanningDoc.docx). Si vous utilisez FAST Search Server 2010 for SharePoint comme solution de recherche de contenu d entreprise, voir Plan for performance and capacity (FAST Search Server 2010 for SharePoint). Fournit de l aide sur l empreinte de l utilisation de Visio Services 272

273 Sujet Web Analytics Gestion de contenu Web Word Automation Services Flux de travail Description concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (VisioServicesCapacityPlanningDoc.docx). Fournit de l aide sur l empreinte de l utilisation du service Web Analytics concernant les topologies exécutant SharePoint Server Consultez les articles à la page Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en anglais). Fournit de l aide sur la planification des performances et de la capacité pour une solution de gestion de contenu Web. Consultez l article à la page Estimer les exigences de performances et de capacité pour la gestion de contenu Web dans SharePoint Server Fournit de l aide sur la planification de la capacité pour Word Automation Services dans SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (WASCapacityPlanningDoc.docx). Fournit de l aide sur l empreinte de l utilisation de flux de travail concernant les topologies exécutant SharePoint Server Téléchargez ce livre blanc (éventuellement en anglais) (WorkflowCapacityPlanningDoc.docx). 273

274 Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en anglais) This article provides guidance on the footprint that usage of Access Services dans Microsoft SharePoint Server 2010 has on topologies that are running Microsoft SharePoint Server In this article: Test farm characteristics Test results Recommendations Troubleshooting Test farm characteristics This section describes the dataset that was used during the testing; the workloads that were placed on the product during performance gathering; the hardware that was used during the testing; and the topology for how that hardware was deployed. Dataset Access Services capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables and the complexity of queries often have the most effect on capacity and performance. The testing used representative sizes and complexities, but every application and dataset is different. The capacity and performance will depend on the applications that are being used, their specific complexity, and the data size. To evaluate the capacity profile, Access Services applications were simulated on a farm dedicated to Access Services (no other SharePoint tests were running). The farm contained the following representative sites: 1,500 Access Services applications that have a Small size profile; 100 items maximum per list. 1,500 Access Services applications that have a Medium size profile; 2,000 items maximum per list. 274

275 1,500 Access Services applications that have a Large size profile; 10,000 items maximum per list. Each application is made up of multiple lists, and the other lists are appropriately sized based on this largest list. Access Services can handle more data than 10,000 items. This number for the Large profile was chosen because it was expected that larger applications would not be common. The applications were evenly distributed among the following applications: Contacts A simple contact management application, dominated by a single list. Projects A simple task and project tracking applications, dominated by two lists (projects and tasks associated with each project). Orders A simple order entry system, similar to the Northwind Traders sample of Microsoft Access, but scaled down, and included many interrelated lists (orders, order details, invoices, invoice details, purchase orders, purchase order details, and so on). Workload To simulate application usage, workloads were created to perform one or more of the following operations: Opening forms Paging through the forms Filtering and sorting data sheets Updating, deleting and inserting records Publishing application Render reports Each workload includes think time between user actions, ranging from 5 to 20 seconds. This differs from other SharePoint capacity planning documents. Access Services is stateful; memory cursors and record sets were maintained between user interactions. It was important to simulate a full user session and not merely individual requests. For a single user workload, there is an average of two requests per second. The following table shows the percentages used to determine which application and which size of application to use. Small Medium Large Contacts 16% 10% 9% Projects 18% 12% 10% 275

276 Small Medium Large Orders 11% 8% 6% Green and red zone definitions For each configuration, two tests were ran to determine a green zone and a red zone. The green zone is the recommended throughput that can be sustained. The red zone is the maximum throughput that can be tolerated for a short time, but should be avoided. The green zone was defined as a point at which the test being run consumes at most half the bottlenecking resource. In this case, the bottlenecking resource was %CPU on any of the three tiers: front-end Web server, application server (Access Data Services), or database server (SQL Server). First, the bottleneck was identified for a particular configuration. If the bottleneck was Access Data Services CPU, we made sure that the green zone test consumed CPU on the Access Data Services computers in a range between 40 and 50 percent. For the red zone, a point was selected at which the maximum throughput was reached. This proved to be a CPU range between 80 and 90 percent. When searching for bottleneck, we looked at %CPU, memory usage (private bytes), disk queue length, network I/O, and other resources that could result in a bottleneck. Both the green and red zone tests were run for 1 hour at a fixed user load. Your results might vary The specific capacity and performance figures presented in this article will differ from figures in a real-world environment. This simulation is only an estimate of what actual users might do. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed the initial system design, you should test the configuration to determine whether the system will support the factors in your environment. Hardware setting and topology Lab Hardware To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four front-end Web servers, one to four application servers (if there is Access Services or Access Data Services), and a single database server computer that is running Microsoft SQL Server In addition, testing was performed by using four client computers. All server computers were 64-bit. All client computers were 32-bit. The following table lists the specific hardware that was used for the testing. 276

277 Machine role CPU Memory Network Disk Front-end Web server 2 processor, 4 core 2.33 GHz 8 GB 1 gig 2 spindles RAID 5 Application server (Access Data Services) 2 processor, 4 core 2.33 GHz 8 GB 1 gig 2 spindles RAID 5 Database server (SQL Server) 4 processor, 4 core 2.6 GHz 32GB 1 gig Direct Attached Storage (DAS) attached RAID 0 for each Logical Unit Number (LUN) Topology From our experience, CPU on the application sever tier, where Access Data Services is running, is an important limiting factor for throughput. We varied our topology by adding additional Access Data Services computers until it was no longer the bottleneck, and then added a front-end Web server to obtain even more throughput. 1x1: One front-end Web server computer to one Access Data Services computer 1x2: One front-end Web server computer to two Access Data Services computers 1x3: One front-end Web server computer to three Access Data Services computers 1x4: One front-end Web server computer to four Access Data Services computers 2x1: Two front-end Web server computers to one Access Data Services computer 2x2: Two front-end Web server computers to two Access Data Services computers 2x4: Two front-end Web server computers to four Access Data Services computers 277

278 The computer running SQL Server is a relatively strong computer and at no time did it become the bottleneck (although it started to approach CPU saturation on our 2x4 test), so we did not vary this in our topologies. Depending on the queries that are a part of a realworld application mix, it is expected that the database server (SQL Server) tier could become the bottleneck. Reporting Services was running in connected mode for all of our tests, running in the application server (Access Data Services) tier. Test results The following tables show the test results of Access Services. For each group of tests, only certain specific variables are changed to show the progressive impact on farm performance. All the tests reported in this article were conducted with think time or wait time. This differs from the capacity planning results for other parts of SharePoint. For information about bottlenecks of Access Services, see Common bottlenecks and their causes later in this article. Overall scale The following table and graph summarize the impact of adding additional front-end Web servers and dedicated Active Data Services computers to the farm. These throughput numbers are specifically for the Active Data Services computers. They do not reflect the impact on the overall farm. Topology Baseline solution maximum (RPS) Baseline recommended (RPS) 1x x x x x x x

279 279

280 Recommended results The following graph shows the results for recommended sustainable throughput. 280

281 As described earlier in this article, adding the fourth Access Data Services computer shifts the bottleneck to the front-end Web server, and that adding a second front-end Web server resolves the resource constraint on the front-end Web server tier. This would imply, that 1x1, 1x2, and 1x3 are reasonable configurations. However, when the fourth Access Data Services computer is added, a front-end Web server should also be added. Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be assumed that the addition of a seventh Access Data Services computer would also imply the addition of a third front-end Web server, and so on, to satisfy the needs of the farm. Remember that these results are based on a simulated work load only, and that an actual deployment should be monitored to find the point at which additional front-end Web servers are needed to support additional Access Data Services computers. Also, the front-end Web servers are dedicated to Access Services, and in reality the front-end Web servers are likely shared with other SharePoint workloads. The following graph shows the results. 281

282 The following graph shows the response time at this throughput level. The response time is very fast, at less than ¼ second on average per request. 282

283 These results show that the SQL Server computer was not a bottleneck, because adding a second front-end Web server resolved the resource shortage, and the SQL Server CPU was always less than 50 percent. However, be aware that the instance of SQL Server is 283

284 shared with other SharePoint services and SharePoint itself, and so the cumulative effect might drive CPU or disk I/O queue lengths to the point that they do become a bottleneck. Maximum The following graph shows the results, in which throughput was pushed beyond what could be sustained. In this graph we see that again a second front-end Web server was needed to maximum the usefulness of the fourth Access Data Services computer. Again, your results might vary, because this is highly dependent on the applications and their usage patterns. 284

285 285

286 In this case, the response time is increased, as the overall system is under stress. However, these levels are still approximately one second, and acceptable to most users. It might seem odd that with four Access Data Services computers, two front-end Web servers have an increased response time than one front-end Web server. This is because the overall throughput of the system is increased with two front-end Web servers. 286

287 SQL Server is again not a limiting factor here, because adding the second front-end Web server put us back on a linear scaling line. However, we are reaching almost 90 percent CPU usage on the instance of SQL Server. Therefore, there is very little headroom remaining. If we were to add a fifth Access Data Services computer, the SQL Server computer likely would have become the bottleneck. 287

288 Detailed results The following tables show the detailed results for the recommended configurations. 288

289 Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4 Req/Sec Tests/Sec Average Latency Average front-end Web server tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Max w3wp Private Bytes 9.46E E E E E E E+09 Average application server (Access Data Services) tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU %CPU w3wp %CPU RS Max total Private Bytes 4.80E E E E E E E+09 Max w3wp Private Bytes 2.10E E E E E E E+09 Max RS Private Bytes 1.78E E E E E E E

290 Database server (SQL Server) tier (single computer) 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Avg Private Bytes 2.96E E E E E E E+10 Max Private Bytes 3.26E E E E E E E+10 Avg Disk Queue Length Total The following tables show the detailed results for the maximum configurations. Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4 Req/Sec Tests/Sec Average Latency Average front-end Web server tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Max w3wp Private Bytes 9.46E E E E E E E

291 Average application server (Access Data Services) tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU %CPU w3wp %CPU RS Max total Private Bytes 4.80E E E E E E E+09 Max w3wp Private Bytes 2.10E E E E E E E+09 Max RS Private Bytes 1.78E E E E E E E+09 Database server (SQL Server) tier (single computer) 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Avg Private Bytes 2.96E E E E E E E+10 Max Private Bytes 3.26E E E E E E E+10 Avg Disk Queue Length Total Recommendations This section provides general performance and capacity recommendations. Access Services capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables and the complexity of queries often have the most effect. The testing used representative sizes and complexities, but every 291

292 application and dataset is different. Therefore, the capacity and performance will depend on the applications in use, their specific complexity, and the data size. Hardware recommendations Access Services uses standard hardware for both front-end Web servers and application servers; no special requirements are necessary. General SharePoint Server 2010 guidelines for CPU number, speed, and memory are applicable for computers in the application server (Access Data Services) tier. Scaled-up and scaled-out topologies To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for an Access Services scenario: To provide for more user load, check the CPU for the existing Access Services application servers. Add additional CPUs or cores, or both, to these servers if it is possible. Add more Access Services server computers as needed. This can be done to the point that the front-end Web server has become the bottleneck, and then add front-end Web servers as needed. In our tests, memory on the front-end Web server tier and application server (Access Data Services) tier was not a bottleneck. Depending on the size of the result sets, memory could become an issue. However, we do not expect that to be the norm. Track the private bytes for the Access Data Services w3wp process, as described here. In our tests, SQL Server was not a bottleneck. However, our tests were run in isolation from other SharePoint Server 2010 services. SQL Server CPU and disk I/O should be monitored and additional servers or spindles added as needed. Performance-related Access Services settings One way to control the performance characteristics of Access Services is to limit the size and complexity of queries that can be performed. Access Services provides a set of configurable throttles for controlling queries. Each of the following queries can be set through SharePoint Central Administration. (In the Application Management section, click Manage Service Applications, and then click Access Services.) In general, how much data that has to be retrieved from SharePoint to perform a query will have a significant effect on performance. This can be controlled in several ways. First, the inputs to a query can be limited: Maximum Sources per Query Maximum Records per Table Second, the resulting size of a query can be limited: 292

293 Maximum Columns per Query Maximum Rows per Query Allow Outer Joins In addition to the size of the query (data size in and out), the processing complexity on the data can be controlled, to reduce the CPU load on the application server (Access Data Services) tier: Maximum Calculated Columns per Query Maximum Order by Clauses per Query Obviously, the previous settings will affect the applications that can be run on the server. For example, if an application is written with 40 output columns from a query, and the settings are below this level, the application will throw a runtime error. A balance between user need and acceptable performance must be struck, and is highly dependent on the kind of Access applications that are expected to be run on the farm. One additional, more extreme measure can be taken. SharePoint Server 2010 supports a set of query operations natively, which Access Services augments to cover a broader set of application scenarios. For Access Services to improve queries from SharePoint, there is the potential that a large amount of data might have to be retrieved from the SharePoint content database. Instead, Access Services can be set to stick with only query operations, which can be natively supported by SharePoint. Therefore, avoiding the data fetch required for more complex operations: Allow Non-Remotable Queries Optimizations Common bottlenecks and their causes During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput. The table in Troubleshooting later in this article lists some common bottlenecks and describes their causes and possible resolutions. Performance monitoring To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied. Front-end Web servers The following table shows performance counters and processes to monitor for Web servers in your farm. 293

294 Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. Private Bytes Process(w3wp) This value should not approach the Max Private Bytes set for w3wp processes. Iif it does, additional investigation is needed into what component is using the memory. Access Data Services The following table shows performance counters and processes to monitor for application servers, or Access Data Services (Access Data Services) in this case, within your farm. Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Process(w3wp) The Access Data Services runs within its own w2wp process, and it will be obvious which w2wp 294

295 Performance counter Apply to object Notes 295 process this is as it will be getting the bulk of the CPU time. Avg. Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging. % Processor Time Process(ReportingServicesService) Reports are handled by SQL Server Reporting Services. If too many reports are being run, or if the reports are very complex, then the CPU and Private Bytes for this process will be high. Private Bytes Process(w3wp) Access Services caches the results of queries in memory, until the user s session expires (the timeout for which is configurable). If a large amount of data is being processed through the Access Data Services, memory consumption for the Access Data Services w3wp will increase. Private Bytes Process(ReportingSrevicesService) Reports are handled by SQL Server Reporting Services. If too many reports are being run, or

296 Performance counter Apply to object Notes reports are very complex, the CPU and Private Bytes for this process will be high. Database servers The following table shows performance counters and processes to monitor for database servers in your farm. Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Process(sqlservr) Average values larger than 80 percent indicate that processor capacity on the database server is insufficient. Private Bytes Process(sqlservr) Shows the average amount of memory being consumed by SQL Server. Avg. Disk Queue Length PhysicalDisk(_Total) Shows the average disk queue length; the database requests waiting to be committed to disk. This is often a good indicator that the instance 296

297 Performance counter Apply to object Notes of SQL Server is becoming overloaded, and that possibly additional disk spindles would help distribute the load. Troubleshooting The following table lists some common bottlenecks and describes their causes and possible resolutions. Bottleneck Cause Resolution Access Data Services CPU Web server CPU usage Database server disk I/O Access Services depends on a large amount of processing in the application server tier. If a 1x1, 1x2, or 1x3 configuration is used, the first bottleneck encountered will likely be the CPU on the Access Data Services servers. When a Web server is overloaded with user requests, average CPU usage will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers. When the number of I/O requests to a hard disk exceeds the disk s I/O 297 Increase the number of CPUs or cores, or both, in the existing Access Data Services computers. Add additional Access Data Services computers if possible. This issue can be resolved in one of two ways. You can add more Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higherspeed processors. Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk

298 Bottleneck Cause Resolution Reporting Services CPU utilization capacity, the requests will be queued. I/O ( contains As a result, the time to complete useful information about resolving disk I/O issues. each request increases. The Reporting Services process is using a large share of the CPU resources. Dedicate a computer to Reporting Services, taking load from the application server (Access Data Services) tier (connected mode) or the front-end Web server tier (local mode). 298

299 Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en anglais) This article describes the effects of using Excel Services dans Microsoft SharePoint Server 2010 on topologies running Microsoft SharePoint Server You can use this information to better scale your deployments based on your latency and throughput requirements. Remarque : It is important to be aware that the specific capacity and performance figures presented in this article will differ from the figures in realworld environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed your initial system design, test the configuration to determine whether the system will support the needs of your environment. In this article: Test farm characteristics Test Results Recommendations For general information about how to plan and run your capacity planning for SharePoint Server 2010, see Capacity management and sizing for SharePoint Server 2010 (en anglais). Test farm characteristics This section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance and capacity testing of Excel Services. 299

300 Dataset Excel Services capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of the workbook and the complexity of calculations have the most impact. Our testing used representative sizes and complexities, but every workbook is different, and your capacity and performance depends on the actual workbooks you use, and their specific size and complexity. We simulated Excel workbooks on a farm dedicated to Excel to evaluate our capacity profile. Note that no other SharePoint Server tests were running during our capacity profile tests. Within this farm, we used three buckets of workbooks Small, Large, and Very Large based on workbook size and complexity: Workbook Characteristics Small Large Very Large Sheets Columns ,000 Rows , ,000 Calculated Cells 0-20% 0-70% 0-70% Number of Formats Tables Charts Workbook Uses External Data 0% 20% 50% Workbook Uses a Pivot Table 0% 3% 3% Workbook Uses Conditional Formats 0% 10% 20% 300

301 This test farm included 2,000 SharePoint Server sites. Each site contained one small, one large, and one very large workbook. The distribution of the workbooks on the SharePoint Server pages was 10% small workbooks and 90% large and very large workbooks. Additionally, the test farm dataset included SharePoint Server pages that contained 1-5 Excel Web Parts. Workload To simulate application usage, workloads were created to perform one or more of the following operations: Action Mix Small Workbook Large Workbook View 50% 70% Edit 35% 15% Collaborative Viewing 10% 10% Collaborative Editing 5% 5% In addition, 17% of all the workbooks included external data. For large and very large workbooks that included external data, refreshes were performed 80% of the time; small workbooks do not include external data. Each workload includes think time between user actions of 10 seconds. Think time refers to user action delays that simulate how long a user might take to perform the actions. This differs from other SharePoint Server 2010 capacity planning documents. Excel Services is stateful the workbook is maintained in memory between user interactions making it important to simulate a full user session and not merely individual requests. On average, there are 0.2 requests per second for a single user workload. We randomly selected one of the 2,000 sites to run the test for each workload. We used the percentages in the following table to select application and application size, within that site. Workbook Selection Use Percentage Small Workbook 30% Large Workbook 55% Dashboard 10% 301

302 Workbook Selection Use Percentage Very Large Workbook 5% Green and Red Zone definitions For each configuration two zones were determined before throughput tests were performed. One zone was the green zone or recommended zone in which throughput can be sustained. The other zone was the red zone or maximum zone in which throughput can be tolerated for a short time but should be avoided. To determine our red and green zone user loads, we first conducted a step test and then stopped when the following conditions were met: Green zone We stopped at the point when any of the computers in our farm (Web front-end, Services de calcul Excel, or Microsoft SQL Server) exceeded 50% CPU usage or the response time for the overall system exceeded 1 second. Red Zone We stopped at the point where the successful RPS for the Services de calcul Excel computers in the farm was at a maximum. Past this point, the overall throughput for the farm started to decrease and/or we would start to see failures from one of the tiers. Often the maximum private bytes in Services de calcul Excel would be exceeded when throughput was in the red zone. After conducting the step tests, we retreated from these maximum values to run a longer constant load test of 1 hour. We stopped the green zone test when 75% of the load was used. We peaked in the red zone step test when we used 65% of the load. If the green zone test was limited by memory, and the CPU usage percentage never exceeded 50%, we instead used 75% of the load number calculated for the red zone. The average response time was less than.25 seconds for both green and red zones, and for both scale-out and scale-up tests. Hardware Settings and Topology This section describes the kinds of computer hardware we used in our lab and the farm configuration topologies that we used in our tests. Lab Hardware Several farm configurations were used for our testing to provide a high level of test-result detail. The farm configurations ranged from one to three Web front-end servers, one to three application servers for Excel Services and Services de calcul Excel, and a single database server computer that is running Microsoft SQL Server Additionally, our tests used four client computers. All servers were 64-bit, and the client computers were 32-bit. The following table lists the specific hardware that we used for testing. 302

303 Machine Role CPU Memory Network Web front-end server 2 proc/4 core 2.33 GHz Intel Xeon 8 GB 1 gig Services de calcul Excel 2 proc/4 core 2.33 GHz Intel Xeon 8 GB 1 gig SQL Server 4 proc/4 core 2.6 GHz Intel Xeon 16 GB 1 gig Topology Our testing experience indicates that memory on the Services de calcul Excel tier and CPU on the Web front-end server tier are the most important limiting factors for throughput. Be aware that your experience may vary. As a result, we varied the number of computer servers in both tiers for the scale-out tests. We deployed a topology of 1:1 for the Services de calcul Excel and Web front-end servers for the scale-up tests, and then varied the number of processors and available memory in the Services de calcul Excel computers. Services de calcul Excel is not especially demanding on the SQL Server instance running SharePoint Server 2010, as the workbook is read a binary large object (BLOB) from SharePoint Server 2010 and put in memory on the Services de calcul Excel tier (and additionally disk cached). At no time did SQL Server become a bottleneck. For all tests, bottleneck is defined as a state in which the capacity of a particular component of a farm is reached. Test Results The following tables show the test results of Excel Services dans Microsoft SharePoint Server For each group of tests, only certain specific variables are changed to show the progressive effect on farm performance. Note that all the tests reported on in this article were conducted with think or wait time (think time equals 10 seconds between user actions). This differs from the capacity planning results for other parts of SharePoint Server For information about Excel Services bottlenecks, see the Common bottlenecks and their causes section in this article. Overall Scale The table here summarizes the effect of adding additional Web Front-End and dedicated Services de calcul Excel computers to the farm. These throughput numbers are specifically for the Services de calcul Excel computers, and do not reflect the effect on the overall farm. 303

304 Topology Baseline Maximum (RPS) Baseline Recommended (RPS) 1x x x x x x x x x

305 305

306 Recommended Results The following chart shows our results for recommended sustainable throughput. 306

307 307

308 The previous chart shows that there is overhead associated with adding Web front-end computers to the farm. However, this is offset as Services de calcul Excel computers are added. A single Web front-end became the bottleneck after adding two additional Services de calcul Excel computers. This Web front-end bottleneck reversed any benefit that was gained from the additional capacity of adding a second and third Services de calcul Excel computer. Also notice that three Web front-end computers did not add any more throughput, as Services de calcul Excel became the limiting factor. 308

309 309

310 Notice in the previous chart that as Web front-end computers are added, the CPU load on each computer is reduced significantly. Note too, that with two Web front-end computers and three Services de calcul Excel computers, the CPU load is reaching the maximum seen for a single Web front-end computer. This implies that adding another Services de calcul Excel computer would make the Web front-end tier the limiting factor. Remember that these results are for the recommended load. This is why the CPU load is maxing out at around 35% instead of at an increased level. Maximum Results The following chart shows our results for maximum peak throughput. 310

311 311

312 Similar to our recommended results, we see that a single Web front-end computer is the limiting factor as we add a second and third Services de calcul Excel computer. Also notice that exactly as with the recommended results, adding a third Web front-end computer does not add to throughput as Services de calcul Excel is the limiting factor after the second Web front-end computer is added. 312

313 313

314 The results in the previous chart show that multiple Web front-end computers do not become as heavily loaded as a single Web front-end computer configuration. This indicates that the Services de calcul Excel computers are the bottleneck after the second Web front-end computer is added. Detailed Results This section shows details for the recommended and maximum results obtained in our tests. Recommended Results The following tables show the recommended results of our tests. Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 Client Successful RPS Client Response Time (sec.) TPS Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 % CPU (average over all Web Frontend computers Services de 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 calcul Excel Tier % CPU (average over all Services de calcul Excel

315 Services de 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 calcul Excel Tier computers) Peak Private Bytes (maximum over all Services de calcul Excel computers) 5.94E E E E E E E E E+09 Maximum Results The following tables show the maximum results of our tests. Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 Client Successful RPS Client Response Time (sec.) TPS Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 % CPU (average over all Web Frontend computers 315

316 Services de calcul Excel Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 % CPU (average over all Services de calcul Excel computers) Peak Private Bytes (maximum over all Services de calcul Excel computers) 5.91E E E E E E E E E+09 Scale Up Test results We also measured the effect of adding CPUs and memory to the Services de calcul Excel tier. For these tests, a 1x1 topology was used. 316

317 Our results in the previous chart show that adding additional CPUs was helpful but did not significantly affect the overall throughput. 317

318 318

319 The red zone line in the previous chart shows however, that adding memory does have a significant effect on throughput, especially at peak times. In this test, the same hardware was used throughout. However, the Maximum Private Bytes for the Excel Services process was limited. Since workbooks are kept in memory, the size of the workbooks has a significant effect on how many workbooks, and also how many users, any Services de calcul Excel computer can support. Recommendations This section provides general performance and capacity recommendations for hardware, Excel Services settings, common bottlenecks and troubleshooting. Note that Excel Services capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of the workbook and the complexity of calculations have the most effect. Our testing used representative sizes and complexities, but every workbook is different, and your capacity and performance depends on the specific size and complexity of the workbooks you use. Hardware Recommendations Excel Services uses standard hardware for both Web front-end servers and application servers, there are no special requirements. General SharePoint Server 2010 guidelines on CPU number, speed, and memory are applicable for computers in the Services de calcul Excel tier. Note that one of the first bottlenecks an Services de calcul Excel computer is likely to encounter is memory and this may require you to add resources. Before you do, we recommend that you test with a representative set of workbooks from your organization, as the size and complexity of workbooks have a large effect on how much more capacity the addition of memory is likely to have. To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for an Excel Services scenario: To provide for more user load, check the CPU and memory for the existing Excel Services application servers. Add additional memory if the CPU is not a concern, or add CPUs if memory is not a concern. If both memory and CPU are reaching their upper limits, additional Services de calcul Excel computers may be necessary. Add additional Services de calcul Excel or application servers until the point that the Web front-end servers become the bottleneck, and then add Web front-end servers as needed. In our tests, SQL Server was not a bottleneck. Excel Services does not make large demands on the database tier, as workbooks are read and written as whole documents, and also workbooks are held in memory throughout the user s session. Performance-Related Excel Services Settings 319

320 One of the ways to control the performance characteristics of Excel Services is to control how memory is used. Each of the global settings in the following list are set through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications > application Excel Services > Global Settings: Maximum Private Bytes By default, Services de calcul Excel will use up to 50% of the memory on the computer. If the computer is shared with other services, it may make sense to lower this number. If the computer is not being shared and is dedicated to Services de calcul Excel, and is indicating that memory may be a limiting factor, increasing this number may make sense. In any event, experimenting by adjusting this number can guide the administrator to making the necessary changes in order to better scale up. Memory Cache Threshold Services de calcul Excel will cache unused objects (for example, read-only workbooks for which all sessions have timed out) in memory. By default, Services de calcul Excel will use 90% of the Maximum Private Bytes for this purpose. Lowering this number can improve overall performance if the server is hosting other services in addition to Services de calcul Excel. Increasing this number increases the chances that the workbook being requested will already be in memory and will not have to be reloaded from the SharePoint Server content database. Maximum Unused Object Age By default, Services de calcul Excel will keep objects in the memory cache as long as possible. To reduce the Services de calcul Excel memory usage, in particular with other services that are running on the same computer, it may make more sense to impose a limit on how long objects are cached in memory. There are also settings available to control the maximum size of a workbook and the lifetime of a session, which in turn control how long a workbook is held in memory. These settings are associated with each trusted location and are not global. These settings can be set through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications > application Excel Services > Trusted Locations, and then edit the settings for each trusted location in the Workbook Properties section on the Edit Trusted File Location page. Maximum Workbook Size Maximum Chart or Image Size By default, Services de calcul Excel is limited to 10 MB or smaller workbooks and 1 MB or smaller charts/images. Obviously using larger workbooks and larger charts/images puts more strain on the available memory of the Services de calcul Excel tier computers. However, there may be users in your organization that need these settings to be increased for Services de calcul Excel to work with their particular workbooks. Session Timeout By decreasing the session time out, memory is made available for either the unused object cache or other services faster. 320

321 Volatile Function Cache Lifetime Volatile functions are functions that can change their value with each successive recalculation of the workbook, for example date/time functions, random number generators, and so on. Because of the load this could generate on the server, Services de calcul Excel does not recalculate these values for each recalculation, instead caching the last values for a short time period. Increasing this lifetime can reduce the load on the server. However, this depends on having workbooks that use volatile functions. Allow External Data Services de calcul Excel can draw on external data sources. However, the time that is required to draw upon the external source can be significant, with potentially a large amount of data returned. If external data is allowed, there are several additional settings that can help throttle the effect of this feature. Common bottlenecks and their causes During performance testing, several different common bottlenecks were revealed. Bottlenecks are defined as a state in which the capacity of a particular component of a farm is reached. This causes a plateau or decrease in farm throughput. The following table lists some common bottlenecks and describes their causes and possible resolutions. Troubleshooting performance and scalability Bottleneck Cause Resolution Services de calcul Excel Memory Services de calcul Excel CPU Excel Services holds each workbook in memory throughout the user's session. A large number of workbooks, or large workbooks, can cause Services de calcul Excel to consume all available memory causing the actually consumed "Private Bytes" to exceed "Maximum Private Bytes." Excel Services can depend on a large amount of processing in the application tier, depending on the number and complexity of workbooks. 321 Scale Up with more memory in the Services de calcul Excel tier computers, or Scale Out with the addition of more Services de calcul Excel computers. The choice will partly depend on if CPU is also reaching a maximum. Increase the number of CPUs and/or cores in the existing Services de calcul Excel computers, or add Services de calcul Excel

322 Bottleneck Cause Resolution Web server CPU usage When a Web server is overloaded with user requests, average CPU usage will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers. computers. This issue can be resolved in one of two ways. You can add Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding faster processors. Performance monitoring To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied. Front-end Web server The following table shows performance counters and processes to monitor for front-end Web servers in your farm. Performance Counter Apply to object Notes % Processor Time Processor (w3wp) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server computer that used the processor to execute 322

323 Performance Counter Apply to object Notes instructions. Private Bytes Process (w3wp) This value should not approach the Max Private Bytes set for w3wp processes. If it does, additional investigation is needed into what component is using the memory. Services de calcul Excel The following table shows performance counters and processes to monitor for application servers, or in this case Services de calcul Excel, within your farm. Performance Counter Apply to object Notes % Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server that used the processor to execute instructions. % Processor Time Processor (w3wp) The Services de calcul Excel runs within its own w3wp process, and it will be obvious which w3wp process this is as it will be getting the bulk of the CPU time. 323

324 Performance Counter Apply to object Notes Average Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging. Private Bytes Process(w3wp) Excel Services caches workbooks in memory, until the user's session expires (the time out for which is configurable). If a large amount of data is being processed through the Services de calcul Excel, memory consumption for the Services de calcul Excel w3wp will increase. SQL Server As we have previously described, Excel Services is light on the SQL Server tier, as workbooks are read once into memory on the Services de calcul Excel tier during the user's session. Follow general SharePoint Server guidelines for monitoring and troubleshooting of the SQL Server tier. 324

325 Évaluer les besoins en performances et en capacité pour PerformancePoint Services Cet article décrit l impact de l utilisation de PerformancePoint Services sur les topologies exécutant Microsoft SharePoint Server Remarque : Il convient de noter que les chiffres spécifiques relatifs à la capacité et aux performances présentés dans cet article diffèreront des chiffres d un environnement du monde réel. Les chiffres présentés ici sont destinées à fournir un point de départ pour la conception d un environnement à l échelle appropriée. Une fois que vous avez terminé la conception initiale de votre système, testez la configuration pour déterminer si votre système prendra en charge les facteurs dans votre environnement. Dans cet article : Caractéristiques de la batterie de serveurs de test Résultats des tests Recommandations Pour obtenir des informations générales sur la planification de capacité et l exécution qui en résulte pour SharePoint Server 2010, voir Capacity management and sizing for SharePoint Server 2010 (en anglais). Caractéristiques de la batterie de serveurs de test Jeu de données Le jeu de données était constitué d un portail d entreprise créé à l aide de SharePoint Server 2010 et PerformancePoint Services et contenant un seul tableau de bord de taille moyenne. Ce tableau de bord contenait deux filtres liés à une carte de performance, deux 325

326 graphiques et une grille. Il était basé sur une source de données Microsoft SQL Server 2008 Analysis Services (SSAS) unique utilisant les exemples de bases de données AdventureWorks pour le cube SQL Server 2008 Analysis Services. Le tableau suivant décrit le type et la taille de chaque élément du tableau de bord. Nom Description Taille Filtre un Filtre de sélection de membre 7 membres de dimension Filtre deux Filtre de sélection de membre 20 membres de dimension Carte de performance Carte de performance 15 lignes de membres de dimension par 4 colonnes (2 indicateurs de performance clés) Graphique un Graphique en courbes 3 séries par 12 colonnes Graphique deux Graphique à barres empilées 37 séries par 3 colonnes Grille Grille analytique 5 lignes par 3 colonnes Le tableau de bord de taille moyenne utilisait le modèle Deux colonnes avec en-tête et les tailles des éléments de tableau de bord étaient configurées pour un dimensionnement automatique ou avaient pour valeur un pourcentage spécifique du tableau de bord. Chaque élément du tableau de bord était affiché avec une hauteur aléatoire et une largeur comprise entre 400 et 500 pixels afin de simuler les différences de taille de fenêtre de navigateur Web. Il est important de modifier la hauteur et la largeur de chaque élément de tableau de bord car le rendu des graphiques dépend de la taille des fenêtres de navigateurs Web. Scénarios et processus de test Cette section définit les scénarios de test et traite du processus de test utilisé pour chaque scénario. Vous trouverez des informations détaillées telles que les résultats des tests et les paramètres spécifiques dans les sections «Résultats des tests» plus loin dans cet article. 326

327 Nom du test Afficher un tableau de bord et modifier de manière aléatoire l un des deux filtres à cinq reprises, avec une pause de 15 secondes entre les interactions. Afficher un tableau de bord, sélectionner un graphique et le développer et le réduire à cinq reprises, avec une pause de 15 secondes entre les interactions. Afficher un tableau de bord, sélectionner une grille et la développer et la réduire à cinq reprises, avec une pause de 15 secondes entre les interactions. Description du test 1. Afficher le tableau de bord. 2. Sélectionner l un des deux filtres, sélectionner de manière aléatoire une valeur de filtre et attendre le réaffichage du tableau de bord. 3. Répétez l opération à quatre reprises, en sélectionnant de manière aléatoire l un des deux filtres et une valeur de filtre aléatoire. 1. Afficher le tableau de bord. 2. Sélectionner un membre aléatoire sur un graphique et le développer. 3. Sélectionner un autre membre aléatoire sur le graphique et le réduire. 4. Sélectionner un autre membre aléatoire sur la grille et la développer. 5. Sélectionner un autre membre aléatoire sur la grille et la réduire. 1. Afficher le tableau de bord. Sélectionner un membre aléatoire sur une grille et développer le membre. 2. Sélectionner un autre membre aléatoire sur la grille et la développer. 3. Sélectionner un autre membre aléatoire sur la grille et la réduire. 4. Sélectionner un autre membre aléatoire sur la grille et la développer. Une combinaison de tests unique a été utilisée, constituée des pourcentages de tests démarrés suivants. 327

328 Nom du test Afficher un tableau de bord et modifier de manière aléatoire l un des deux filtres à cinq reprises. Afficher un tableau de bord, sélectionner un graphique et le développer et le réduire à cinq reprises. Afficher un tableau de bord, sélectionner une grille et la développer et la réduire à cinq reprises. Combinaison de tests 80 % 10 % 10 % Les outils de test de charge de Microsoft Visual Studio 2008 ont été utilisés afin de créer un ensemble de tests Web et de tests de charge simulant des opérations d utilisateurs (modification de filtres et navigation sur des grilles et des graphiques). Les tests utilisés dans cet article contenait une distribution normales de pauses de 15 secondes, également appelées «temps de réflexion», entre les interactions et un temps de réflexion de 15 secondes entre les itérations de tests. Une charge a été appliquée afin de produire un temps de réponse moyen de deux secondes pour l affichage d une carte de performance ou d un rapport. Le temps de réponse moyen a été mesuré sur une période de 15 minutes après un délai de préchauffage initial de 10 minutes. Chaque nouvelle itération de test sélectionne un compte d utilisateur distinct parmi un pool de cinq mille comptes et une adresse IP aléatoire (à l aide de la commutation IP de Visual Studio) parmi un pool d environ adresses. La combinaison de tests a été exécutée à deux reprises sur le même tableau de bord de taille moyenne. Lors de la première exécution, l authentification de source de données a été configurée de façon à utiliser le Compte de service autonome, qui utilise un compte commun pour demander les données. Les résultats des données sont identiques pour plusieurs utilisateurs et PerformancePoint Services peut utiliser la mise en cache afin d améliorer les performances. Lors de la seconde exécution, l authentification de source de données a été configurée de façon à utiliser l identité par utilisateur et le cube SQL Server Analysis Services a été configuré de façon à utiliser la sécurité dynamique. Dans cette configuration, PerformancePoint Services utilise l identité de l utilisateur pour demander les données. Les résultats des données pouvant être différents, aucune mise en cache ne peut être partagée par les utilisateurs. Dans certains cas, la mise en cache pour l identité par utilisateur peut être partagée si la sécurité dynamique Analysis Services n est pas configurée et que les rôles Analysis Services, auxquels les utilisateurs et groupes Microsoft Windows sont assignés, sont identiques. Configuration matérielle et topologie Matériel de laboratoire 328

329 Pour fournir un niveau élevé de détails de résultats de tests, plusieurs configurations de batterie de serveurs ont été utilisées lors des tests. Ces configurations comprenaient de un à trois serveurs Web, de un à quatre serveurs d applications et un serveur de bases de données unique exécutant Microsoft SQL Server Une installation d entreprise par défaut de SharePoint Server 2010 a été effectuée. Le tableau suivant indique le matériel spécifique utilisé lors des tests. Serveur Web Serveur d applications Ordinateur exécutant SQL Server Ordinateur exécutant Analysis Services Processeur(s) 2,66 GHz 2,66 GHz 2,66 GHz 2,4 GHz RAM 16 Go 32 Go 16 Go 64 Go Système d exploitation Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise Carte réseau 1x1 gigabit 1x1 gigabit 1x1 gigabit 1x1 gigabit Authentification NTLM et Kerberos NTLM et Kerberos NTLM et Kerberos NTLM et Kerberos Une fois la batterie étendue avec plusieurs serveurs Web, un système d équilibrage de la charge matérielle a été utilisé afin d équilibrer la charge utilisateur sur plusieurs serveurs Web à l aide de l affinité d adresse source. L affinité d adresse source enregistre l adresse IP source des demandes entrantes et l hôte de service sur lequel leur charge a été équilibrée, et elle dirige toutes les transactions ultérieures vers le même hôte. Topologie La topologie de départ était constituée de deux serveurs physiques, l un agissant comme serveur Web et serveur d applications, l autre assumant la fonction de serveur de bases de données. Cette topologie de départ est considérée comme une topologie à deux ordinateurs (ou 2M, c est-à-dire 2 machines), ou encore comme topologie «1 par 0 par 1» (où le nombre de serveurs Web dédiés est indiqué en premier, suivi du nombre de serveurs d applications dédiés, puis du nombre de serveurs de bases de données). Les serveurs Web sont également appelés serveurs Web frontaux (ou WFE, Web Front End) plus loin dans ce document. La charge a été appliquée jusqu à ce que des facteurs de limitation soient rencontrés. En règle général, le facteur de limitation sur le serveur Web ou le serveur d applications était le processeur. Des ressources ont ensuite été ajoutées afin d annuler les effets de cette limite. Les facteurs de 329

330 limitation et les topologies différaient sensiblement selon la configuration de l authentification de source de données (Compte de service autonome ou identité par utilisateur avec sécurité du cube dynamique). Résultats des tests Les résultats des tests contenaient trois mesures importantes pour aider à définir la capacité de PerformancePoint Services. Mesure Nombre d utilisateurs Demandes par seconde Affichages par seconde Description Nombre total d utilisateurs signalé par Visual Studio. Nombre total de demandes par seconde signalé par Visual Studio, y compris les demandes de fichiers statiques tels que les images et feuilles de style. Nombre total d affichages pouvant être effectués par PerformancePoint Services. Un affichage représente tout filtre, carte de performance, grille ou graphique affiché par PerformancePoint Services ou toute demande Web envoyée à l URL de service de rendu qui contient RenderWebPartContent ou CreateReportHtml. Pour en savoir plus sur CreateReportHtml et RenderWebPartContent, voir la Spécification du protocole RenderingService PerformancePoint Services (éventuellement en anglais) ( Les journaux IIS peuvent être analysés à la recherche de ces demandes, afin d aider à planifier la capacité de PerformancePoint Services. Par ailleurs, l utilisation de cette mesure génère un chiffre qui dépend beaucoup moins de la composition du tableau de bord. Un tableau de bord contenant deux affichages peut être comparé à un tableau de bord en contenant

331 Conseil : Lorsque vous utilisez une source de données configurée de façon à utiliser l authentification de Compte de service autonome, la règle relative au rapport des serveurs dédiés est de un serveur Web pour deux serveurs d applications exécutant PerformancePoint Services. Conseil : Lorsque vous utilisez une source de données configurée de façon à utiliser l authentification par utilisateur, la règle relative au rapport des serveurs dédiés est de un serveur Web pour au moins quatre serveurs d applications exécutant PerformancePoint Services. Avec les topologies comprenant plus de quatre serveurs d applications, il est probable que le goulet d étranglement soit le serveur Analysis Services. Analysez le processeur et la durée de requête de votre serveur Analysis Services afin de déterminer s il est nécessaire de faire monter en puissance Analysis Services avec plusieurs serveurs. Tout prolongement de la durée de requête sur le serveur Analysis Services accroît de manière significative le temps de réponse moyen de PerformancePoint Services au-delà du seuil souhaité (deux secondes). Les tableaux qui suivent fournissent une synthèse des résultats de tests pour l authentification de Compte de service autonome et l authentification par utilisateur lors de l extension de deux à sept serveurs. Vous trouverez des résultats détaillés incluant des compteurs de performance supplémentaires plus loin dans ce document. Synthèse de l authentification de Compte de service autonome Topologie (WFE x APP x SQL) Utilisateurs Demandes par seconde Affichages par seconde 2M (1x0x1) M (1x1x1) M (1x2x1)

332 Topologie (WFE x APP x SQL) Utilisateurs Demandes par seconde Affichages par seconde 5M (1x3x1) M (2x3x1) M (2x4x1) Synthèse de l authentification par utilisateur Topologie (WFE x APP x SQL) Utilisateurs Demandes par seconde Affichages par seconde 2M (1x0x1) M (1x1x1) M (1x2x1) M (1x3x1) Topologies 2M et 3M Afin de mieux comprendre le coût matériel par transaction et la courbe de temps de réponse, les tests de charge ont été exécutés avec quatre charges utilisateur d intensité croissante, jusqu à la charge utilisateur maximale pour les topologies 2M et 3M. Authentification de Compte de service autonome Nombre d utilisateurs Moyenne de processeurs WFE/APP 19,20 % 57,70 % 94,00 % 96,70 % 332

333 Nombre d utilisateurs Demandes par seconde Affichages par seconde 10,73 31,72 49,27 49,67 Temps de réponse moyen (sec) 0,12 0,15 0,

334 Authentification par utilisateur 334

335 Nombre d utilisateurs Moyenne de processeurs WFE/APP 30,80 % 61,30 % 86,50 % 93,30 % Demandes par seconde Affichages par seconde 10,3 19,32 26,04 27,75 Temps de réponse moyen (sec) 0,28 0,45 0,

336 Résultats pour la batterie 3M (1x1x1) Authentification de Compte de service autonome 336

337 Nombre d utilisateurs Demandes par seconde Affichages par seconde Temps de réponse moyen (sec) 0,12 0,18 0,65 2 Moyenne de processeurs WFE 11 % 28 % 43 % 46 % Octets privés WFE max du processus de travail W3WP Internet Information Services (IIS) SharePoint Server. 0,7 Go 1,4 Go 2,0 Go 2,4 Go Moyenne de processeurs APP 25 % 62 % 94 % 95 % Octets privés APP max de W3WP PerformancePoint Services 5,9 Go 10,8 Go 14,1 Go 14,6 Go 337

338 Authentification par utilisateur 338

339 Nombre d utilisateurs Demandes par seconde Affichages par seconde Temps de réponse moyen (sec) 0,28 0,48 0,91 2 Moyenne de processeurs WFE 5 % 12 % 17 % 19 % Octets privés WFE max de W3WP SharePoint Server 0,78 Go 1,3 Go 1,6 Go Moyenne de processeurs APP 25 % 57 % 81 % 81 % 1,9 Go Octets privés APP max de W3WP PerformancePoint Services 19 Go 20,1 Go 20,5 Go 20,9 Go 339

340 Résultats 4M+ pour l authentification de Compte de service autonome À partir de la topologie 4M, une charge a été appliquée afin de produire un temps de réponse moyen de deux secondes pour l affichage d une carte de performance ou d un rapport. Ensuite, un serveur supplémentaire a été ajouté afin d éliminer le facteur de limitation 340

341 (toujours le processeur sur le serveur Web ou le serveur d applications), puis la combinaison de tests a été réexécutée. Cette logique a été répétée jusqu à atteindre un total de sept serveurs. 4M (1x2x1) 5M (1x3x1) 6M (2x3x1) Nombre d utilisateurs Demandes par seconde Affichages par seconde Moyenne de processeurs WFE 77 % 63 % 54 % 73 % 7M (2x4x1) Octets privés WFE max de W3WP SharePoint Server 2,1 Go 1,7 Go 2,1 Go 2,0 Go Moyenne de processeurs APP 83 % 94 % 88 % 80 % Octets privés APP max de W3WP PerformancePoint Services 16 Go 12 Go 15 Go 15 Go Résultats 4M+ pour l authentification par utilisateur Les mêmes tests ont été répétés pour une source de données configurée pour l authentification par utilisateur. Notez que l ajout d un serveur d applications afin de créer une topologie à quatre serveurs d applications n a pas augmenté le nombre d utilisateurs ou de demandes par secondes pouvant être pris en charge par PerformancePoint Services, à cause des délais de requêtes générés par Analysis Services. 341

342 3M (1x1x1) 4M (1x2x1) 5M (1x3x1) User count Demandes par seconde Affichages par seconde Moyenne de processeurs WFE 19 % 24 % 26 % 12 % 6M (1x4x1) Octets privés WFE max de W3WP SharePoint Server 2,1 Go 1,9 Go 1,9 Go 1,5 Go Moyenne de processeurs APP 89 % 68 % 53 % 53 % Octets privés APP max de W3WP PerformancePoint Services 20 Go 20 Go 20 Go 20 Go Processeur Analysis Services 17 % 44 % 57 % 68 % 342

343 Recommandations Recommandations relatives au matériel 343

344 Les compteurs de mémoire et de processeur mentionnés dans les tableaux de tests doivent être utilisés afin de déterminer la configuration matérielle requise pour une installation de PerformancePoint Services. Pour les serveurs Web, PerformancePoint Services utilise la configuration matérielle SharePoint Server 2010 recommandée. Il se peut que la configuration matérielle requise pour les serveurs d applications doive être modifiée lorsque PerformancePoint Services consomme une grande quantité de mémoire. Cela se produit lorsque des sources de données sont configurées avec l authentification par utilisateur ou lorsque le serveur d applications exécute de nombreux tableaux de bord avec de longs délais d attente de source de données. Le serveur de bases de données n est pas devenu un goulet d étranglement dans les tests et l utilisation maximale du processeur a atteint une pointe de 31 % avec le tableau de bord authentifié avec le Compte de service autonome 7M. Les définitions de contenu PerformancePoint Services telles que les rapports, cartes de performance et indicateurs de performance clés sont stockées dans des listes SharePoint et mis en cache en mémoire par PerformancePoint Services, ce qui réduit la charge sur le serveur de bases de données. Consommation de mémoire PerformancePoint Services peut consommer de grandes quantités de mémoire dans certaines configurations, c est pourquoi il est important d analyser l utilisation de la mémoire du pool d applications PerformancePoint Services. PerformancePoint Services met en cache plusieurs éléments en mémoire, notamment des résultats de requêtes Analysis Services et d autres sources de données pendant toute la durée de vie du cache de source de données (par défaut, 10 minutes). Lorsque vous utilisez une source de données configurée pour l authentification de Compte de service autonome, ces résultats de requête sont stockés une fois et partagés par plusieurs utilisateurs. En revanche, lorsque vous utilisez une source de données configurée pour l authentification par utilisateur et la sécurité de cube dynamique Analysis Services, les résultats de requête sont stockés une fois par utilisateur par affichage (il s agit donc d une combinaison «par filtre».) L API de cache sous-jacente utilisée par PerformancePoint Services est l API de cache ASP.NET. L avantage majeur offert par l utilisation de cette API est le fait qu ASP.NET gère le cache et supprime les éléments en fonction des limites de mémoire, afin d éviter les erreurs d insuffisance de mémoire. Une fois ces limites atteintes, PerformancePoint Services générait tout de même ces affichages, mais les temps de réponse augmentaient de manière significatives durant la brève période durant laquelle ASP.NET supprimait les entrées mises en cache. Le compteur de performance «Applications ASP.NET \ Suppressions d API du cache» du pool d applications hébergeant PerformancePoint Services peut être utilisé afin d analyser les suppressions du cache ASP.NET qui se produisent suite à une pression sur la mémoire. Si ce compteur est supérieur à zéro, examinez le tableau suivant afin de trouver une solution. Problème L utilisation du processeur de serveur d applications est faible et Solution Ajouter davantage de mémoire physique ou limiter la mémoire du 344

345 Problème d autres services s exécutent sur le serveur d applications Solution cache ASP.NET. L utilisation du processeur de serveur d applications est faible et seul Si cela est acceptable, configurer les paramètres du cache PerformancePoint Services s exécute sur le serveur d applications. ASP.NET de sorte que celui-ci utilise davantage de mémoire, ou ajouter de la mémoire. L utilisation du processeur de serveur d applications est élevée. Ajouter un autre serveur d applications. Une source de données configurée de façon à utiliser l authentification par utilisateur peut partager des résultats de requêtes et des entrées de cache si les ensembles d appartenances de rôles Analysis Services des utilisateurs sont identiques et si la sécurité de cube dynamique n est pas configurée. Il s agit d une nouvelle fonctionnalité de PerformancePoint Services dans Microsoft SharePoint Server Par exemple, si l utilisateur A est dans les rôles 1 et 2, que l utilisateur B est dans les rôles 1 et 2, et que l utilisateur C est dans les rôles 1, 2 et 3, seule les utilisateurs A et B partagent des entrées de cache. Si la sécurité de cube dynamique est activée, les utilisateurs A, B et C ne partagent pas d entrées de cache. Analysis Services Lors des tests de PerformancePoint Services avec l authentification par utilisateur, deux propriétés Analysis Services ont été modifiées afin d améliorer les performances de débit multi-utilisateur. Le tableau suivant montre les propriétés qui ont été modifiées et indique la nouvelle valeur de chaque propriété. Propriété Analysis Services Valeur Mémoire \ HeapTypeForObjects 0 Mémoire \ MemoryHeapType 2 Ces deux paramètres de mémoire configurent Analysis Services de façon à utiliser le segment Windows plutôt que le segment Analysis Services. Avant de modifier ces propriétés et durant l ajout de la charge utilisateur, les temps de réponse ont augmenté sensiblement, passant de 0,2 seconde à plus de 30 secondes, tandis que les valeurs de processeurs sur les serveurs d applications, serveurs Web et 345

346 serveurs Analysis Services sont restées faibles. Afin de résoudre ce problème, la durée de requête a été recueillie à l aide de vues de gestion dynamique Analysis Services, ce qui a montré une augmentation des durées de requêtes allant de 10 millisecondes à 5000 millisecondes. Ces résultats ont entraîné une modification des paramètres de mémoire mentionnés ci-dessus. Il convient de noter que bien que cela ait augmenté sensiblement le débit, d après l équipe Analysis Services, la modification de ces paramètres présente un coût faible mais mesurable sur les requêtes d utilisateur unique. Avant de modifier des propriétés Analysis Services, consultez le Livre blanc SQL Server 2008 : guide des performances d Analysis Services (éventuellement en anglais) ( afin de connaître les meilleures pratiques pour l amélioration des performances de débit multi-utilisateur. Goulets d étranglement courants et leurs causes Durant les tests de performances, plusieurs goulets d étranglement courants ont été révélés. Un goulet d étranglement est une condition dans laquelle la capacité d un composant spécifique d une batterie est atteinte, ce qui provoque une stabilisation ou une diminution du débit de la batterie. Si une utilisation élevée du processeur a été rencontrée comme goulet d étranglement, des serveurs supplémentaires ont été ajoutés afin d éliminer ce goulet d étranglement. Le tableau suivant répertorie certains goulets d étranglement courants et fournit des résolutions possibles en supposant que l utilisation du processeur était faible et ne constituait pas le goulet d étranglement. Goulet d étranglement possible Cause et élément à analyser Résolution Performance du segment mémoire Analysis Services Par défaut, Analysis Services Modifier Analysis Services de façon à utiliser le segment Windows. Pour obtenir utilise son propre segment des instructions, voir la section «Analysis Services» plus haut dans cet article et le mémoire plutôt que le segment Livre blanc SQL Server 2008 : guide des performances d Analysis Services Windows, ce qui procure de (éventuellement en anglais) médiocres performances de ( débit multi-utilisateur. Examinez les durées de requêtes Analysis Services à l aide de vues de gestion dynamique afin de déterminer si les durées de requêtes augmentent avec la charge utilisateur et si 346

347 Goulet d étranglement possible Threads de requêtes et de traitement Analysis Services Cause et élément à analyser l utilisation du processeur par Analysis Services est faible. Par défaut, Analysis Services limite le nombre de threads de requêtes et de traitement pour les requêtes. Les requêtes de longue durée et les charges utilisateur élevées pourraient utiliser tous les threads disponibles. Analysez les threads inactifs et les compteurs de performance de file d attente de travaux dans la catégorie MSAS 2008 :Threads. Résolution Augmenter le nombre de threads accessibles aux requêtes et aux processus. Pour obtenir des instructions, voir la section relative à Analysis Services et le Livre blanc SQL Server 2008 : guide des performances d Analysis Services (éventuellement en anglais) ( Mémoire des serveurs d applications PerformancePoint Services met en cache les résultats des requêtes Analysis Services et aux sources de données pendant toute la durée de vie du cache de source de données. Ces éléments peuvent consommer une grande quantité de mémoire. Analysez le compteur de performance Applications ASP.NET \ Suppressions d API du cache du pool d applications PerformancePoint Services afin de déterminer si des Ajouter de la mémoire ou augmenter les limites de mémoire cache ASP.NET par défaut. Pour une discussion supplémentaire, voir la section Consommation de mémoire plus haut dans ce document. Voir également l article intitulé Paramètres d éléments de cache ASP.NET ( et le billet de blog de Thomas Marquardt Historique des limites de mémoire cache ASP.NET (éventuellement en anglais) ( 347

348 Goulet d étranglement possible Cause et élément à analyser suppressions du cache sont forcées par ASP.NET à cause d une insuffisance de mémoire. Résolution Paramètres de limitation WCF PerformancePoint Services est Si nécessaire, modifier le comportement de limitation WCF (Windows implémenté en tant que service Communication Foundation). Voir les comportement de limitation de service WCF WCF. WCF limite le nombre ( et le billet de blog de maximal d appels simultanés en Wenlong Dong sur la limitation des requêtes WCF et l évolutivité des serveurs guise de comportement de (éventuellement en anglais) limitation de service. Bien que ( les requêtes de longue durée puissent atteindre ce goulet d étranglement, cela est assez rare. Analysez les appels de compteur de performance WCF / Modèle de service non traités pour PerformancePoint Services et comparez ce chiffre au nombre maximal actuel d appels simultanés. Analyse des performances Pour vous aider à déterminer le moment où une montée en puissance parallèle ou par unité du système est nécessaire, utilisez des compteurs de performance afin d analyser l intégrité du système. PerformancePoint Services est un service WCF ASP.NET qui peut être analysé à l aide des mêmes compteurs de performance que tout autre service WCF ASP.NET. Utilisez également les informations fournies dans les tableaux suivants afin d identifier les compteurs de performance supplémentaires à analyser et les processus auxquels ces compteurs de performance doivent être appliqués. 348

349 Compteur de performance Instance de compteur Remarques Applications ASP.NET / Suppressions Pool d applications d API du cache PerformancePoint Services MSAS 2008 :Threads / imitation des requêtes WCF et l évolutivité des serveurs S/O Si la valeur est supérieure à zéro, examinez la «Consommation de mémoire». Si la valeur est égale à zéro, consultez la section «Analysis Services» et le Livre blanc SQL Server 2008 : Guide des performances d Analysis Services (éventuellement en anglais) ( MSAS 2008 :Threads / Longueur de S/O Si la valeur est supérieure à zéro, consultez la section «Analysis Services» la file d attente des travaux du pool de requêtes et le Livre blanc SQL Server 2008 : Guide des performances d Analysis Services (éventuellement en anglais) ( MSAS 2008 :Threads / Threads inactifs du pool de traitement S/O Si la valeur est supérieure à zéro, consultez la section «Analysis Services» et le Livre blanc SQL Server 2008 : Guide des performances d Analysis Services (éventuellement en anglais) ( MSAS 2008 :Threads / Longueur de S/O Si la valeur est supérieure à zéro, consultez la section «Analysis Services» la file d attente des travaux du pool de traitement et le Livre blanc SQL Server 2008 : Guide des performances d Analysis Services (éventuellement en anglais) ( WCF CountersServiceModelService (*)\Appels non traités Instance de service PerformancePoint Si la valeur est supérieure à zéro, voir Limitation des requêtes WCF et évolutivité des serveurs (éventuellement en anglais) ( 349

350 Voir aussi Autres ressources Plan for PerformancePoint Services (SharePoint Server 2010) 350

351 Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en anglais) Initial capacity testing was performed for a simulated midsized deployment of Microsoft SharePoint Server 2010 and other applications that included 30,000 SharePoint entities. This article describes the results of the capacity testing activities and contains guidance on capacity management for the Web Analytics service application in SharePoint Server In SharePoint Server 2010, the Web Analytics service application enables you to collect, report, and analyze the usage and effectiveness of SharePoint Server 2010 sites. Web Analytics features include reporting, Web Analytics workflow, and Web Analytics Web Part. For more information, see Reporting and usage analysis overview. The aspects of capacity planning that are described in this article include the following: Description of the architecture and topology. Capacity planning guidelines based on the key factors such as total expected traffic and number of SharePoint components. Description of the other factors that affect the performance and capacity requirements. Before you continue to read this article, make sure that you understand key concepts related to SharePoint Server 2010 capacity management. The resources that are listed in this section can help you learn about frequently used terms and get an overview of the recommended approach to capacity management. These resources can also help you use the information that is provided in this article more effectively. For more conceptual information about performance and capacity management, see the following articles: Gestion de la performance et de la capacité (SharePoint Server 2010) Capacity management and sizing for SharePoint Server 2010 (en anglais) In this article: Introduction Hardware specifications and topology Capacity requirements 351

352 Introduction Overview As part of SharePoint Server 2010, the Web Analytics service application is a set of features that you can use to collect, report, and analyze the usage and effectiveness of a SharePoint Server 2010 deployment. You can organize SharePoint Web Analytics reports into three main categories: Traffic Search Inventory SharePoint Web Analytics reports are typically aggregated for various SharePoint entities, such as sites, site collections, and Web applications for each farm. To view an architectural overview of the Web Analytics service application in a SharePoint deployment, see Architectural overview later in this article. The Web Analytics shared service requires resources primarily at the application server and database server level. This article does not cover the Web Server layer capacity planning, because the Web Analytics service s capacity requirements are minimal at this level. This article contains the capacity requirements for several application servers and Microsoft SQL Server based computers, according to the following criteria: Total expected site traffic (clicks, search queries, ratings). Number of SharePoint components (Site, Site Collection, and Web Application) for each farm. Other less significant factors which can affect the capacity requirements are summarized in Other factors later in this article. Architectural overview The following diagram (Figure 1) shows the flow of the site usage data from a Web browser to the analytics databases, and then back to the Web browser as reports. The usage data is logged to the usage files on the Web servers. The usage timer job calls the Logging Web Service to submit the raw data from the usage files. The Logging Web Service writes it to the staging database, where the raw data is stored for seven days (this is not configurable). The Web Analytics components Log Batcher and User Behavior Analyzer clean and process the raw data on the staging database. The Report Consolidator runs one time every 24 hours. The Report Consolidator aggregates the raw data from the staging database on various dimensions, and then writes it to the reporting database. The aggregated data is stored in the reporting database for a default period of 25 months (this is configurable). 352

353 353

354 Figure 1. SharePoint Server 2010 Web Analytics architectural overview The performance of the Logging Web Service primarily depends on the number of application servers. (Scaling out is available for the application servers.) The performance of the Log Batcher and User Behavior Analyzer depends primarily on the analytics staging database. The Read and Write activities that are performed by all the different components can cause the analytics staging database to slow down the process. (Scaling out is available for the staging database.) The performance of the Report Consolidator also primarily depends on the reporting database. (Scaling out of reporting database is not supported.) Hardware specifications and topology This section provides detailed information about the hardware, software, topology, and configuration of a case study environment. Hardware Remarque : This environment is scaled to accommodate prerelease builds of SharePoint Server 2010 and other products. Therefore, the deployed hardware has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Gestion de la performance et de la capacité (SharePoint Server 2010). Web servers This article does not cover the Web server layer capacity planning, because the Web Analytic service s capacity requirements are minimal at this level. Application servers The following table describes the configuration of each application server. Based on the site traffic and the number of SharePoint components that are involved, users will need one or more application servers. Application server Processors 354 Minimum requirement 4 quad 2.33 GHz

355 Application server RAM Operating system Size of the SharePoint drive Minimum requirement 8 GB Windows Server 2008, 64 bit 300 GB Number of network adapters 1 Network adapter speed Authentication Load balancer type Software version 1 GB NTLM SharePoint Load Balancer SharePoint Server 2010 (prerelease version) Services running locally Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search Web Analytics Data Processing Service Web Analytics Web Service Database servers The following table describes the configuration of each database server. Instances of SQL Server were required for both the staging and reporting databases. 355

356 Database server Processors RAM Operating system Disk size Minimum requirement 4 quad 2.4 GHz 32 GB Windows Server 2008, 64-bit 3 terabytes Remarque : Although we used this disk size for our capacity testing, your environment will likely require a much larger disk size to support Web Analytics. Number of network adapters 1 Network adapter speed 1 GB Authentication NTLM Software version SQL Server 2008 Topology The following diagram (Figure 2) shows the Web Analytics topology. 356

357 Figure 2. Web Analytics topology 357

358 Capacity requirements Testing methodology This section presents the capacity requirements with regard to the total amount of site traffic (this is measured by number of clicks, search queries, and ratings) per day that can be supported by different numbers of application servers and SQL Server based computers. The numbers presented currently are for a midsize SharePoint deployment that has about 30,000 SharePoint entities. The Web Analytics shared service aggregates the data for each day. Therefore, the data volume that is presented corresponds to the total number of records (this is measured by number of clicks, search queries, and ratings) that the SharePoint farm is expected to receive each day. This section provides diagrams that show the daily site traffic that can be supported by one, two, or three application servers (Figure 3) and the daily site traffic that can be supported that corresponds to the various database configurations (Figure 4). In the diagrams, data is shown by using two colors: Green Green values indicate the safe limit for the site traffic that can be processed for the corresponding number of application servers and SQL Server based computers. Yellow Yellow values indicate the expected limit for the site traffic that can be processed for the corresponding number of application servers and SQL Server based computers. The green and yellow values are estimates that are based on two key factors: Total site traffic, measured by number of page view clicks, search queries, and ratings. Number of SharePoint entities, such as sites, site collections, and Web applications, for each farm. The estimates also depend on other properties of the data and the data retention period in the reporting database. For testing, the other properties of the data were maintained as constant as described in Dataset description later in this section. Also, in smaller SharePoint deployment environments, you can share the application servers and SQL Server based computers together with other SharePoint services and databases. This article contains information about the capacity of the application servers and the SQL Server based computers that are in a test environment so that the Web Analytics shared service is the only major service that is running on the servers. The actual performance results for environments that actively use other shared services at the same time running might vary. To determine the capacity requirements for your environment, make sure that you estimate the expected daily site traffic and the number of components that you might use for a SharePoint deployment. Then, the number of application servers and SQL Server based computers should be estimated independently, as shown in Figure 3 and Figure 4. Dataset description 358

359 The dataset that was selected for the test environment is a mid-sized dataset that has approximately 30,000 SharePoint components, which includes all web applications, site collections, and sites. Other characteristics of the data that were kept constant in the environment are also listed in the following table. Dataset characteristics Value Number of SharePoint components 30,000 Number of unique users 117,000 Number of unique queries 68,000 Number of unique assets 500,000 Data size in the reporting database 200 GB The total site traffic, measured by number of clicks, search queries, and ratings, was increased as part of this case study to establish the number of records that can be supported by the corresponding topology. Important : Some typically used topologies generally exceed the capacity planning guidance. Those topologies include the following: Team sites My Site Web sites Self-provisioning portals If you anticipate that you might exceed the capacity planning guidelines, we recommend that you turn off the Web Analytics service application. For more information about how to turn off a service application, see Starting or stopping a service. Application servers The following diagram (Figure 3) shows the daily site traffic that can be supported by one, two, or three application servers. The site traffic is represented in millions of records (each click, search query, or rating makes up a record) each day. The yellow line represents the 359

360 expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records. 360

361 Figure 3. Daily site traffic vs. the application servers topology 361

362 The application servers are not very CPU-intensive or memory intensive. Thus, the CPU and the memory usage are not summarized for this section. SQL Server based computers The following diagram (Figure 4) shows the daily site traffic that can be supported that corresponds to the following configurations: One instance of SQL Server for both staging and reporting databases (1S+R). Two instances of SQL Server, one staging database and one reporting database (1S1R). Three instances of SQL Server, two staging databases and one reporting database (2S1R). The site traffic is represented in millions of records (each click, search, or rating makes up a record) each day. The yellow line represents the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records. 362

363 Figure 4. Daily site traffic vs. SQL Server topology 363

364 The following table summarizes the CPU and memory usage of the various components on the instances of SQL Server that are hosting the staging database and the reporting database. Configuration 1S+R 1S1R 1S1R 2S1R 2S1R Total sum of percentage of processor time for 8 processor computer Staging + Reporting Staging Reporting Staging Reporting SQL Server buffer hit ratio % Disk time 7, Disk queue length Other factors Many other factors can affect the performance of various analytics components and can affect the capacity planning. These factors primarily affect the performance of the Report Extractor component because they can affect the size of the data aggregated each day. The total size of the data in the reporting database also affects the performance of the Reporting Extractor, although this is not significant because the data is partitioned daily. Some of these other factors are as follows: Number of unique queries each day. Number of unique users each day. Total number of unique assets clicked each day. Existing data size in the reporting warehouse, based on the data retention in the warehouse. The overall effect of these factors is less significant than the total data volume and the number of site entities. However, it is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Gestion de la performance et de la capacité (SharePoint Server 2010). 364

365 Remaining issues There are current known issues that significantly affect the current performance of the Web Analytics service application for deployments that have a large site hierarchy, which includes approximately 100,000 or more SharePoint components. This article might be updated with the capacity requirements for larger site hierarchies when more information is available. Voir aussi Concepts Gestion de la performance et de la capacité (SharePoint Server 2010) Autres ressources SharePoint 2010 Administration Toolkit (SharePoint Server 2010) 365

366 Estimer les exigences de performances et de capacité pour la gestion de contenu Web dans SharePoint Server 2010 Cet article contient de l aide sur la gestion de la capacité pour les sites Microsoft SharePoint Server 2010 sur lesquels la fonctionnalité Infrastructure de publication est activée. Ce document est spécifique à SharePoint Server 2010 et les informations qu il présente ne s appliquent pas à SharePoint Foundation. Cet article présente les scénarios suivants : Un site de publication Internet (site de présence d une entreprise). Ce type de site est publié sur Internet et permet aux utilisateurs d Internet anonymes de rechercher des informations sur une société. Les sites de ce type sont personnalisés et le contenu est étroitement contrôlé. Un site de publication intranet (site d information interne). Ce type de site est publié en interne au sein d une organisation. Sa principale utilisation consiste à partager des informations avec les utilisateurs authentifiés au sein de l organisation. Les informations du site peuvent être gérées de manière étroite ou des zones peuvent être gérées de façon moins stricte. Un Wiki d entreprise (référentiel de connaissances). Un Wiki d entreprise est un site à batterie de serveurs unique qui croît naturellement à mesure que les collaborateurs créent des pages et les lient à des pages existantes ou futures. Les Wikis d entreprise sont généralement publiés en interne au sein d une organisation. Ce site permet aux personnes d une entreprise ou d une organisation de capturer et de partager des connaissances à l aide d une solution intégrée à leur environnement SharePoint et améliorée par celui-ci. Après avoir lu ce document, vous comprendrez les concepts suivants : la métrique clé (débit) que vous devez optimiser pour prendre en charge de nombreuses opérations de lecture ; les différents goulots d étranglement potentiels liés à un déploiement de la gestion de contenu Web SharePoint Server 2010 ; l importance du cache de sortie pour l optimisation du débit ; l impact des opérations d écriture sur l expérience de lecture de l utilisateur final. Dans cet article : 366

367 informations préalablement requises Détails et approche des tests Déploiements de la gestion de contenu Web Éléments à optimiser Résultats des tests et recommandations À propos des auteurs informations préalablement requises Avant de lire ce document, vous devez avoir assimilé les concepts clés sur lesquels repose la gestion de la capacité dans SharePoint Server La documentation suivante vous permet de vous familiariser avec l approche recommandée pour la gestion de la capacité et fournit un contexte qui vous permet de comprendre comment utiliser efficacement les informations contenues dans ce document. Pour plus d informations conceptuelles sur les performances et la capacité susceptibles de faciliter la compréhension du contexte des données fournies dans cet article, voir les documents suivants : Gestion et dimensionnement de la capacité pour SharePoint Server 2010 (éventuellement en anglais) Études de cas techniques sur les performances et la capacité (SharePoint Server 2010) (éventuellement en anglais) Détails et approche des tests Dans chaque test, des variables susceptibles d exister en situation réelle ont été extraites pour indiquer des recommandations spécifiques. Par conséquent, il est très important d effectuer des tests et de suivre une procédure de surveillance dans votre propre environnement pour vérifier que la mise à l échelle répond au volume de demandes attendu. Pour plus d informations sur les concepts de gestion de la capacité, vous pouvez consulter Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Cet article présente les performances liées aux fonctionnalités de la collection de sites, à la fonctionnalité Infrastructure de publication de SharePoint Server et la mise en cache de sortie. Ces fonctionnalités ne sont disponibles que si la fonctionnalité Infrastructure de publication de SharePoint Server est activée. Par défaut, cette fonctionnalité est activée pour les portails de publication. Jeu de données 367

368 Les tests ont été menés à l aide d un jeu de données qui partage des caractéristiques avec les déploiements réels de la gestion de contenu Web. Bien que la charge fût constante, différentes pages ont été demandées. Le tableau suivant décrit le jeu de données utilisé pour ces tests. Jeu de données Objet Taille des bases de données de contenu Site de publication 2,63 Go Nombre de bases de données de contenu 1 Nombre de collections de sites 1 Nombre d applications Web 1 Nombre de sites 50 Nombre de pages Composition des pages Taille des pages Images pages, réparties en 20 dossiers comportant pages chacun Pages d article en HTML de base, avec des références vers deux images 42 Ko (page non compressée) et 12 Ko (page compressée) 3 000, présentant chacune une taille comprise entre 30 Ko et 1,3 Mo Il est recommandé de configurer les services Internet (IIS) de manière à compresser systématiquement les fichiers au lieu d utiliser le paramétrage par défaut consistant à compresser les fichiers dynamiquement. Lorsque la compression dynamique est activée, IIS compresse les pages jusqu à ce que l utilisation de l UC dépasse un certain seuil, point auquel IIS arrête de compresser les pages jusqu à ce que l utilisation repasse sous le seuil. Pendant la réalisation des tests indiqués dans cet article, la compression était toujours activée. Ce jeu de données de test n a utilisé que des fonctionnalités SharePoint Server 2010 par défaut spécifiques au produit. Votre site comprend probablement des personnalisations en plus de ces fonctionnalités de base. Par conséquent, il est important de tester les performances de votre propre solution. 368

369 Configuration matérielle Le nombre de serveurs Web dans la batterie de serveurs différait d un test à l autre. Toutefois, tous présentaient la même configuration matérielle. Le tableau suivant décrit la configuration matérielle des serveurs Web et des serveurs d applications utilisés pendant ces tests. Spécifications matérielles des serveurs d applications et des serveurs Web Serveur Web Processeurs RAM Système d exploitation Taille du lecteur SharePoint 2 quadri-cœurs à 2,33 GHz 8 Go Windows Server 2008, 64 bits 300 Go Nombre de cartes réseau 2 Vitesse des cartes réseau Authentification Type d équilibrage de la charge Version logicielle Services en cours d exécution localement 1 gigabit De base Windows Équilibrage de la charge matérielle SharePoint Server 2010 (version précommerciale) Administration centrale Courrier électronique entrant Microsoft SharePoint Foundation Application Web de Microsoft SharePoint Foundation Service Minuteur de flux de travail Microsoft SharePoint Foundation Le tableau suivant décrit la configuration matérielle des serveurs de bases de données utilisés pendant ces tests. Spécifications matérielles des serveurs de bases de données 369

370 Serveur de bases de données Processeurs RAM Système d exploitation Stockage 4 quadri-cœurs à 3,19 GHz 16 Go Windows Server 2008, 64 bits 15 disques de 300 Go à tr/m Nombre de cartes réseau 2 Vitesse des cartes réseau Authentification 1 gigabit NTLM Version logicielle Microsoft SQL Server 2008 Glossaire Ce document comprend certains termes spécialisés. Voici certains termes clés et leurs définitions : Demandes par seconde Nombre de demandes reçues par une batterie de serveurs ou un serveur en une seconde. Il s agit d une mesure courante de la charge d un serveur et d une batterie de serveurs. Notez que les demandes diffèrent des chargements de page ; chaque page contient plusieurs composants, qui génèrent chacun une ou plusieurs demandes lors du chargement de la page. Par conséquent, un même chargement de page génère plusieurs demandes. En règle générale, les événements et les vérifications d authentification qui utilisent des ressources insignifiantes ne sont pas pris en compte dans les mesures des demandes par seconde. Zone verte Il s agit de l état dans lequel le serveur peut répondre à l ensemble de critères suivant : La latence côté serveur pour au moins 75 % des demandes est inférieure à 1 seconde. Tous les serveurs présentent une utilisation de l UC inférieure à 50 %. Le taux d échec est inférieur à 0,01 %. 370

371 Déploiements de la gestion de contenu Web Deux modèles de création de contenu dans les sites de publication SharePoint sont susceptibles de déterminer le choix de la topologie de batterie de serveurs. Dans le modèle de création sur place, une collection de sites unique est partagée par les auteurs et les visiteurs. Les auteurs peuvent créer et mettre à jour du contenu à tout moment, ce qui aboutit à des distributions variables des opérations de lecture et d écriture pendant une journée donnée. En règle générale, de nombreuses lectures et un nombre modéré d écritures ont lieu dans cette batterie de serveurs Le diagramme suivant illustre le fonctionnement de la création sur place du point de vue de la topologie. Dans le modèle de déploiement de contenu, plusieurs collections de sites prennent en charge séparément et de façon exclusive la création et la publication du contenu. Le contenu est créé et mis à jour dans l environnement de création, puis est déployé de façon planifiée sur l environnement de publication en vue de sa lecture par les visiteurs. La fonction essentielle de l environnement de publication consiste à traiter les demandes de lecture, sauf lorsque du contenu est déployé à partir de l environnement de création. La charge du serveur exercée par le déploiement de contenu peut être ajustée sur des intervalles planifiés, ce qui n est pas le cas dans le modèle de création sur place. Le diagramme suivant illustre le fonctionnement du déploiement de contenu du point de vue de la topologie. Ces modèles de création de contenu s excluent mutuellement. Bien que les sites de publication Internet et les sites de publication intranet puissent utiliser le modèle de déploiement de contenu ou le modèle de création sur place, celui-ci convient le mieux aux Wikis d entreprise. En règle générale, un Wiki d entreprise présente un volume d opérations d écriture supérieur au volume d opérations de lecture, car une proportion plus importante d utilisateurs peut modifier 371

372 les pages. Les pages de Wiki d entreprise diffèrent des pages d article de publication et présentent des caractéristiques différentes en termes de performances. Éléments à optimiser Cette section présente des informations sur l optimisation de votre environnement de gestion de contenu Web. Dans le cadre de l optimisation de l environnement, vous devez savoir comment gérer le débit, les goulots d étranglement et la mise en cache. Dans cette section : Le débit est la métrique clé Goulots d étranglement et correction La mise en cache peut s avérer utile Le débit est la métrique clé Le débit et le temps de réponse sont les métriques les plus importantes que vous devez optimiser lorsque vous planifiez la capacité pour un déploiement de gestion de contenu Web SharePoint Server Le débit représente le nombre d opérations qu une batterie de serveurs peut effectuer par seconde, mesuré en demandes par seconde. Goulots d étranglement et correction Un goulot d étranglement désigne la ressource système qui, du fait de son épuisement, empêche la batterie de serveurs de traiter des demandes supplémentaires. Le diagramme suivant montre les éléments d une batterie de serveurs et les ressources qui peuvent constituer des goulots d étranglement et qui doivent faire l objet d une surveillance. 372

373 373

374 Utilisation de l UC des serveurs Web L UC des serveurs Web doit être le goulot d étranglement d une topologie correctement ajustée, car il s agit du composant qu il est possible de faire évoluer le plus facilement. L équilibrage de charge répartit les demandes entre les serveurs Web et s assure qu aucun serveur n est surutilisé par rapport aux autres. Bien que des utilisateurs supplémentaires puissent visiter le site une fois que l UC des serveurs Web est utilisée en totalité, le temps de réponse du serveur augmente pour ces utilisateurs. Ce comportement facilite la gestion des pics dans le volume de demandes. Toutefois, le maintien de la charge au-delà de la capacité d une batterie de serveurs aboutit à un journal de demandes en souffrance trop important par rapport au seuil des demandes en attente. À ce stade, les serveurs Web ne gèrent pas les demandes et répondent par l erreur HTTP 503. Dans l illustration suivante, le temps de réponse du serveur diminue dès que le seuil des demandes en attente est atteint, car seules les erreurs HTTP sont traitées. 374

375 Les modifications suivantes sont illustrées dans ce diagramme : 375

376 1. Le temps de réponse augmente lorsque l utilisation de l UC des serveurs Web approche 100 %. 2. Dès que le seuil des demandes en attente est dépassé, le traitement des demandes supplémentaires se traduit par la génération d erreurs. Autres goulots d étranglement Si l UC des serveurs Web n est pas le goulot d étranglement, les éléments suivants à analyser comme étant susceptibles de comporter des goulots d étranglement sont la topologie de la batterie de serveurs, la configuration de la batterie de serveurs ou le contenu des pages fournies. Certains goulots d étranglement potentiels dans ces éléments sont les suivants : 1. Réseau Dans les situations de débit élevé, le réseau peut être saturé entre le serveur Web et le serveur de bases de données ou entre le serveur Web et les utilisateurs finaux. Pour éviter cette situation, configurez les serveurs Web de telle sorte qu ils utilisent des cartes réseau de 2 gigabits. 2. UC du serveur de bases de données Si l UC du serveur de bases de données devient le goulot d étranglement, l ajout de serveurs Web à la batterie de serveurs ne peut pas augmenter le débit maximal que la batterie de serveurs peut prendre en charge. Un goulot d étranglement affectant l UC du serveur de base de données, mais pas les UC des serveurs Web, peut refléter deux situations : a) Des paramètres de cache mal optimisés ou des pages très lentes, notamment celles qui ne sont pas placées dans le cache de sortie. Cela se caractérise par une utilisation élevée de l UC du serveur de bases de données, mais par un débit faible ou moyen et par une utilisation faible ou moyenne des serveurs Web. b) Le serveur de bases de données a peut-être atteint le niveau de capacité maximal pour le débit requis pour la batterie de serveurs. Cela se caractérise par une utilisation élevée de l UC des serveurs Web et du serveur de bases de données lorsque le débit est élevé. La mise en cache peut s avérer utile SharePoint Server 2010 utilise trois types de mise en cache. L objectif commun de ces caches est d améliorer l efficacité en réduisant les appels à la base de données pour des données fréquemment demandées. Les demandes ultérieures d une page peuvent être traitées à partir du cache du serveur Web, ce qui aboutit à une diminution significative de l utilisation des ressources des serveurs Web et des serveurs de bases de données. Les trois types de mise en cache sont les suivants : Cache de sortie Ce cache stocke le contenu des pages demandées dans la mémoire du serveur Web. Pour plus d informations sur le cache de sortie, voir Mise en cache de sortie et profils de cache ( 376

377 Cache d objets Ce cache stocke des objets SharePoint, tels que des métadonnées d élément de liste et Web, dans la mémoire du serveur Web. Pour plus d informations sur le cache d objets, voir Cache d objets ( Cache disque pour les objets BLOB (Binary Large Object) Ce cache stocke sur disque des fichiers image, son, vidéo et d autres fichiers binaires volumineux. Pour plus d informations sur le cache BLOB, voir Mise en cache sur disque pour les objets BLOB ( Chacun de ces caches est important pour maintenir un débit élevé. Toutefois, la mise en cache de sortie a l impact le plus important et est abordée en détail tout au long de cet article. Résultats des tests et recommandations Cette section présente des domaines spécifiques qui ont été testés et fournit des recommandations établies à l issue de ces tests. Dans cette section : Impact de l activation du cache de sortie Utilisateurs anonymes et utilisateurs authentifiés Caractéristiques des opérations de lecture et d écriture dans le cadre d une montée en puissance parallèle Mises en garde concernant le cache de sortie Impact du volume de lectures sur l UC et le temps de réponse Impact des opérations d écriture sur le débit Impact du déploiement de contenu Impact de la capture instantanée de base de données pendant l exportation à l aide du déploiement de contenu Caractéristiques du contenu Impact de l activation du cache de sortie Le cache de sortie est une fonctionnalité très utile pour optimiser une solution SharePoint Server 2010 pour de nombreuses opérations de lecture. Dans le cadre de ces tests, afin que soit déterminé le taux de demandes par seconde maximal, le nombre d utilisateurs actifs effectuant des demandes sur la batterie de serveurs a été augmenté jusqu à ce que l utilisation de l UC du serveur de bases de données ou des serveurs Web ait atteint le niveau de 100 % et soit devenue un goulot d étranglement. Le test a été mené sur des topologies de batterie 377

378 de serveurs 1x1 (1 serveur Web et 1 serveur de bases de données), 2x1, 4x1 et 8x1 pour montrer l impact de la montée en puissance parallèle des serveurs Web suivant différents taux d accès au cache de sortie. Taux d accès au cache de sortie Le taux d accès au cache de sortie mesure les accès par rapport aux échecs d accès au cache de sortie. Un accès au cache se produit lorsque le cache reçoit une demande pour des données d objet qui sont déjà stockées dans le cache. Un échec d accès au cache se produit lorsqu une demande est reçue pour des données d objet qui ne sont pas stockées dans le cache. Lorsqu un échec d accès au cache se produit, le cache essaie de stocker les données d objet demandé afin que les demandes ultérieures pour ces données aboutissent à un accès au cache. Une demande de page peut aboutir à un échec d accès au cache pour plusieurs raisons. Les pages sont configurées pour ne pas utiliser le cache de sortie. Il s agit de pages personnalisées, par exemple, de pages dont les données sont spécifiques à l utilisateur actuel. Le délai de premier accès par clé de variante de cache de sortie a expiré. Le délai de premier accès après la mise en cache de contenu a expiré. Le diagramme suivant montre l effet de la mise en cache de sortie sur le débit maximal dans les batteries de serveurs comportant entre un et quatre serveurs Web et un serveur de bases de données. 378

379 379

380 Remarque : Le point de données pour le taux de demandes par seconde maximal sur une batterie de serveurs 4x1 avec un taux d accès au cache de sortie de 100 % est extrapolé et n a pas été réellement observé. Le volume de demandes pour la batterie de serveurs a atteint la limite de la bande passante réseau ; en d autres termes, le taux de transfert de données a approché 1 gigabit par seconde. Dans tous les cas, l utilisation de l UC des serveurs Web s élève à 100 %. Le tableau suivant répertorie les impacts du taux d accès au cache de sortie sur les topologies de batterie de serveurs comportant entre un et quatre serveurs Web et un serveur de bases de données. Impacts du taux d accès au cache de sortie sur différentes topologies de batterie de serveurs Taux Mesure 1x1 2x1 4x1 d accès au cache de sortie 100 % Taux de demandes par seconde maximal Utilisation de l UC par SQL Server % % % 95 % Taux de demandes par seconde maximal ,93 % ,00 % ,80 % 380

381 Taux Mesure 1x1 2x1 4x1 d accès au cache de sortie Utilisation de l UC par SQL Server 90 % Taux de demandes par seconde maximal Utilisation de l UC par SQL Server ,12 % ,40 % ,00 % 50 % Taux de demandes par seconde maximal Utilisation de l UC par SQL Server 459 9,86 % ,50 % ,00 % 0 % Taux de demandes par seconde maximal Utilisation de l UC par SQL 172 9,53 % ,00 % ,30 % 381

382 Taux Mesure 1x1 2x1 4x1 d accès au cache de sortie Server Conclusions et recommandations pour l impact de l activation du cache de sortie Des taux élevés d accès au cache de sortie entraînent des augmentations significatives du taux de demandes par seconde maximal. Par conséquent, il est recommandé d activer la mise en cache de sortie pour optimiser votre solution de publication SharePoint Server Vous pouvez configurer le cache de sortie dans la page Paramètres du cache de sortie pour la collection de sites. Pour plus d informations, voir Améliorer le rendu des pages en configurant la mise en cache de sortie ( sur le site Web Office.Microsoft.com. Dans les tests au cours desquels la mise en cache de sortie était activée, la première demande qui aboutissait à la mise en cache d une page était exclue ; en d autres termes, un certain pourcentage de pages est déjà stocké dans le cache. Lorsqu un utilisateur demande pour la première fois une page qui n est pas mise en cache, la page est ajoutée au cache. Si le cache a atteint ou approche le niveau de capacité maximal, il tronque les dernières données demandées. Le taux d accès au cache de 0 % simule dans un environnement la brève période au cours de laquelle le cache de sortie activé est rempli après avoir été vidé. Par exemple, cela s observe chaque jour dans un environnement réel lors du recyclage du pool d applications. Il est important d appliquer à votre configuration matérielle une montée en puissance par unité ou parallèle correcte afin de faire face à la situation dans laquelle le taux d accès au cache est de 0 % pendant la brève période entre le recyclage du pool d applications et la demande et la mise en cache suivantes de pages. En outre, le taux d accès au cache de 0 % simule un environnement dans lequel la mise en cache de sortie n est pas activée. Utilisateurs anonymes et utilisateurs authentifiés Le test précédent suppose que toutes les demandes adressées au site sont réalisées par des lecteurs anonymes. Toutefois, dans votre site, une partie ou la totalité des utilisateurs peuvent être authentifiées. Un site de publication intranet d entreprise et un contenu accessible uniquement aux membres d un site Internet sont des exemples de scénarios de lecture authentifiée. 382

383 Grâce aux profils de cache de sortie, vous pouvez définir pour les utilisateurs authentifiés et pour les utilisateurs anonymes des comportements du cache de sortie spécifiques. Profils de cache Les profils de cache regroupent des paramètres que vous pouvez appliquer aux pages, aux éléments de page, aux types de contenu et aux niveaux d échelle dans un déploiement de site. Un profil de cache définit les types de comportement de cache suivants : la durée de conservation des éléments dans le cache ; la stratégie de filtrage de sécurité ; l expiration des paramètres, tels que la durée et les modifications ; les variantes du contenu mis en cache, par exemple, en fonction de l autorisation utilisateur, des droits d utilisateur et d autres variables personnalisées. Toute modification apportée à un profil de cache a un impact immédiat sur la totalité du contenu concerné sur le site. Vous pouvez définir différents profils de cache pour les utilisateurs anonymes et pour les utilisateurs authentifiés. Pour les utilisateurs anonymes et pour les utilisateurs authentifiés ont été respectivement utilisés le profil de cache de sortie Internet public (purement anonyme) et le profil de cache de sortie Extranet (site publié). Le graphique suivant montre l impact du débit authentifié sur l utilisation de l UC du serveur de bases de données. 383

384 Le mode d authentification utilisé était l authentification de base Windows. Bien qu il ne soit pas recommandé d utiliser l authentification de base Windows pour les sites Internet, cette méthode d authentification a été sélectionnée afin que soit illustré un traitement minimal imposé par l authentification. La taille de ce traitement varie en fonction du mécanisme d authentification que vous utilisez. Lorsque vous testez votre déploiement, veillez à prendre en compte l impact de votre mécanisme d authentification. Pour plus d informations sur les mécanismes authentifications pris en charge par SharePoint Server 2010, voir Plan authentication methods (SharePoint Server 2010). Conclusions et recommandations pour les utilisateurs anonymes et les utilisateurs authentifiés 384

385 Les utilisateurs authentifiés connaissent des taux de demandes par seconde inférieurs et s exposent à une moindre nécessité d une montée en puissance parallèle, car le travail supplémentaire de validation des informations d identification exerce une charge sur le serveur de bases de données. Comme l ont montré les résultats des tests, le taux de demandes par seconde maximal observé lorsque les utilisateurs sont authentifiés est sensiblement inférieur à celui constaté dans le cas d une batterie de serveurs avec accès anonyme. Caractéristiques des opérations de lecture et d écriture dans le cadre d une montée en puissance parallèle Nos tests ont été conçus de manière à enregistrer des écritures par heure. Dans cet article, une écriture représente la création et l archivage d une nouvelle page de publication ou la modification et l archivage d une page de publication existante. Pour les tests suivants, des lecteurs ont été ajoutés au système jusqu à ce que l utilisation de l UC des serveurs Web ait atteint approximativement %, puis des opérations d écriture ont été réalisées dans l environnement à l aide d un délai artificiel. Le nombre total d écritures par heure pour le test a été approximativement de 500. Nous avons utilisé un taux d accès au cache de sortie de 90 % pour tous les tests. Nous avons réalisé le même test sur une batterie de serveurs 1x1, 2x1 et 4x1 et avons observé l utilisation de l UC de SQL Server et des serveurs Web en plus du débit de lecture globale pour chaque configuration. En outre, nous avons testé une configuration de lecture seule anonyme en guise de ligne de base et nous avons également testé une configuration avec des lecteurs authentifiés en utilisant l authentification de base Windows. Bien que l UC des serveurs Web fût utilisée à hauteur de 100 % pendant les tests avec montée en puissance parallèle et lecture seule, nous avons maintenu l utilisation de l UC des serveurs Web entre 80 et 90 % pour les tests avec montée en puissance parallèle et opérations d écriture. Nous avons opéré ainsi afin de laisser une marge de manœuvre pour une utilisation supplémentaire de l UC pendant une activité d écriture. Le graphique suivant montre le taux global de demandes de lecture par seconde observé pendant chaque test. Le taux de demandes de lecture par seconde devient linéaire lorsque des serveurs Web sont ajoutés, même pendant une activité d écriture. Toutefois, le taux de demandes par seconde affiche une perte lorsque des écritures sont incorporées. 385

386 386

387 L utilisation de l UC du serveur de bases de données a augmenté à mesure que le nombre de serveurs Web s accroissait. Le graphique suivant montre la tendance de croissance de l utilisation de l UC de SQL Server dans les différentes configurations. Comme indiqué dans la section Utilisateurs anonymes et utilisateurs authentifiés plus haut dans cet article, l authentification a une incidence sur l utilisation de l UC du serveur de bases de données et cela devient plus prononcé lorsqu une activité d écriture est ajoutée (ce qui a également un impact sur l utilisation de l UC du serveur de bases de données). 387

388 388

389 L extrapolation de la tendance de l utilisation de SQL Server montre que SQL Server devient le goulot d étranglement lorsque la configuration compte six serveurs Web traitant des demandes de lecture authentifiées. Toutefois, dans le cas des lectures anonymes, la montée en puissance parallèle au profit d un nombre plus élevé de serveurs Web est réalisable. Il est important de garder à l esprit que des facteurs supplémentaires dans un déploiement typique ont une incidence sur la charge exercée sur le serveur de bases de données et qu il est important de tenir compte de ces facteurs lors de la planification de la capacité. Pour plus d informations sur la détermination d une zone verte pour une utilisation typique de l UC du serveur de bases de données, voir Vue d ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server Conclusions et recommandations pour les caractéristiques des opérations de lecture et d écriture dans le cadre d une montée en puissance parallèle Nos données montrent que la montée en puissance parallèle du nombre de serveurs Web est une stratégie efficace pour augmenter le débit si le serveur de bases de données ne devient pas le goulot d étranglement. En moyenne, la combinaison de tests de lectures anonymes avec écritures authentifiées a engendré une augmentation de 52 % de l utilisation de l UC des serveurs Web par rapport à une combinaison de tests de lectures anonymes sans écritures. En outre, les lectures authentifiées engendrent une charge supplémentaire significative sur SQL Server, car chaque demande entraîne des vérifications d authentification supplémentaires, ce qui requiert un allerretour vers SQL Server. Le graphique suivant montre l impact du débit sur l utilisation de l UC du serveur de bases de données. 389

390 390

391 Mises en garde concernant le cache de sortie Si la seule préoccupation concernant la planification de la capacité était d optimiser le taux de demandes par seconde, ces tests indiqueraient que le taux d accès au cache optimal est de 100 %. Toutefois, il peut s avérer impossible ou non souhaitable d activer la mise en cache de sortie de tout ou partie des pages en raison des contraintes liées à la mémoire ou au caractère actuel des données. Caractère actuel des données Les données issues du cache de sortie risquent de ne pas contenir les mises à jour récemment apportées au contenu d origine. Dans la source du déploiement de contenu ou, dans le cas des auteurs authentifiés, dans un scénario de création en production, il est possible que les auteurs souhaitent que les modifications les plus récentes apportées au contenu soient visibles immédiatement. Cela est généralement facilité par la définition de la propriété Durée dans le profil de cache, qui spécifie la durée de conservation d une page dans le cache de sortie avant son expiration. Lorsqu une page expire, elle est supprimée du cache et une demande ultérieure aboutit à un échec d accès au cache qui actualise le contenu de la page. En outre, la propriété de profil de cache Rechercher les modifications peut être définie de manière à ce que le serveur compare l heure de mise en cache d une page et l heure de la dernière modification du contenu d une collection de sites. Une demande d une page pour laquelle les horodatages ne correspondent pas entraîne une invalidation de cache pour toutes les pages de la collection de sites. Étant donné que la propriété Rechercher les modifications a une incidence sur toutes les pages d une collection de sites, il est recommandé de n activer cette option que dans le cadre d une solution de création sur place authentifiée rarement mise à jour et fondamentalement statique. La combinaison de cette option avec une longue durée permet de fournir toutes les pages à partir du cache jusqu à ce qu une mise à jour du site soit réalisée. Par défaut, la propriété Rechercher les modifications n est pas activée. Cela signifie que le serveur Web fournit des données à partir du cache de sortie en réponse aux demandes d une page qui n a pas encore expiré, que la page ASPX d origine sous-jacente ait été modifiée ou non. Dans ce test, mené sur une batterie de serveurs 1x1, toutes les variables sont les mêmes que dans les tests présentés dans la section Caractéristiques des opérations de lecture et d écriture dans le cadre d une montée en puissance parallèle, à l exception de la propriété Rechercher les modifications. Lorsque la propriété Rechercher les modifications est activée, le cache est vidé plus souvent, ce qui aboutit à une diminution du taux d accès au cache de sortie. Le graphique suivant montre l impact de la propriété Rechercher les modifications sur le débit. 391

392 Il est déconseillé d utiliser la propriété de profil de cache de sortie Rechercher les modifications, sauf dans des cas spécifiques. Un site qui utilise le modèle de création sur place et dont le contenu est rarement modifié peut tirer parti de ce paramètre dans le cas d une configuration associant des utilisateurs authentifiés et une durée de mise en cache longue, mais il est fort probable que les autres types de sites connaissent une dégradation du taux de demandes par seconde. 392

393 Il est possible que des impératifs justifient que le contenu présentant un caractère urgent soit publié instantanément ou plus rapidement que ne le permettent les paramètres par défaut. Dans ce cas, vous devez diminuer la durée ou activer la mise en cache de sortie. Conclusions et recommandations pour les mises en garde concernant le cache de sortie La mise en cache de sortie ne résout pas tous les problèmes liés à la gestion de la capacité. Il existe certaines situations dans lesquelles la mise en cache de sortie est inadaptée et dont vous devez tenir compte lorsque vous activez le cache de sortie et configurez des profils de cache de sortie. Impact du volume de lectures sur l UC et le temps de réponse Ce test a été mené sur une batterie de serveurs 1x1 avec accès anonyme et activation de la mise en cache de sortie. Le graphique suivant montre l impact du volume de lectures sur l UC et le temps de réponse. 393

394 Conclusions et recommandations pour l impact du volume de lectures sur l UC et le temps de réponse Comme indiqué dans la section Goulots d étranglement et correction, le temps de réponse serveur demeure généralement constant jusqu à ce que le serveur Web reçoive un volume de demandes suffisant pour que la totalité de son UC soit utilisée. Lorsque l UC du serveur Web est entièrement utilisée, le temps de réponse augmente de manière significative. Toutefois, la batterie de serveurs est toujours en mesure de gérer un volume de demandes supplémentaire. 394

395 Impact des opérations d écriture sur le débit Le rapport entre les opérations de création et les opérations de modification est réparti de façon égale sur la durée des tests. Les valeurs d écritures par heure ont été testées jusqu à approximativement 500 opérations, car la création ou la modification de plus de 500 pages par heure reflète le fonctionnement de très peu de déploiements SharePoint. Le test n a pas couvert les processus automatisés, tels que le déploiement de contenu, abordé dans la section Impact du déploiement de contenu. Ces opérations de création et de modification peuvent aboutir à plusieurs opérations SQL Server. Par conséquent, il est important de garder à l esprit que les écritures mesurées dans ces tests ne sont pas réalisées au niveau de SQL Server, mais qu elles sont plutôt représentatives d une opération d écriture du point de vue d un utilisateur. Tous les tests de taux de demandes par seconde par rapport aux écritures par heure ont été menés sur une batterie de serveurs 1x1. Nous avons d abord ajouté des opérations de lecture au test jusqu à ce que l utilisation de l UC du serveur Web se situe entre 60 et 80 % afin de laisser une mémoire tampon pour les pics de trafic, et nous avons conservé ce niveau d utilisation moyen sur toute la durée du test. Ensuite, nous avons introduit des écritures à l aide d un délai artificiel pour contrôler le nombre d opérations d écriture. Toutefois, des pics d utilisation accrue de l UC de SQL Server et du serveur Web se sont produits pendant les écritures. Pour certains taux d accès au cache, certains de ces pics ont dépassé le seuil d un fonctionnement ordinaire, comme le montre le graphique suivant, sans que la moyenne s écarte toutefois de la plage du fonctionnement ordinaire. 395

396 396

397 Comme le montre le graphique précédent, le débit présente une légère réduction lorsque des écritures sont ajoutées à l environnement. Le graphique montre l évolution du débit entre un scénario de lecture seule et un scénario combinant des opérations de lecture et approximativement 500 écritures par heure. Deux points de données ont été enregistrés pour chaque taux d accès au cache de sortie. Par conséquent, la relation entre les points de données n est pas nécessairement linéaire. La réduction du pourcentage est d autant plus prononcée que le taux d accès au cache est faible, comme le montre le graphique suivant. Le taux global de demandes de lecture par seconde demeure étroitement lié au taux d accès au cache, indépendamment des écritures. 397

398 398

399 Le graphique suivant montre que l ajout d écritures au système n a pas entraîné une augmentation sensible de l utilisation de l UC du serveur de bases de données. Notez que l axe vertical représente, en pourcentage, la capacité de l UC sur une échelle allant de 0 à 10. Une charge supplémentaire sur SQL Server a naturellement été observée pendant les opérations d écriture. Toutefois, l augmentation la plus importante s élève à 2,06 %, ce qui est insignifiant. L utilisation moyenne de l UC du serveur de bases de données est demeurée 399

400 inférieure à 10 % pendant tous les tests. Ce test a été réalisé sur une batterie de serveurs 1x1. L utilisation de l UC du serveur de bases de données augmente lorsque le nombre de serveurs Web fait l objet d une montée en puissance parallèle. Cet aspect est abordé plus en détail dans la section Caractéristiques des opérations de lecture et d écriture dans le cadre d une montée en puissance parallèle. L utilisation de l UC du serveur Web a également été mesurée pendant les tests. Le graphique suivant montre que l utilisation moyenne de l UC du serveur Web est demeurée dans la plage % tout au long de la durée des tests, même lorsque le nombre d écritures par heure approchait la valeur

401 401

402 Toutefois, l utilisation de l UC mesurée réelle connaît des pics lorsque les écritures se produisent, comme le montre le graphique suivant. En général, ces pics de l UC ne représentent pas un problème. L objectif de la zone verte est de permettre à l UC d absorber certains pics de charge du processeur. En outre, lorsque des serveurs Web sont ajoutés, l impact des pics est réparti sur ces serveurs, ce qui réduit l incidence produite sur chaque UC de serveur Web. Toutefois, vous devez avoir conscience que les pics de ce type sont normaux dans un déploiement réel ; l activité d écriture n est pas distribuée de manière uniforme, bien que cela se produise généralement de façon sporadique. 402

403 403