Performances etPerformances etplanification de chargeplanification de charge

Planification de chargePlanification de charge

Démarche consistant à évaluer une Démarche consistant à évaluer une technologie par rapport aux besoins d’une technologie par rapport aux besoins d’une organisation, organisation,

et de prendre une et de prendre une décision éclairéedécision éclairée

pour l’acquisition de matériel permettant au pour l’acquisition de matériel permettant au système installé de répondre aux attentes en système installé de répondre aux attentes en terme de montée en charge. terme de montée en charge.

Questions courantes Questions courantes

De combien de hardware ai-je besoin ?

Ai-je besoin d’une ferme de serveurs ?

Ai-je besoin de SQL Server ?

Quel volume de données puis-je stocker ?

Combien de personne puis-je supporter ?

Combien de sites vont pouvoir utiliser mes serveurs ?

Comment puis-je valider mon architecture ?

Buts Buts

Fournir un cadre (framework) pour la planification de capacité.

Mettre en lumière les principaux pièges à éviter.

Identifier les outils disponibles pour valider des décisions de capacité dans votre environnement.

AgendaAgenda

Framework :Utilisateurs : débit et latence.

Données : volume et stockage.

Caractéristiques matérielles.

Autres facteurs.

Le démontrer dans votre environnement.

FrameworkFramework Utilisateurs – DébitUtilisateurs – Débit

Charge utilisateurs : typique versus crête :Typique = moyenne des requêtes durant une unité de temps standard (jour de travail).Crête = accès concurrents (versus type utilisateur) ; planifié pour une charge de crête.

Profil utilisateur : comportement des utilisateurs :Distribution des requêtes à travers le contenu.Exploitez vos journaux IIS.

Principe de base pour l’usage ; hypothèse : 10% d’accès concurrents.

1 RPS =

* Note : Informations cohérentes avec WSSv2 et SPS 2003

Profil Taux attendu (RPH)

Utilisateurs simultanés

Nb d’utilisateurs

total

Léger 20 180 1 800

Typique 36 100 1 000

Lourd 60 60 600

Extrême 120 30 300

FrameworkFramework Utilisateurs - LatenceUtilisateurs - Latence

Eléments participant à la latence :Traitement processeur du serveur (bêta2 ~ 40%) :

Traitements SQL, nombre de dialogues SQL, traitements AJAX, traitements supplémentaires pour la sécurité.

Traitements processeur du client (bêta2 ~ 45%) :Javascript, CSS, requêtes AJAX, interprétation HTML, spécifications de la machine cliente.

Transfert réseau (bêta2 ~ 5%) :Bande passante, taille du téléchargement.

Recommandations :Ennemi n°1 en terme de latence = les Web Parts personnalisées :

Attention : à la complexité des dialogues SQL, aux données inutiles, aux scripts clients trop lourds.

Réutiliser du code client existant au lieu d’en rajouter d’autres.Prendre en compte les performances dans la conception du code – ex : définitions des tables HTML. Profiler vos solutions.

FrameworkFramework Données – VolumeDonnées – Volume

Combien d’objets ?Infrastructure : sites portails, sites d’équipes, sites personnels, librairies de documents, etc.

Données : documents, listes, profils, etc.

Recommandations :Planifier prudemment la hiérarchie et le déploiement des sites :

Limiter le nombre d’applications Web et de pools d’applications.Limiter le nombre de SSP (Services partagés).Planifier une augmentation de la taille de la base de données.

Suivre les bonnes pratiques en termes de données et fonctionnalités, ainsi que les limites suggérées.

FrameworkFramework Données – Limites suggérées (bêta 2)Données – Limites suggérées (bêta 2)

Objet Scope Recommandation

Collection de sites Base de données 50 000

Sites Web Collection de sites 250 000

(sous) Sites Web Site Web 2 000

Listes Site Web 2 000

Eléments Liste 10 M

Documents Librairie

documentaire

2 M

Documents Dossier 2 000

Taille de document Fichier 2 Go

Documents indexés (MOSS) SSP 50 M

Scopes de recherche (MOSS) Collection de sites 1 000

Nombre de profils (MOSS) SSP 5 M

FrameworkFramework Données – Prérequis StockageDonnées – Prérequis Stockage

Premier critère : stockage des documents :Planifier 1,2 – 1,5 x la taille des fichiers pour SQL Servernote : critère dépendant aussi du niveau de RAID utilisé pour les disques SQL.

Second critère : indexServeur d’indexation : 30% de la taille totale du contenu total indexé.

Serveur de recherche : 2 x la taille de l’index.

FrameworkFramework Hardware – Montée en charge de SharePointHardware – Montée en charge de SharePoint

Conçu pour accompagner la croissance des besoins des organisations :

Ressources serveur : x32, x64, CPU, RAM, disque dur :Recommandations : 64 bits pour les services de « back-end » qui peuvent exploiter l’adressage mémoire supplémentaire. SQL : la configuration du disque dur est critique.

