#Drupagora Présenté au forum Drupagora 2013 par Guillaume Leccese - directeur technique d'Oxalide N'hésitez pas à nous contacter pour plus d'informations : contact [at] oxalide [point] com

1. La performance de vos applications Drupal

3. La performance de vos
applications Drupal
OPS : 1ère partie
• Définir les KPI
• Mesurez la performance
• Les best practices OPS
DEV : 2nd part
• Cache TAGS
• Pluggable Asset Optimization

4. Les KPI

5. Les KPI métier
Avec des métriques UX et Marketing
– Un temps de réponse maximum, moyen
– Un nombre de requête par seconde (avec un temps de réponse
maximum aussi)
– Nombre de connexions simultanées
– Nombre de visiteur sur une période
– Capacité de montée en charge sur une courte période (ex : 1000
connexions en 5 minutes)
• Etc …
• En gros, les SLA « applicatives »

6. Les KPI « infra »
Taux d’occupation
des serveurs
Consommation
mémoire
Bande passante
utilisée
Mesurer l’utilisation
des middlewares

7. Le test de performance
Mesurer la performance

8. L’objectif
Test de performance
Détecter les leviers pour améliorer la performance
0
L’infrastructure
L’application
Définir une valeur
référence

9. L’objectif
«
Plus que la charge, c’est le comportement des visiteurs
et leurs incidences sur l’application et l’infrastructure
KPI CLIENTS
SCENARIO
LES POINTS
DE RUPTURE
»

10. Le scénario
Appliquez un scénario proche de la réalité
eCommerce
Home page
Catégories
Produits
Tunnel de paiement
Presse
Home page
Rubriques/Sous-rubriques
Articles
Commentaires
Institutionnel
Home page
Contact
Articles

11. Quand réaliser un test de performance ?
En continue dans le planning
avant le passage en production
dans des cycles de build et de run

12. Quelques outils
Mais aussi
• Siege
• Apache Bench

13. Résultat d’un test de performance
Profiling
Xdebug + webgrind
Xhprof

14. La performance avec Drupal

15. Drupal d’un point de vue OPS
Consommation CPU
La consommation mémoire
des processus Apache (PHP)
La bande passante entre
les frontaux et la base
et/ou memcached et du
coup aussi le nombre de
requête dans MySQL

16. Où aller chercher de la performance ?
CLIENT
DEV
x 100
de performance
supplémentaire
MOA
Application
Architecture logicielle
Infrastructure
DEVOPS
5 à 10 %
de performance
supplémentaire

17. L’optimisation d’une requête SQL
CPU taux d’occupation
80% à 10 % d’occupation
DIVISÉ PAR 8
Load average
15 à 2
DIVISÉ PAR 7,5
Accès à innodb en lecture
1,46 m à 295,9 ko
DIVISÉ PAR 5

18. La dette technique
faible
important
Temps de traitement et de réponse

19. La protection des ressources
1er rempart
2ème rempart
3ème rempart
4ème rempart
Query Cache
Memcached
APC
100 %
90 %
10 %

20. Une architecture Drupal scalable
dédié
frontaux
distant
séparée

21. Les best practice
Désactiver les modules inutiles
Désactiver le support des .htaccess (mais interdire la lecture !)
Charger toutes les règles de rewrite dans la configuration Apache
APC en tant qu’OPCode
Les sessions et la cache

22. Dans la pratique : test de performance
• Machine virtuelle 4vCPU (E5-2670) / 8Go de RAM
• Debian Wheezy 7.2
– Apache 2.2.22
– PHP 5.4.4
– MySQL 5.5.31
• Drupal 7
– Module View
– Devel pour générer du contenu
•
•
•
•
Méthodologie pour les tests :
Scénario Jmeter sur la home, 10 threads pendant 5 minutes
Dstat pour mesurer la consommation CPU
Gnuplot pour générer les graphes

23. Test #1
Aucune optimisation
Aucun Best Practice cité
Test #2
htaccess dans apache
Sans les logs
.htaccess désactives
Test #3
Ajout d’APC
521 ms
519 ms
228 ms
TEMPS DE REPONSES DIVISER PAR 2

24. Test #4
Tuning MySQL
innodb, query cache, table cache
Test #5
APC : apc.stats=0 (le « mythe »)
Test #5
CPU
228 ms
230 ms
CHARGE CPU A 100%

25. Test #6
On active la cache drupal
Test #6
Charge CPU
22,9ms
TEMPS DE REPONSES DIVISER PAR 10
CHARGE CPU REDUITE SIGNIFICATIVEMENT

26. Conclusion 1ère partie
Créer et partagez des
référentiels communs
Discutez des impacts
du code sur l’infrastructure

27. Intégrer la performance
dès le BUILD
Collaborez Dev et Ops

28. job@oxalide.com