Autres facteurs de planification de la capacité et des performances (Office SharePoint Server)
Mise à jour : 2009-04-23
Cette section décrit les facteurs supplémentaires dont il convient de tenir compte lors de la planification de votre déploiement.
Facteurs d’environnement
Composants WebPart de requête de contenu
Facteurs d’environnement
Considérations réseau
Sécurité réseau
Authentification
Développement du code personnalisé
Configuration réseau
La configuration du réseau est essentielle pour les performances de votre installation d’Office SharePoint Server ou de Windows SharePoint Services. Les composants réseau courants susceptibles d’avoir une incidence sur les performances sont les suivants :
Carte réseau (NIC)
Paramètres de la carte réseau Vous devez autant que possible utiliser des cartes réseau Gigabit. Si vous avez des cartes à auto-commutation (100 Mo / 1 Go), vous devez toujours définir la dérivation pour qu’elle utilise 1 Gigabit.
Trafic entrant/sortant Pour les scénarios pour lesquels vous prévoyez un trafic élevé, nous vous recommandons de disposer de cartes réseau séparées pour gérer le trafic entrant et sortant.
**Commutateurs **Si vous exécutez votre réseau via un commutateur, assurez-vous d’utiliser un commutateur Gigabit et de disposer du même nombre de canaux entrants et sortants.
**Routeurs **Vérifiez que vos routeurs sont configurés sur une infrastructure Gigabit.
Contrôleurs de domaine Il est possible que l’authentification devienne un goulot d’étranglement des performances dans votre environnement SharePoint si le contrôleur de domaine reçoit les demandes plus rapidement que les réponses qu’il peut envoyer. Pour les environnements qui utilisent une authentification utilisateur telle que NTLM, nous recommandons un taux de 3 serveurs Web par contrôleur de domaine. Si vos tests indiquent que la charge d’authentification à 3 serveurs Web par contrôleur de domaine est acceptable, vous pouvez ajouter un serveur Web supplémentaire par contrôleur de domaine pour une limite de 4 serveurs Web par contrôleur de domaine prise en charge.
N’oubliez pas de planifier et de tester minutieusement la configuration réseau avant de déplacer un système vers un environnement de production.
Recommandations pour la topologie du réseau
Planifiez les connexions réseau au sein des batteries de serveurs et entre celles-ci. Il est recommandé d’utiliser un réseau présentant une latence faible.
La liste suivante indique certaines meilleures pratiques et recommandations.
Tous les serveurs de la batterie de serveurs doivent disposer d’une latence et d’une bande passante LAN sur le serveur exécutant SQL Server 2005 (latence inférieure ou égale à 1 milliseconde (ms)).
Nous n’avons pas testé un déploiement d’Office SharePoint Server 2007 dans lequel un serveur exécutant SQL Server 2005 est déployé dans une topologie de réseau étendu (WAN) à distance des autres composants de la batterie de serveurs avec une latence de réseau supérieure à 1 ms. Par conséquent, une topologie WAN de ce type n’est pas recommandée.
Planifiez un réseau WAN adéquat si vous envisagez d’utiliser la mise en miroir SQL Server 2005 ou la copie des journaux de transaction SQL Server 2005 pour maintenir un site distant à jour.
Sécurité réseau
Pour plus d’informations sur la sécurité réseau, voir Planifier une communication sécurisée dans une batterie de serveurs (Office SharePoint Server).
Authentification
Le mécanisme d’authentification utilisé dans votre environnement a un effet incrémentiel sur les performances globales du système. Les facteurs qui contribuent aux performances d’authentification sont les suivants :
Le nombre et la vitesse des allers-retours vers le fournisseur d’authentification
Les performances de traitement du fournisseur d’authentification
Les tests Microsoft indiquent que l’ordre des mécanismes d’authentification, du plus rapide au plus lent, est le suivant :
Anonyme
Kerberos
NTLM
De base
Authentification par formulaires
Si vous choisissez d’écrire un fournisseur d’authentification à utiliser avec Office SharePoint Server ou Windows SharePoint Services, vous devez suivre les pratiques recommandées dans l’article MSDN Authentification dans ASP.NET : conseils de sécurité .NET (https://msdn2.microsoft.com/fr-fr/library/ms978378.aspx).
Développement du code personnalisé
La cause la plus courante de perte de performances dans les versions antérieures de SharePoint Server est le développement et le déploiement de fonctionnalités personnalisées inefficaces en plus de la plateforme SharePoint. Lors du développement de fonctionnalités personnalisées pour SharePoint, vous devez analyser un certain nombre de mesures de performances. Ces mesures comprennent, sans s’y limiter :
Allers-retours SQL Server Pour les pages principales, nous ne recommandons pas plus de 2 ou 3 allers-retours SQL. Des allers-retours excessifs ont l’effet négatif suivant sur les performances :
Augmentation du temps de réponse de l’utilisateur final en raison d’une durée de traitement côté serveur plus importante
Réduction du débit système global en raison de la charge supplémentaire sur le serveur de bases de données
**Utilisation du processeur sur les serveurs SQL **Pour préserver la santé de votre système Microsoft Office SharePoint Server, il est important que l’utilisation du processeur sur le ou les serveurs de base de données reste relativement faible. Une utilisation moyenne du processeur sur SQL Server 2005 supérieure à 60 % entraîne une dégradation des performances. Voici notamment ce que vous pouvez faire pour réduire l’utilisation du processeur sur les serveurs SQL :
Mettez en place une stratégie de mise en cache ; cela réduit le nombre global d’appels à partir des serveurs Web vers le serveur de bases de données.
Optimisez le code personnalisé afin d’utiliser des méthodes d’objet qui renvoient vos données souhaitées de la manière la plus efficace (par exemple, présentez des index sur les listes, etc...)
Répartissez vos bases de données SQL sur plusieurs serveurs de base de données physiques
Taille de téléchargement des pages Conservez la taille du code à un niveau minimal. Une augmentation relativement faible de la taille de page peut avoir un impact significatif sur les performances si un grand nombre de personnes accèdent à cette page chaque jour, en particulier pendant les heures de pointe.
Efficacité du code côté client Environ 50 % du temps de réponse de l’utilisateur final est constitué de traitement côté client de code renvoyé. Si votre solution personnalisée augmente ce code, vous pouvez escompter un effet négatif sur le temps de réponse de l’utilisateur final.
**Rappels AJAX **Pour les parties AJAX, le nombre de rappels et la charge utile de chaque rappel. Par exemple, chaque indicateur de performance clé effectue 3 appels pour renvoyer le résultat. Assurez-vous de tester les performances de page lorsque vous introduisez plusieurs indicateurs de performance clés ou tout autre code personnalisé dans une page.
Composant WebPart de requête de contenu
Le composant WebPart de requête de contenu utilise le mécanisme de requête de liste croisée de Windows SharePoint Services pour extraire le contenu d’une collection de sites SharePoint. Si le composant WebPart est configuré pour émettre une requête qui implique un grand nombre de listes, le mécanisme de requête de liste croisée peut lever une exception.
Par défaut, des requêtes de liste croisée possèdent une limite de liste de 1 000. En d’autres termes, si vous configurez le composant WebPart de requête de contenu à l’aide d’une requête qui contient plus de 1 000 listes, la requête de liste croisée ne s’achève pas et le composant WebPart n’affiche aucun contenu. La raison de cette limitation consiste à éviter de surcharger SQL Server 2005. Plus la requête de liste croisée contient de listes, plus il faut de temps au serveur de bases de données pour renvoyer le contenu demandé par la requête. Pour un très grand nombre de listes, le serveur de bases de données peut ainsi traiter de manière disproportionnée les requêtes de liste croisée au détriment d’autres demandes.
Si vos conditions supposent l’interrogation de plus de 1 000 listes, vous pouvez augmenter la limite de liste si la charge imposée par les opérations à la base de données est acceptable. Pour ce faire, vous pouvez ajouter un attribut MaxListLimit à la propriété ListsOverride du composant WebPart. Par exemple, si vous souhaitez augmenter la limite de liste à 2 000, vous devez définir la propriété ListsOverride sous la forme suivante :
<Lists ServerTemplate="850" MaxListLimit="2000">
Télécharger ce livre
Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :
Vous trouverez la liste complète des livres disponibles sur Livres à télécharger pour Office SharePoint Server 2007.