Ferme de serveurs :Les restrictions en termes de topologie ont été supprimées.Front-End Web, requêtes, index, services Excel, Project, SQL.

Services partagés :Actifs par défaut (jusqu’à 20 par ferme).

Adage WSS : le contenu est uniquement limité par les capacités matérielles* :

Sites : les portails sont « juste d’autres sites ».

* Voir les limitations sur les données.

FrameworkFramework Hardware – Serveur uniqueHardware – Serveur unique

SQL Express approprié jusqu’à 500 utilisateurs (typiques).

SQL approprié jusqu’à 5 000 utilisateurs (typiques) :Héberge : 1 000 sites d’équipes, portails, et sites personnels.

Stocke : 10 000 documents.

Indexe : 100 000 docs (11 docs/sec).

10 rps pour des opérations « courantes ».

Type de serveur RAM Disque CPU

Serveur unique 2 Go 100 Go 1 x 2.8 Ghz Pentium-4 (32bits)

Un serveur avec :Front-end WEBApplicationBase de données

FrameworkFrameworkHardware – Ferme 4x1x1Hardware – Ferme 4x1x1

Hautement disponible :Utilisateurs : des centaines de milliers.Héberge :des dizaines de milliers de sites d’équipes, personnels ou de portails.Stocke : des millions de documents.Indexe :des millions de documents.

Type de serveur RAM Disque CPU

Serveurs Front-end 2 Go 200 Go 2 x 2.8 Ghz AMD 64 bits

Serveurs d’indexation

4 Go 200 Go 2 x 2.8 Ghz AMD 64 bits

Serveurs SQL Server

4 Go 200 Go 4 x 2.8 Ghz, dual core, AMD 64 bits

front end Web + Requêtes + Services Excel

Index SQL Server en cluster

Bien dimensionner votre installationBien dimensionner votre installationAi-je besoin d’une ferme de serveurs ?Ai-je besoin d’une ferme de serveurs ?

Type de ferme

Nombre utilisateurs

Commentaires

Serveur unique (SQL Express) ≤ 500 Pas de haute disponibilité

Serveur unique (SQL) ≤ 5,000 Pas de haute disponibilité

Ferme moyenne (2 x 1 x 2)

≤ 100,000 Pas de point unique de défaillance

Ferme importante (4 x 3 x 2)

≤ 500,000 Pas de point unique de défaillance

Principes de base pour les fermes :*

* : le nombre d’utilisateurs peut varier suivant les profils d’usage, le mix des opérations et le HW.

Bien dimensionner votre installationBien dimensionner votre installationAi-je Ai-je vraiment vraiment besoin d’une ferme de serveurs ?besoin d’une ferme de serveurs ?

Tout le monde veut une ferme … Utiliser le framework – comprendre les utilisateurs, les données et le matériel.

Comprendre les coûts et bénéfices de la haute disponibilité.

La plupart des pertes de services sont dues à des problèmes de configuration :

TESTER les scénarios de restauration / bascule.S ’assurer que les périphériques réseau sont correctement configurés.Utiliser MOM pour superviser les fonctions critiques.

Métriques pour la bêta 2 :30 RPS/Front-end Web (~ 200 000* pages/jour/serveur).

Scale Out : 8 Front-end Web => 1 serveur SQL.

* Requêtes sur les pages qui ne sont pas en cache

Autres facteursAutres facteurs

Nouvelles fonctionnalités : Sécurité au niveau des éléments.Enrichissement de l’interface.Audit.Indexation de grandes listes.Mise en cache : BLOB, Outputs.Réduction de la taille des pages.

Sécurité :SSL et IPSec.Sélection de l’authentification : Kerberos, autres providers, etc.

Réseau :Cartes, switches, routeurs, pare-feux, etc.Contrôleurs de domaine / Front end Web.

Résolution de problèmesRésolution de problèmesDébit faible :

SQL – Utiliser les bonnes pratiques SQL pour les performances, spécialement les performances disques. Conflits entre les opérations asynchrones et le timer job. Contention de ressources : nombre d’applications Web, de pools d’applications, de bases de données, etc.Analyser dans tous les codes maisons ou modifiés les dialogues SQL et charges utiles. Rechercher les composants réseau mal configurés (cartes, routeur, etc.).

Temps de réponse élevé pour les utilisateurs :Taille des pages :

OOB, téléchargement de la 1ère page ~ 200 Ko ; ne devrait pas être beaucoup plus élevé.Utiliser la compression des pages si possible.

Stratégie de cache : activer la mise en cache des BLOB et Output lorsque c’est possible.Spécification des machines clientes. Problèmes réseau (voir ci-dessus).

Tester votre environnementTester votre environnement

Outils :Visual Studio Team System (VSTS-T).Microsoft Operations Manager (MOM).

Usages :Créer des utilisateurs.Charger des données.Créer des tests simulant des pourcentages d’usage.Varier les tests, les facteurs d’environnement, etc. pour identifier les points de blocage.

Quand ?Déploiements initiaux. Nouvelles configurations HW.Validation de solutions personnalisées.