Download - La performance de vos applications Drupal
La performance de vos applications Drupal
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
Les KPI
Les KPI métier
– 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 »
Avec des métriques UX et Marketing
Les KPI « infra »
Taux d’occupation des serveurs
Consommation mémoire
Bande passante utilisée
Mesurer l’utilisation des middlewares
Le test de performance
Mesurer la performance
L’objectif Test de performance
Détecter les leviers pour améliorer la performance
L’infrastructure
L’application Définir une valeur référence
0
L’objectif
Plus que la charge, c’est le comportement des visiteurs et leurs incidences sur l’application et l’infrastructure
« »
LES POINTS DE RUPTURE
KPI CLIENTS SCENARIO
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
Quand réaliser un test de performance ?
avant le passage en production
dans des cycles de build et de run
En continue dans le planning
Quelques outils
Mais aussi • Siege • Apache Bench
Résultat d’un test de performance
Profiling
Xdebug + webgrind Xhprof
La performance avec Drupal
Drupal d’un point de vue OPS
La bande passante entre les frontaux et la base et/ou memcached et du coup aussi le nombre de requête dans MySQL
La consommation mémoire des processus Apache (PHP)
Consommation CPU
Où aller chercher de la performance ?
Infrastructure
Application
Architecture logicielle
MOA
DEV x 100
de performance supplémentaire
DEVOPS 5 à 10 % de performance supplémentaire
CLIENT
L’optimisation d’une requête SQL
Load average 15 à 2
Accès à innodb en lecture 1,46 m à 295,9 ko
CPU taux d’occupation 80% à 10 % d’occupation
DIVISÉ PAR 7,5
DIVISÉ PAR 8
DIVISÉ PAR 5
La dette technique
faible important Temps de traitement et de réponse
APC
Memcached
Query Cache
10 % 100 % 90 %
1er rempart 2ème rempart 3ème rempart 4ème rempart
La protection des ressources
Une architecture Drupal scalable
frontaux dédié distant séparée
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
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
Test #1 Aucune optimisation
Aucun Best Practice cité
Test #2 htaccess dans apache
Sans les logs .htaccess désactives
Test #3 Ajout d’APC TEMPS DE REPONSES DIVISER PAR 2
521 ms
519 ms
228 ms
228 ms
230 ms
CHARGE CPU A 100%
Test #4 Tuning MySQL
innodb, query cache, table cache
Test #5 APC : apc.stats=0 (le « mythe »)
Test #5 CPU
Test #6 On active la cache drupal
Test #6 Charge CPU
22,9ms
TEMPS DE REPONSES DIVISER PAR 10
CHARGE CPU REDUITE SIGNIFICATIVEMENT
Conclusion 1ère partie
Discutez des impacts du code sur l’infrastructure
Créer et partagez des référentiels communs
Collaborez Dev et Ops
Intégrer la performance dès le BUILD