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
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 »

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
0
L’infrastructure
L’application
Définir une valeur
référence

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
»

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 ?
En continue dans le planning
avant le passage en production
dans des cycles de build et de run

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
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

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

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

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

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

Une architecture Drupal scalable
dédié
frontaux
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
521 ms
519 ms
228 ms
TEMPS DE REPONSES DIVISER PAR 2

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%

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
Créer et partagez des
référentiels communs
Discutez des impacts
du code sur l’infrastructure

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

job@oxalide.com