Télécharger en tant que PDF, PPTX
Téléchargé parOxalide
La performance de vos applications Drupal
Le document décrit les étapes pour améliorer la performance des applications Drupal, incluant la définition de KPI et la mise en œuvre de tests de performance. Il fournit des best practices pour l'optimisation, notamment l'utilisation de cache et des outils de mesure. La méthodologie de test présentée démontre l'impact des optimisations sur les temps de réponse et la consommation des ressources.
La performance de vos applications Drupal
- 1. La performance devos applications Drupal
- 3. La performance devos 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.
- 5. Les KPI métier Avecdes 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 deperformance Mesurer la performance
- 8. L’objectif Test de performance Détecterles leviers pour améliorer la performance 0 L’infrastructure L’application Définir une valeur référence
- 9. L’objectif « Plus que lacharge, 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 unscé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 untest 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 testde performance Profiling Xdebug + webgrind Xhprof
- 14. La performance avecDrupal
- 15. Drupal d’un pointde 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 chercherde 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êteSQL 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 Tempsde traitement et de réponse
- 19. La protection desressources 1er rempart 2ème rempart 3ème rempart 4ème rempart Query Cache Memcached APC 100 % 90 % 10 %
- 20. Une architecture Drupalscalable dédié frontaux distant séparée
- 21. Les best practice Désactiverles 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 AucunBest 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 activela cache drupal Test #6 Charge CPU 22,9ms TEMPS DE REPONSES DIVISER PAR 10 CHARGE CPU REDUITE SIGNIFICATIVEMENT
- 26. Conclusion 1ère partie Créeret partagez des référentiels communs Discutez des impacts du code sur l’infrastructure
- 27. Intégrer la performance dèsle BUILD Collaborez Dev et Ops
- 28.