Drupal : Optimisation des performances
Qui? Guillaume Plessis Expert, Steady bean Mainteneur du projet Dotdeb Co-auteur «Performances PHP» Frédéric Marand Fondateur d OSInet Mainteneur Drupal Audit, conseil & formation Drupal
Serveur de référence Instance Amazon EC2 c1.xlarge : 8 cores Intel Xeon E5506 (2,13GHz, 64bits) 7Go de mémoire vive Debian 6.0.3 «Squeeze» + Dotdeb Apache 2.2 + PHP 5.3.8 + MySQL 5.1.58 Drupal 7.9
Les étapes 1.Bonnes pratiques Drupal 2.Savoir ce qui se passe 3.Analyser 4.Simuler 5.Améliorer
Bonnes pratiques Drupal Desserrer le frein à main Configuration Drupal par défaut : sûr, mais lent Utiliser les paramètres d accélération niveau de cache agrégation Coder dans les bonnes pratiques pièges courants : node_access vs. blocs, requêtes dans les thèmes développer en E_STRICT ( E_ALL < PHP 5.4) Pas de Dblog en production
Drupal Journaux & debug DBlog : en développement Syslog : en production Apache access.log : pour des scénarios de tirs de charge error.log : détection des erreurs applicatives PHP php.err : détection des erreurs applicatives Xdebug / Xhprof : traces pour le profiling MySQL journal des requêtes lentes et sans index journal général pour les scénarios de tirs de charge
Monitoring : pourquoi? Objectifs disponibilité stabilité Fournit des éléments d analyse Détecter les dysfonctionnements Anticiper le dimensionnement
Monitoring : outils Nombreux outils : Nagios et ses dérivés, Zabbix... Cacti, Munin PHP : Pinba Xhprof, APM Dtrace Zend Platform Drupal : MuninAPI
Monitoring : métriques OS : CPU, RAM, réseau Apache : Requêtes par seconde Temps de réponse PHP : Pinba Drupal : sessions, entités MySQL : Requêtes par seconde, connexions innodb_buffer_pool
Analyser : profiling Objectif détecter les goulots d étranglement performance! Outils Xdebug, Xhprof, Kcachegrind, webgrind, Zend Platform... Créer un environnement dédié
Simuler Objectifs détecter les goulots d étranglement qualifier une architecture Outils Jmeter, Funkload, Tsung, Siege, ab... / Simpletest Attention à l uniformité des tests! 15 req/s
Optimisation : PHP PHP n est souvent pas le responsable Sachez comment il fonctionne : script opcodes exécution optimisation, ré-ordonnancement mise en cache (attention à l invalidation) Outils disponibles : caches / accélérateurs : APC (3.1.6), Xcache, Zend Optimizer... caches : fichiers / memcached / Redis 123 req/s
Optimisation : serveur web Adapter la configuration à la machine Apache : KeepAlive ServerLimit, Maxclients MaxRequestsPerChild PHP : un memory_limit réaliste (2Go de RAM = 16 scripts PHP x 128Mo) configuration différente de la CLI (Drush) 154 req/s
Optimisation : serveur web Pistes pour Apache (prefork) : Désinstaller les modules non utilisés Activer les optimisations de compilation? Utiliser d autres serveurs HTTP plus légers : Nginx Lighttpd Utiliser un reverse-proxy / cache Utiliser un CDN 152 req/s
Optimisation : HTTP Beaucoup d améliorations possibles But : faire baisser la charge sur le serveur web Quelques pistes : Compression gzip/deflate (étendue + configuration Drupal) Connexions persistantes / pipelining / multiples serveurs de médias Eviter les JS synchrones ou en début de page Pas de fetches background synchrones ou de pages dans la page En-têtes HTTP efficaces : Expires etags reverse-proxys
Optimisation : MySQL Choisir le bon système (Linux : 2.6+, 64bits) la bonne distribution de MySQL (Oracle, Percona, MariaDB / 5.1, 5.5) le bon moteur de stockage (InnoDB/XtraDB, HEAP, Archive...) Proliling + EXPLAIN Optimisation via les logs Réplication Déport des données en NoSQL
Optimisation : architecture Scalabilité verticale : augmentation de la puissance du serveur horizontale : augmentation du nombre de serveurs Ouverture vers le Cloud
Architecture type
Questions? gui@php.net w_a_s_t_e fgm@osinet.fr osinet