© OCTO – Technology 2005 Evaluez les performances de vos applications Eric Groise [email protected] Messaoud Oubechou [email protected]

© OCTO – Technology 2005

www.octo.com

Evaluez les performances de vos applications

Eric Groise [email protected]

Messaoud [email protected]

Brief Microsoft Performance Applicative© 2005 - OCTO Technology

L’Architecture au cœur du Système d’Information

Centrées autour de l’architecture, nos prestations vous permettent :

De piloter plus facilement votre SI

De concevoir vos projets de manière plus structurée, tant sur le plan fonctionnel que technique

D’industrialiser la mise en œuvre des projets, des phases de développement aux phases de production

Pour en savoir plus : www.octo.com

L’Architecture : un puissant outil de communication entre les différents acteurs que sont les directions, les métiers et l’informatique


Connaissances requises pour la session

Connaissance du .NET Framework Développement en .NET


Agenda

Introduction Objectifs et démarche Phases d’architecture et de

conception Phase de développement Phase de mesures et tests


Agenda




Introduction

2005 : Les mises en production .NET !

La phase d’industrialisation est en cours Usines de développement .NET L’exploitation des applications

Deux classiques des études:1. La sécurité applicative

2. La performance applicative

Messaoud OUBECHOU

Source : http://www.microsoft.com/france/msdn/devdays2005/programme.mspx


Le scope de cette session

De quoi parlerons-nous ? La démarche projet La performance au niveau applicatif En plateforme .NET

• WebForms ET WinForms Avec tous les langages de la plateforme

De quoi ne parlerons-nous pas ? De la performance des développements Des aspects purement système Des aspects purement réseau


Qu’est ce la performance ?

Ne pas confondre performance avec … … la haute disponibilité… … la « scalabilité ».

De même, les performances ne se limitent pas aux temps de réponse, ni au « tuning » technique

« Une application performante est une application qui réalise ce qu’on lui demande dans les contraintes imparties »


Les bonnes questions

Quels sont mes objectifs de performance ?

Où / quels sont les impacts sur mon projet ? …sur mon architecture ? …sur mon développement ? …sur mes tests ?

Quel outillage adopter ? A quel moment ? Par qui ?

Comment mesurer, suivre, voir anticiper les performances de mon application ?


Cela dit, on ne vérifie pas…

… la cohérence globale de l’application et notamment Que les normes de développement ont bien été respectées Que l’application est maintenable

… la disponibilité globale de l’application Une application peut supporter une forte charge sans pour autant

être hautement disponible

… que le comportement fonctionnel de l’application est celui attendu C’est le domaine des tests fonctionnels Il peut y avoir un intérêt à exécuter des tests fonctionnels en

parallèle de tests de charge• Afin de vérifier que le comportement fonctionnel ne change pas

en fonction de la sollicitation


Agenda




Objectifs de l’évaluation des performances

Identifier des problèmes de performance flagrants

Connaître les limites de l’application

Valider le fonctionnement de l’application aux limites

Permettre d’apprécier la capacité d’évolution de l’application


Définition

… en somme, il s’agit de valider que l’application respecte le SLA spécifié.

L’ingénierie de la performance applicative comprend : Une démarche

• itérative • à partir d’un modèle de performance partant du SLA (temps de

réponse, bande passante, ressources).

Elle impacte notamment sur les phases projet architecture / conception, développement, mesure et test

Mais pas que…

Des outils• Positionnés dans les phases du projet


Les étapes de la démarche 1/2

Définition du ‘modèle de performance’ Bénéficier d’une vision claire sur les besoins, contraintes et objectifs Se donner les moyens de challenger la conception vis-à-vis de ces objectifs

En phase d’Architecture et en phase de Conception, cela revient à à concevoir une application tiendra les promesses Avoir une vue claire sur la chaîne de communication Pousser des patterns orientés performance Faire en sorte que la conception pourra a minima tenir ses promesses Positionner une revue d’architecture

En phase de Développement, cela revient à développer suivant l’architecture et la conception définies, puis à optimiser S’inscrire dans le modèle d’architecture défini Faire selon les patterns définis par l’architecte Analyser et optimiser par couches A éviter : l’anti-pattern de la micro-optimisation trop tôt !


Les étapes de la démarche 2/2

En phase de Test, cela revient à s’assurer que la conception teint effectivement ses promesses Identifier les métriques appropriées Procéder à des tests de charge Acquérir et analyser les métriques En cas d’échec, ré-itérer en revoyant le modèle… etc. etc.

En phase d’Administration et d’exploitation, L’aventure commence (presque) ! Suivre l’évolution des métriques Idéallement : être proactif, pas réactif


