Performance Tuning SharePoint 2010

Session animée par Eric Shupps

Notre speaker  un énorme chapeau de cowboy. Il fait visiblement honneur à son surnom de « SharePoint cowboy ».

Nous n’aborderons pas ici l’aspect programmation mais plutôt l’administration.

Le sommaire de la session :

  • L’infrastructure : le réseau,  les serveurs, les bases de données
  • La configuration : la mise en cache, la compression, le throttling, les locks
  • Les pages : la customisation, le branding, les listes
  • Les outils

On commence par l’infrastructure.

Premier problème rencontré sous SharePoint, les nombreux accès aux bases de données, ce qui engendre une dégradation progressive des performances.

Il est important de séparer le trafic des serveurs de bases de données du trafic des serveurs Web. Il est mieux qu’ils soient sur de réseaux différents.

Nous avons droit à un beau graphique représentant l’architecture idéale.

Concernant le serveur exécutant le moteur de recherche, il est mieux qu’il se crawl lui-même plutôt qu’il crawle les serveurs Web ce qui génère du trafic inutile sur le réseau.

Pour déterminer l’architecture à utiliser, il est important d’estimer les fonctionnalités les plus importantes pour notre plateforme.
Les opérations de lecture demandent plus de serveurs Web.

Les opérations d’écriture nécessitent plus de serveurs de bases de données.

Les opérations  de recherche nécessitent plus de serveur d’applications.

D’un point de vue géographique, il faut garder à l’esprit que les distributions globales nécessitent des fermes locales.

Notre cowboy nous montre ensuite les impacts des différents types d’opérations sur les bases de données. Le plus gros consommateur est la recherche, vient ensuite la collaboration puis les requêtes de contenu…

Les développeurs et les administrateurs ont tout intérêt à travailler ensemble pour faire les bons choix plutôt que de se rejeter la faute mutuellement en cas de problème.

Pour estimer la quantité de documents d’un site, voici la formule magique: ((DxV)xS)+(10kbx(L+(VxD)))
D = nombre de documents
S = taille des documents
V = nombre de versions
L = éléments de liste

Il ne faut également pas oublier que les analytics peuvent être conséquentes et doivent être isolées des autres données.
Une base de contenu doit idéalement être limitée à 200go (max supporté : 4to)

Une base de données peut représenter volume énorme de données : il faut isoler le crawl du temp.

Un point important : configurer l’auto growth manuellement !!!

D’autres points importants : isoler les logs de transactions, faire des backups réguliers, défragmenter, utiliser des quotas….

On attaque ensuite le sujet de la mise en cache.

Les bons développeurs doivent utiliser le cache pour les données !

On parcourt quelques exemples de codes à éviter.

De nombreux caches sont disponibles sous SharePoint: l’output cache, le blob cache, le db caching…

On passe à présent à la démo

Nous voyons qu’en activant la feature publishing sur un site, il est possible de paramétrer l’output cache et des profils de cache.

Petit tour dans Visual Studio pour tester la charge du serveur. De nombreux indicateurs sont disponibles. On se concentre sur le temps de chargements des pages.

On active le blob cache pour voir l’impact sur les performances. Ici, les images et les css sont copiés sur le file system. Faire attention au dossier qu’on a paramétré pour le blob cache. Il ne faut pas copier les fichiers n’importe où.

Effectivement les temps de réponse sont beaucoup plus rapides  !
Ensuite, on active l’output cache dans le paramètres de la collection de sites. C’est encore plus rapide !!! On a diminué de 70% les temps de chargement.

On aborde maintenant la compression IIS.

Elle diminue la taille des fichiers qui transitent sur le réseau mais, attention, elle augmente l’utilisation du cpu. Il faut y aller doucement.

On peut définir pour quels types de fichiers on veut l’activer. C’est très utile pour les fichiers comme le core.js par exemple qui est relativement lourd.

Nous voyons un exemple de script pour l’activer.

Le throttling et les locks permettent de limiter le nombre de données remontées par les requêtes. C’est configurable, il peut être désactivé pour les administrateurs ou pendant des périodes précises.

Le byte rate throttling contrôle, lui, la vitesse de téléchargent des fichiers comme les flashs ou les vidéos.

On illustre tout ça avec une démo.

Ça n’améliore les performances mais ça évite les problèmes en cas de requête remontant de nombreux éléments.

On passe maintenant aux pages.

Dans SharePoint, les pages contiennent beaucoup de contrôles. Il faut faire attention à ce que font les contrôles et à la quantité des données qu’ils consomment, surtout pour les accès en base.

Quand on customise une page depuis SharePoint Designer, cette page est copiée en base (deghost), ce qui implique des accès en base supplémentaires. Au passage, Eric nous donne son avis sur SharePoint Designer. Pour résumer ses propos, c’est nul ! Et toute la salle applaudit ! 🙂

Il ne fait pas oublier que lorsqu’on customise une page, les performances diminuent de 10% en moyenne. Ne pas hésiter à cliquer sur « reset to site définition », tant pis pour les modifications effectuées… !

Concernant le branding, il recommande d’utiliser une masterpage mini pour commencer, de minimifier les fichiers, d’utiliser des images split avec css (il y a des outils pour ça), de privilégier la copie des fichiers sur le file system plutôt que sur des emplacements virtuels (librairies), de regrouper les css en un seul fichier plutôt qu’en plusieurs.

Concernant les listes, ce n’est pas parce qu’on peut faire qu’il faut faire !!! Faire attention aux requêtes. Les Webparts Listview utilisent maintenant du xslt mais il faut tout de même faire du code custom pour les affichages de listes très larges.

Plus de 5000 ligne dans une liste c’est beaucoup (c’est la limite de throtthle par défaut). Plus il y a de  colonnes, plus il y a de lignes SQL. Beaucoup de lignes SQL peuvent diminuer les performances de 35%.

Utiliser le Remote Blob Cache pour éviter le stockage de gros fichiers en base.

Pour finir, nous passons en revue quelques outils, notamment le Developer Dashboard qui permet d’avoir des informations au chargement de la page : voir les requêtes qui passent, les contrôles, les temps d’exécution de chaque élément…

La session s’achève avec une démonstration du Developer Dashboard.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s