Dans cette présentation, nous parlons du perfugma, des activités de performance, la supervision, les types de tests en performance

1. 1
Tél : +212 537 778 843
www.octo.com
© OCTO 2015
49 rue Jabal Tazzeka
10000 Agdal, Rabat - MAROC
07/05/2015
La performance des applications en production

2. 2
18:30 : Méthodologie de la performance (30min)
Landry DEFO KUATE (OCTO Technologies)
19:00 : Présentation technique des solutions de supervision (60min)
Mohamed RAHOU (adhoc-international)
20:00 : CA Technologies : outillage et produits
M’Hamed ARAHOU (CA Technology)
Contenu de la soirée

3. 3
Qui sommes nous ?
Landry
DEFO KUATE
Architecte @OCTO
Co-organisateur
« Perf-UG Maroc »
@defolandry

4. 4
Introduction au Performance User Groupe Morocco

5. 5
Wikipedia
« [Les tests de performance] vont avoir pour objectif
de mesurer les temps de réponse d'un
système applicatif en fonction de sa
sollicitation. Cette définition est donc très
proche de celle de test de charge où l'on
mesure le comportement d'un système en
fonction de la charge d'utilisateurs simultanés.
Seuls les tests de charge permettent de valider
correctement une application ou un système
avant déploiement, tant en Qualité de Service
qu'en consommation de ressources. »
Bienvenue au Performance User Group Maroc
Larousse
Résultat chiffré (en temps
ou en distance) d'un
athlète ou d'un cheval à
l'issue d'une épreuve.
La performance d’un
système informatique
est caractérisée par les
temps de traitement
dans un contexte et
sous une sollicitation
donnés.

6. 6
Notre vision ?
Source : www.arthursclipart.org
Les performances
d’un système sont une
spécification
fonctionnelle implicite
du système

7. 7
Notre vision ?
Source : Les géants du Web
La mesure de
performance doit être
au cœur du processus
de développement
informatique

8. 8
Notre vision ?
Source : Les géants du Web
Nous voulons des
systèmes performants

9. 9
Notre devise !
9
LES TEMPS DE RÉPONSE NOUS DIMINUERONS
LES DÉBITS NOUS AUGMENTERONS
LES RESSOURCES NOUS ÉPARGNERONS
LA HAUTE DISPONIBILITÉ NOUS
PRÉCONISERONS

10. 10
Notre mission
Source : perfUgMa #2
Offrir un lieu
d’échanges informels
où toutes les
personnes intéressées
par l’optimisation et la
performance sont les
bienvenues quel que
soit leur niveau

11. 11
Notre mission
11
Faciliter la diffusion
des derniers outils et
des meilleures
techniques pour
maîtriser au plus tôt la
performance d’un
système informatique

12. 12
Méthodologie de la performance

13. 13
Activités de l’ingénieur en performance applicative
L’audit (statique et dynamique) du code source de l’application
: Java, .NET, NodeJS, PHP, SQL, …
Les tests de l’application
La supervision applicative (Application Performance
Management)

14. 14
Supervision applicative
APM : Application Performance Management

15. 15
APM (Application Performance Management)
Permet de contrôler la performance des applications
métiers et de mettre en avant rapidement d'éventuels
problèmes, directement liés aux logiciels, voire même à
leur environnement (réseau, système, base de données...)
EUM (End User Monitoring)
Permet de mesurer la performance d’une application à
partir de l’environnement de travail de l’utilisateur final
(navigateur, poste de travail, mobile) et non pas à l’entrée
du Datacenter seulement
Définitions APM & EUM

16. 16
Monitoring interne vs Monitoring externe
Portée du monitoring classique limité dans le data center
Dans le data Center :
• Réseau interne
• Applications .NET, Java,
PHP
• Bases de données
• Autres serveurs internes
Utilisateurs éloignés :
• Depuis un navigateur
• Depuis le mobile
• Application desktop
Data centerEnvironnement utilisateur final
• Problème de téléchargement des ressources
applicatives (Exemple QoS du FAI)
• Problèmes d’éxécution de la partie client des
applications riches reposant sur HTML5 et Javascript
(Exemple : stack AngularJs, GWT)
• Erreurs d’éxécution de l’application sur le poste
utilisateur (Erreurs Javascript)
• Indisponibilité de l’application à cause d’un problème
d’accès au réseau interne (Erreurs HTTP 404)
• Visibilité complète dans tout le datacenter