Les objectifs du modèle

Aligner les objectifs de performance sur le contrat de service attendu et sur le budget.

Pourquoi se concentrer sur l’architecture et la conception ?

Par expérience :

1. Les causes aux problèmes de performance sont le plus souvent introduites très tôt dans le projet (phase d’architecture – conception)

2. De plus, ces problèmes ne sont hélas pas résolvables par du simple tuning ou en optimisant juste un bout du programme

3. Plus on corrige tardivement dans le projet, et plus ça coûtera cher.


Caractère itératif de la démarche

Etablir le « modèle de performance » Notez que l’aspect fonctionnel n’est pas neutre

Itérer sur l’architecture et la conception, la mise en œuvre et la validation


Les questions que l’on se pose… en vrac…

Quelles sont mes contraintes en temps de réponse : seuil max ? moyenne ?

Quel chemin du programme est critique pour les performances ? Où l’accès aux ressources est-il critique sur les performances ?

Quelle est la bande passante à ma disposition? Combien de RAM & swap sont à ma disposition ? Quelles sont les caractéristiques du DD (temps d’accès, vitesse…) et du CPU ? …

Quelle couche accède aux ressources et serait susceptible d’aboutir à une contention ? Quel est le code le plus fréquemment appelé ? Où sont les appels synchrones et asynchrones ? Quel code accède aux ressources ? Est-ce en local ou en distant ? Qu’est-ce qui pourrait surcharger la CPU (algo de tri, serialization XML, volumétrie de

donnée…) ? Les I/O disques ? Les I/O reseau (Web Service verbeux ? WS gourmand en données) ? …

Qu’est-ce qui pourrait amener à un problème de latence (initialisation de ressources : pool de cnxions, …) ?

Où sont gérées les transactions ? Quel est le niveau d’isolation ? L’interopérabilité est-elle requise ? M’est-il possible de cacher des données ? Serait-il possible de pré-calculer ou de pré-agréger des données ? Quels impacts sur mes performances sont liés à la sécurité ? Mon client est-il susceptible de « ramer » ? Serait-ce mon serveur ? Et la latence dans

tout cela ? etc. etc.


Structure du modèle

Cas d’utilisation pertinents Mais sur quels critères de choix ?Le tryptique : fonctionnel, technique, à l’usage.

Les objectifs de performance (BN) : temps de réponse, charge (volumétrie, nb users total / concurents, …), …

Les contraintes (BB) Régime de croisière et pic d’activité Les configurations matérielles

Les cas d’utilisation des tests, leur répartitions et leurs objectifs-> « L’application devra supporter 500 utilisateurs connectés dont 50 réalisant un acte d’achat. Cet acte dure en moyenne 7 minutes. »

-> Homepage recherche ‘Add to basket’ Vue du panier + ’Check out !’ identification paiement ‘Merci !’ réception de mail de confirmation

L’architecture générale


Qui fait quoi ?

Consultants fonctionnels

Aident à l’établissement de scéanrii de test le + proche possible des conditions de production : scénarii, jeu de données, nb users, …

Architectes logiciels Conçoivent une architecture en ligne avec le SLA attendu

Vérifient que l’architecture « tiendra ses promesses »

Développeurs Conçoivent des briques logicielles en ligne avec le SLA attendu

Vérifient que la conception « tient ses promesses »

Testeurs Déroulent les scénarii de test

Challengent les résultats par rapport aux objectifs

Administrateurs Posent les métriques

Vérifient l’adéquation du modèle à la réalité

Alertent en cas de divergence

Chef de projet Orchestre les interventions

Priorise les actions

• Conclusion : le problème est transverse.• Les performances ne concernent pas « que » le développeur… !


Bénéfices du modèle de performance

La performance est une fonction native de la conception

Ses réponses en terme d’architecture et de conception sont connues et maîtrisées

Les surprises en production sont évitées par une démarche proactive

Les scénarii de test sont formalisés Ils nous indiquent où axer les efforts techniques Ils nous indiquent quoi tester unitairement Ils nous indiquent où instrumenter Ils nous indiquent si on est ou pas dans les clous

Instancier un gabarit documentaire du modèle… et le faire vivre.


Agenda

Introduction Objectifs et démarche Phases d’architecture et de conception Phase de développement Phase de mesures et tests


L’architecture

Architecture Fonctionnelle Les acteurs fonctionnels

Architecture Applicative Les « briques » applicatives

Architecture Technique Les technologies en détail

Architecture Physique Les machines et le réseau


Quand faire de l’architecture ?

Vous ne pouvez pas commencer les développements sans un minimum d’architecture

