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.