Mise en place d'un cache serveur - WP Tech Nantes 2014

La performance, c’est le mot clef essentiel pour tout propriétaire de sites internet depuis quelques années. Un site performant est une obligation à la fois pour vos visiteurs, mais également pour le bon référencement naturel de votre site.

Avec WordPress, l’idée de performance est systématiquement associée à plugins de cache, dont les plus connus WP Super Cache, W3 Total Cache domine assez largement le marché !

Mais au fond, est-ce vraiment à l’applicatif PHP (WP + Plugins) de proposer cette fonctionnalité alors qu’il existe des logiciels de plus haut niveau dédiés à ce besoin.

Cette session aura comme objectif de démystifier l’approche cache serveur, de la théorie à la pratique, avec des démos lives, et des chiffres à l’appui !

Transcript

1. MISE EN PLACE D’UN CACHE SERVEUR Atelier
2. VOTRE ORATEUR Amaury Balmer  Directeur technique de l’agence web WordPress BE API Expertise technique WordPress et industrialisation WP Addict since 2005 ! Twitter @herewithme @be_api Web herewithme.fr beapi.fr
3. PROMESSE La performance, c’est le mot clef essentiel pour tout propriétaire de sites internet depuis quelques années. Un site performant est une obligation à la fois pour vos visiteurs, mais également pour le bon référencement naturel de votre site. Avec WordPress, l’idée de performance est systématiquement associée à plugins de cache, dont les plus connus WP Super Cache, W3 Total Cache domine assez largement le marché ! Mais au fond, est-ce vraiment à l’applicatif PHP (WP + Plugins) de proposer cette fonctionnalité alors qu’il existe des logiciels de plus haut niveau dédiés à ce besoin. Cette session aura comme objectif de démystifier l’approche cache serveur, de la théorie à la pratique, avec des démos lives, et des chiffres à l’appui !
4. RÉDUIRE SON “TTFB“ EST CRUCIAL ! TTFB = Time To First Bytes Conséquences :  3+ secondes = Urgence  1-3 secondes = Acceptable  500ms – 1000ms = Rapide  <100ms – Fluide !
5. LA THÉORIE
6. COMMENT FONCTIONNE LE WEB (STATIQUE) ? 1. Un navigateur demande à consulter une page web 2. Le serveur HTTP reçoit la demande la requête 3. Le serveur HTTP ouvre le fichier HTML demande 4. Le serveur HTTP renvoi la page au navigateur Simple et rapide !
7. COMMENT FONCTIONNE UN SITE WP ? 1. Un navigateur demande à consulter une page web 2. Le serveur HTTP reçoit la demande la requête 3. Le serveur HTTP transmet la requête à un processus PHP 4. Le processus PHP lance WordPress 5. WordPress exécute ses requêtes auprès de la BDD MySQL 6. WordPress génère le code HTML 7. Le processus PHP renvoi le code HTML au serveur HTTP 8. Le serveur HTTP renvoi la page au navigateur Lourd et complexe !
8. 1, 2, 3, 4 CACHES ? Le cache DB Le cache opcode Le cache objet Le cache statique
9. WORDPRESS
10. VOUS AVEZ DIT PLUGIN ? WP Rocket WP Super Cache W3 Total Cache Hyper Cache WP Fastest Cache Quick cache Batcache Memcached Object Cache APC Object Cache Redis Object Cache WP File Cache File-Based Cache DB Cache reloaded
11. POURQUOI LES PLUGINS ? Compatible avec les hébergements mutualisés Intégré à WordPress  Hookable Bon niveau de performances
12. POURQUOI CHANGER ? Architecture multi serveurs ? Performances / Haute disponibilité ! Dépendance au serveur HTTP Apache Approche WordPress Multisites aléatoire Performances ?
13. WP CACHE ET WP SUPER CACHE Juillet 2007 1ère solution hybride entre le cache applicatif et le cache serveur HTACCESS
14. LES TECHNOS SERVEUR
15. NOUVEAU VOCABULAIRE Cache statique = Reverse proxy
16. KESAKO ? Proxy Le principe de fonctionnement basique d'un serveur proxy est assez simple : il s'agit d'un serveur "mandaté" par une application pour effectuer une requête sur Internet à sa place. Reverse Proxy On appelle reverse-proxy (en français le terme de relais inverse est parfois employé) un serveur proxy-cache "monté à l'envers", c'est-à-dire un serveur proxy permettant non pas aux utilisateurs d'accéder au réseau internet, mais aux utilisateurs d'internet d'accéder indirectement à certains serveurs internes.
17. VARNISH CACHE Serveur de cache HTTP Apparu en 2002 Distribué sous licence BSD Version stable 3 et 4 Version commerciale : VARNISH Plus
18. NGINX Serveur HTTP et de cache HTTP Apparu en 2006 Distribué sous licence BSD Version stable 1.6 et 1.7 Module de cache : fastcgi_cache Version commerciale : NGINX Plus
19. DES AUTRES •Litespeed Cache •Squid Mais vieux, payant et peu répandu…
20. BENCHMARK Essayons…
21. SITE DE DÉMO WordPress 4.0.1 Un thème premium choisi aléatoirement « Jupiter » Des contenus de test Page d’accueil 42 requêtes HTTP 2Mo environ
22. 9 CONFIGURATIONS Apache Apache + 1 plugin (WP Cache) Apache + 1 plugin (WP Super Cache) Apache – FPM Apache – FPM + 1 plugin (WP Super Cache) Nginx – FPM Nginx + 1 plugin (WPSC) Nginx + Fast CGI cache Varnish + Apache - FPM
23. MÉTHODOLOGIE 1 serveur VPS loué pour l’occasion  64 bits  2 vCPU  2 Go de RAM  Debian 7.0 Outil de benchmark  Apache HTTP server benchmarking tool : AB Paramètres  ab -n 100 -c 5 http://vps118432.ovh.net/  200 requêtes, 5 concurrentielles
24. 1,8 20 34,2 1,9 43,5 1,9 48 49,7 53,1 0 10 20 30 40 50 60 Apache Apache + 1 plugin (WPC) Apache + 1 plugin (WPSC) Apache – FPM Apache – FPM + 1 plugin (WPSC) Nginx – FPM Nginx + FPM - 1 plugin (WPSC) Nginx + FPM - Fast CGI cache Varnish + Apache - FPM Requêtes par secondes Pages par secondes
25. RÉSULTATS Configuration Requêtes / seconde Apache 1,8 Apache + 1 plugin (WPC) 20 Apache + 1 plugin (WPSC) 34,2 Apache – FPM 1,9 Apache – FPM + 1 plugin (WPSC) 43,5 Nginx – FPM 1,9 Nginx + FPM - 1 plugin (WPSC) 48 Nginx + FPM - Fast CGI cache 49,7 Varnish + Apache - FPM 53,1
26. ATELIER 1 Installation de Varnish
27. CONTEXTE ET PRÉ-REQUIS 1. Un serveur dédié ou virtualisé sous Linux 2. Un accès SSH (root) 3. 10 minutes 4. Une installation WordPress avec Apache
28. VARNISH EN PRATIQUE 1. Un fichier de configuration VCL  Temps d’expiration  Règles de compression  Exclusions 2. Un plugin WordPress  Demande de purge  WP-Varnish ou Varnish HTTP Purge
29. TROUVER LE BON VCL ?
30. NOTRE VCL ! https://github.com/BeAPI/wp-varnish Mashup de pleins VCL ! • Expiration des pages 2H • Ressources statiques (expiration/compression) • Exclusion cookies / backoffice • Gestion des purges manuelles • Verbeux !
31. INSTALLATION 1. Installation de Varnish 2. Configuration des ports de Varnish et Apache2 3. Mise en place la VCL 4. Reboot des 2 services 5. Test et enjoy !
32. ATELIER 2 Installer Nginx et son cache
33. CONTEXTE ET PRÉ-REQUIS 1. Un serveur dédié ou virtualisé sous Linux 2. Un accès SSH (root) 3. 15 minutes 4. Une installation WordPress avec Apache 1. PHP via FPM / HHVM
34. NGINX EN PRATIQUE 1. Un fichier de configuration  Temps d’expiration  Règles de compression  Exclusions 2. Un plugin WordPress  Demande de purge  NGINX helper
35. HTTP://CODEX.WORDPRESS.ORG/NGINX
36. HTTPS://RTCAMP.COM/WORDPRESS-NGINX/TUTORIALS/
37. INSTALLATION 1. Installation de Nginx 2. Configuration pour WordPress 3. Test 4. Activation du cache statique dans Nginx 5. Test et enjoy !
38. LEQUEL CHOISIR ?
39. VARNISH Un stack classique ! Varnish + LAMP Apache donc support des htaccess Plus flexible sur les règles de purge Support ESI
40. ESI
41. NGINX Adapté au environnement avec peu de ressources ! VPS avec 256 Mo de RAM ! Support de HTTPS 1 logiciel pour tout faire ! Configuration spécifique au type de WordPress installé ! Monosite / Multisite sous domaines – sous répertoires
42. ATTENTION !
43. EMPILER LES TECHNOS DE CACHE 1. Varnish 2. Nginx 3. WP-Super-Cache Possible, mais complexe à purger !
44. MERCI ! Des questions ?