Architecture Fonctionnelle• Modèles Fonctionnels

Architecture Applicative• Cartographie Applicative

Architecture Technique• Socle Technique

Architecture Physique• Cible

L’architecture Technique et Physique s’affinent durant l’avancement du projet


L’architecture et les performances

« Elle définit votre marge de manoeuvre en terme de performances »

Ne pas sombrer dans le « jusqu’au bout-isme » S’assurer que les objectifs demeurent

atteignables Prévoir des « plans B »


Brique applicative

IHMIHM

TraitementsTraitements

DonnéesDonnées


Cartographie Applicative


L’architecture applicative

Caractériser les briques Patterns, anti-patterns

Identifier les relations Criticité d’une brique Dépendances

Identifier les flux Contraintes réseau


L’architecture Technique

Navigation, Vues, Multilangue

Commandes

Services sans contextes, DataSet & DTO

Appels de proc-stock

Client Riche + AutoUpdate

Procédures-stockées


Architecture applicative

IHMIHM

Services MétiersServices Métiers

Services de donnéesServices de données


Les limites du modèle

Les problèmes de performances :

IHM• Trop d’appels de services• Binder des objets

Services métiers• Trop d’objets tuent l’objet• Trop d’appels de services de données

Services de données• Le MPD



IHM Services métiers Tout service IHM s’appuie-t-il sur un service métier ? Il n’y a vraiment aucun « traitement » dans l’IHM ? Bind de DataSet ou d’objets .NET ?

Les constats Tous les « services » ne font pas des traitements

• Exemple : Table Objet métier DataSet

Plus on colle aux scénarios IHM, plus on est économe• Exemple : TreeView interactive

Le SGBD est bien plus performant que le code .NET managé pour l’agrégation et la recherche.


Services IHM

IHMIHM



ServicesServicesIHMIHM



Services Métiers Services de données Rôle de la procédure stockée ? Mapping Objet – Relationnel ?

Les constats Le SGBD est souvent plus performant que du

code .NET managé

Faire un service ne garantit pas qu’il soit réutilisable ni pérenne

Le mapping objet-relationnel coûte cher


Architecture applicative

IHMIHM



ServicesServicesIHMIHM


L’architecture technique

« Avoir le maximum de cartes possible dans son jeu »

Connaître « tout » .NET• Remoting, Services Components, Messaging…

Connaître les produits Microsoft• SQLServer, Biztalk, MSMQ…

Connaître les offres externes• Editeurs• Open Source



De premier niveau Atteindre les objectifs de performance, mais pas plus !

• Prototypes• Test de charge

Cas du régime de croisière

De deuxième niveau Définir des architectures de secours

• Plan B• Scénario « surdimensionné »

Cas du pic d’activité

De troisième niveau Plannifier les évolutions dans le temps Anticiper leurs impacts



- Notification temps réel- 2000 Clients simultanés- Pointes critiques à 100 tps

Prototype Remoting Single Call TCP OK pour 100 tps sur WorkStation Test de 200 clients

Assurances : Pooling des Channels Load Balancing



WinForm,Grid Open Souce

Log4Net, Remoting

Remoting Single Call TCP, Service NT, Log4Net

Olymars

EXE C# AutoUpdate (WebService & ZIP)

SQL Server

+ Pooling

Grid DevExpert

+ DLL C++

s


L’architecture physique

Contraintes matérielles RAM CPU Disque Dur

Contraintes réseau Bande passante Usage CPU (SSL, VPN)

Topologies physiques Distribué Cluster, Load balancing


Conception

Un bon MCD/MPD vaut de l’OR

Le « tout objet » tue les performances


Agenda

Introduction Objectifs et démarche Phases d’architecture et de conception Phase de développement Phase de mesures et tests


Phase de développement

Surveiller où en en est pendant les développements

Faites régulièrement des tests de performance • unitaires• d’intégration (chaînes)

Mais priorité … … aux fonctionnalités … à la maintenabilité

… en phase de développement on optimise après avoir codé.



Le processus d’optimisation des performances du développeur :



Les outils :

Les assistants Le bench Le profiling



Les assistants :

Des outils qui font de véritables revues de code FxCop Total .Net Analyser, DevAdvantage (plugin VS),

DevPartner…

Des métriques Outils de refactoring VIL



Demo

Les assistantsLes assistants



Les benchs :

Outils classiques de bench Microsoft Application Center Test / Web Application

Stress Tool Open STA …

Benchs continus NUnit / MBUnit NUnitForms



Demo

Les benchsLes benchs



Le profiling : suivre l’exécution du code

Temps d’éxécution Qui est lent ?

Parcours Qui est le plus critique ?