17. 17
Les types de tests en performance

18. 18
Les activités de l’ingégieur performance
Mise en place des
mesures et scénarios Exécution des
scénarios
Optimisation
Estimation des gains
potentiels
• Vérifier les
environnements
• Définition des scénarios
représentatifs pour
l’étape de tests de
charge
• Génération des jeux de
données
• Définition d’une cible à
atteindre
• Tests de charge avec
une volumétrie
représentative de la
production • Exécution de tests de
performance locaux sur
les « hot spot » et
tuning en fonction du
résultat
• Validation des
hypothèses
Tests de charge Tests de performance

19. 19
Les différents types de tests
• Objectif : mesurer la performance unitaire
• Ex : le use case de souscription est testé pour 1 utilisateur
et, pour chaque étape du use case, on mesure le temps
passé dans les différents composants de l’application
Test de
performance
• Objectif : mesurer la tenue en charge de l’application sur la
population cible
• Ex : on simule l’utilisation de l’application par 200 utilisateurs
en parallèle pendant 2h
Test de
charge
• Objectif : déterminer les limites de l’application
• Ex : on augmente le nombre d’utilisateurs en parallèle sur
l’application jusqu’à ce que le taux d’erreurs / les temps de
réponse ne soient plus acceptables
Test de
rupture
• Objectif : déterminer la capacité de l’application à fonctionner
sur une période étendue
• Ex : on simule l’utilisation de l’application pendant 48h, avec
une charge constante et égale à la charge moyenne
Test de
vieillissement

20. 20
Méthodologie pour un test de charge
Définition du plan et des
cas de test
Plan de test Cas de test
2 Création des scénarii et
des scripts de tests
3 Enregistrement des
métriques
4
Consolidation des
métriques et édition
d’un rapport de test
5
Analyse du rapport de
test et émission des
préconisations Rapport d’analyse
Métriques
Rapport de test
Contrôleur
Scripts de test Scénarii de test
Capture des
métriques
Application cible
Injecteurs
Données de test
1 Création des paliers de
données
Exécution : simulation
d’utilisateurs
1
3
3
20

21. 21
Les tests de performance
OBJECTIFS
Affiner l’analyse et la compréhension des problèmes de performance.
Tester différentes alternatives d’optimisation possible et mesurer les améliorations qu’elles
apportent.
Itérer facilement entre différentes optimisations possibles.
MÉTHODOLOGIE
L’objectif ici n’étant pas d’obtenir des mesures exactes, des instrumentations plus intrusives sont
envisageables
Les investigations sont réalisées
• Avec les sources du code
• Sur un poste de développement ou avec une manière de déployer très fréquemment
• Avec les droits d’administration pour réaliser tout cela….

22. 22
Principes d’optimisation logs des tests de performance
L’optimisation de performances se fait en intervenant sur plusieurs niveaux
• Ex : optimisation algorithmique, gestion du
multi-threading
Code et
architecture
applicative
• Ex : tuning des paramètresFramework
• Ex : taille des pools de
threads, taille de la mémoire
allouée à la base…
Couches basses : base
de données, serveur
d’application
• Ex : nb machines,
configuration
réseau…
Infrastructure

23. 23
La mesure est un point essentiel dans l’optimisation des performances.
Points de vigilance
L’infrastructure doit être proche de l’infrastructure cible pour que les
tests soient pertinents.
Les temps de réponse des systèmes externes sollicités doivent aussi
être consciencieusement mesurés.
Les jeux de données utilisés doivent être représentatifs des données
de production pour que les résultats soient pertinents

24. 24
recrutement@octo.com
Vous croyez que les technologies changent le
monde ?
Nous aussi ! Rejoignez-nous !

25. 25
Question ?
Questions ?