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

job@oxalide.com