Ressources Qui est le plus gourmand ?



Demo

ProfilingProfiling



Quelques classiques .NET :

Debug / Release Utilisez les possibilités du debug/release pour limiter les impacts en terme

de performance

Garbage Collector Il ne vous rend pas toujours service !

Boxing / Unboxing Sympa, mais coûte cher

Le ViewState Idem

Le Cache

Classes String et StringBuilder Si on instancie beaucoup de String, passez en StringBuilder C’est le cas pour l’opérateur « + » entre strings



Demo

Quelques classiquesQuelques classiques


Agenda

Introduction Objectifs et enjeux Phases d’architecture et de conception Phase de développement Phase de mesures et tests


Mesures et tests

Objectif Valider que les objectifs du modèle de performance sont atteints

Activités 1. Mesurer 2. Tester 3. Optimiser

Le processus est itératif


Mesurer

Objectif Déterminer les métriques techniques à retenir Identifier les points de contention

Outils d’acquisition

Les compteurs de performance

Et l’instrumentation applicative


Mesurer > compteurs de performance

4 « niveaux » de compteurs Réseau Système Plateforme .NET Applicatif

Les (nombreux) compteurs de performance Les compteurs génériques

• Processor, memory, disk I/O, network I/O Les compteurs spécifiques .NET

• Framework : memory, exceptions, contentions, threading, …• ASP.NET (response time, errors, cache, sessions, TX…)• WS, remoting, interop, ADO (TX, cache, pool, index, ...), …

Les compteurs personnalisés


Mesurer > instrumentation applicative

Windows Management Instrumentation (WMI) Natif à windows. Large support par les constructeur Ecrire dans un ‘sink’ WMI est peu performant. Use case : remonter d’erreurs critiques (matérielles, …)

Enterprise Instrumentation Framework (EIF) Natif à .NET. Nombreuses destinations (SQL, event log, fichier, …).

Encapsule WMI, event log et ETW. Scope large : trace, log, audit… configurable (« on/off », et niveaux)

: pérenne ? Use case : instrumentation, entre autres... Nouveauté (01/2005) : les « Enterprise Libraries », Application Block 2ième

génération

Attention aux critères : performance, intrusivité et configurabilité.


Phase de mesure

Demo

Instrumentation applicativeInstrumentation applicative


Tester

Types de tests « Load test » « Stress test »

Exemple : le test de charge La démarche L’activité clé : déterminer la charge à injecter : nb user

simultanés, nb de pages vues, la latence utilisateur, répartition des users dans les scénarii…


Tester la charge > analyser

Résultats théoriques 3 axes clés à challenger au regard du nb de users simultanés

Analyse

Parfois, la réalité n’est pas la théorie à 100 % Hélas, pas de recette « miracle » : c’est du « cas par cas »


Test de charge > optimiser

La question : quel est le premier goulot d’étranglement et « rectifier le tir » (web, appli web, sgbd) ?

Bests practises Utiliser une charge constante Appliquer un seul changement à la fois Prioriser les problèmes à résoudre

Techniques d’optimisation Les classiques : CPU, I/O disque, I/O réseau, SQL Server (idx, vues, sp, agrégats,

triggers, …) Tips d’optimisation en .NET :

• ASP.NET, • ADO.NET,• WS, • ES, • Remoting

Vérifier l’optimisation Re-tester, encore et toujours…


Phase de test

Demo

Test de chargeTest de charge


Best practices

Si vous ne deviez retenir que 5 idées

D’abord, pensez-y le plus tôt possible SVP : soyez « proactif ».

Ensuite, établisser un modèle simple en partant du besoin et des contraintes.

Finalement, évaluez la palette de possibilités mais avec pragmatisme (architecture, conception, développement).

N’oubliez pas qu’un bon outillage est un élément clé du succès.

Finalement et surtout :testez, re-testez, re-re-testez… et [re\-]*testez !


Au fait !

Comment foirer une appli ?


Questions ?


Ressources

Un excellent PAG : msdn.microsoft.com/library/default.asp?url

=/library/en-us/dnpag/html/scalenet.asp : 1 mine d’or & 1 bon guide CLR Profiler 2.0, EnterpriseServicesPerf code sample et

« Performance Considerations for Run-Time Technologies in the .NET

Framework » sur msdn.microsoft.com/downloads/

NPerf sur CodeProject.com www.OpenSTA.org FXCop, Allocation Profiler sur GotDotNet.com MS WAST et EIF en libre download sur microsoft.com

Documents

© OCTO – Technology 2005 Evaluez les performances de vos applications Eric Groise [email protected] Messaoud Oubechou [email protected]