Optimiser un site WordPress sur serveur dédié pour un trafic important

13
146

C’est une question récurrente dont beaucoup de personnes cherchent encore la réponse. Voici un article qui sors un peu des thèmes habituellement abordés sur UnderNews. Optimisation complète du système WordPress.

WordPress est un CMS très utilisé car il est plutôt performant (tant au niveau du code que du référencement) et malléable. Il convient parfaitement pour des blogs et des petits sites. Le seul problème, c’est que ses limites sont très vites atteintes en le laissant d’origine…

En effet, l’ajout de plugins, de thèmes sophistiqués et l’afflux de visites peuvent vite transformer la visite du site en calvaire. Si UnderNews publie aujourd’hui cet article, c’est parce que nous avons vécu exactement ce problème. Et nous pensons à ce jour avoir trouvé une solution viable, évolutive et efficace afin de garder notre système optimisé. Explications !

Avec quelques milliers de visiteurs quotidiens, un thème plutôt chargé et plusieurs dizaines de plugins, UnderNews est le parfait exemple pour illustrer ce tutoriel. Tout d’abord, voici l’évolution depuis l’ouverture du site :

  • Les deux premières semaines, hébergement mutualisé chez UnderHost
  • Basculement vers un serveur dédié Kimsufi entrée de gamme (2G) pendant environ deux mois
  • Migration en urgence vers un Kimsufi milieu de gamme (16G) suite aux down répétitifs du site
  • Et pour finir, installation il y a deux semaines à peine sur un Kimsufi 24G.

Jusqu’à aujourd’hui, le parcours a été long, hasardeux et plus que regrettable en terme de résultats. Mais cela a changé.

Le Kimsufi actuel, basé sur la release 2 d’OVH (Gentoo 64 bits) a été entièrement reconfiguré afin d’optimiser au maximum le site dans le but de le rendre fluide et d’éviter tout down. Inutile de dire que cet OS “made in OVH” est plutôt a éviter, mais nous manquions de temps… Un conseil pour les autres, passez directement sur un Debian “nu”, vous vous éviterez bien des soucis.

Donc ce tutoriel va se baser sur ce cas précis (notamment au niveau des commandes) mais il sera bien entendu applicable sur n’importe quel serveur.

Fini le blabla, entrons dans le vif du sujet !

Donc les prérequis sont :

  1. Un site sous WordPress
  2. Du temps
  3. Un serveur dédié (ou mutualisé mais peu de chance que la configuration soit compatible)

Dans le cas de la release 2 d’OVH, nous allons commencer par une mise à jour complète de l’environnement :

wget ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O install_rtm.sh; sh install_rtm.shwget ftp://ftp.ovh.net/made-in-ovh/release/patch-all.sh -O patch-all.sh; sh patch-all.shemerge --syncemerge portage (commande précédée de ln -sf /usr/portage/profiles/default/linux/x86/2008.0/ /etc/make.profile)

Maintenant, installons le nécessaire !

APC pour l’optimisation de PHP :

ln -s /usr/local/php5/bin/phpize /bin/phpizeln -s /usr/local/php5/bin/php-config /bin/php-configln -s /usr/local/php5/bin/pear /bin/pearln -s /usr/local/php5/bin/pecl /bin/peclcd /usr/local/srcwget http://pecl.php.net/get/APC-3.1.9.tgztar xvzf APC-3.1.9.tgzcd APC-3.1.9phpizeaclocallibtoolize --forceautoheaderautoconfmake./configuremakemake install

Memcached pour le cache des objets en mémoire :

cd /usr/local/srcwget pecl.php.net/get/memcache-3.0.6.tgztar zxvf memcache-3.0.6.tgzcd memcache-3.0.6phpizeaclocallibtoolize --forceautoheaderautoconfmake./configuremakemake installmemcached -d -u nobody -m 48 127.0.0.1 -p 11211rc-update add memcached default

# Editer le fichier de php.ini (/usr/local/lib64/php5/php.ini) puis ajouter :

extension_dir="/usr/local/php5/lib/php/extensions/no-debug-non-zts-20060613/"extension=memcache.soextension=apc.soapc.enabled = 1apc.rfc1867 = on

Redémarrage d’apache pour finir l’installation :

/etc/init.d/apache restart

Première étape terminée ! Passons au côté WordPress maintenant.

Désinstallation de tous les plugins inutiles et installation de W3 Total Cache (supprimer avant tout plugin de cache déjà présent).

On peut maintenant passer à la configuration de ce plugin de cache très complet, qui peut être difficile d’utilisation pour certain.

Alors, dans l’onglet général, on active la fonctionnalité “Page Cache” avec la méthode “Opcode: Alternative PHP Cache (APC)” (installé précédemment sur le serveur). Enregistrement et passage au menu de configuration avancée de “Page Cache”.

Vous avez ensuite le choix d’activer ou pas la fonctionnalité “Minify”. Sur UnderNews, cela n’est pas compatible et génère trop d’erreurs d’affichage sur le site, donc nous le laissons désactivé pour le moment.

Activation du “Database Cache” via la méthode Memcached, puis passage dans l’onglet de configuration avancée.

Activation de “Object Cache” via la méthde Memcached, puis passage dans l’onglet de configuration avancée.

Activation de “Browser Cache”, puis passage dans l’onglet de configuration avancée.

Voila, à ce stade, vous devriez voir un très grosse amélioration des performances. Pour ceux qui veulent aller plus loin, vous avez la possibilité de mettre en place l’utilisation d’un CDN (Content Delivry Network) ou encore de CloudFlare. N’oubliez pas de désactiver le mode “Preload” une fois votre configuration terminée.

Pour ce qui est de l’optimisation pure, c’est terminé. Maintenant, vous pouvez si vous pensez que cela vous ai utile, configurer votre serveur afin de bloquer d’hypothétiques attaques qui pourraient mettre en péril votre système.

Pour cela, dirigez vous vers Fail2Ban et le mod_evasive d’Apache. Je vous laisse le soin de chercher des exemples de configuration sur le Net, cela ne manque pas.

Vous voici fin près pour les tests ! N’hésitez pas à comparer votre score obtenu via l’outil Page Speed fourni par Google (ou l’extension Firefox), vous serez agréablement surpris. N’hésitez pas à nous faire parvenir vos réactions, remarques et résultats !

Pour ceuxx qui veulent en savoir plus sur WordPress et l’optimisation On-Site, vous pouvez vous tourner vers ce livre très complet : WordPress 3.5 pour des sites web efficaces : Administration, personnalisation, référencement, marketing, e-commerce, publication mobile.

13 Commentaires

  1. Faudrait mettre l’article à jours 🙁 car si on test votre site aujourd’hui, les résultat ne sont pas au rendez-vous .

    tools.pingdom.com
    gtmetrix.com

    • Bonjour,

      Tout à fait, cet article date de 2011 et n’est plus du tout d’actualité…

      Le serveur est maintenant beaucoup plus puissant et mieux configuré, et les scripts JS se sont largement multipliés sur le site. Néanmoins, la rapidité globale est bien supérieure maintenant. Comme quoi, avec une configuration serveur aux petits oignons, on peut faire des miracles !

      Les 2 outils cités sont utiles mais pas forcément juges ultimes : ils peuvent indiquer des optimisations pas forcément prioritaires en termes de performances 😉 A utiliser ne connaissance de cause et avec parcimonie.

  2. Bonjour, merci pour ce tuto,
    j’arrive pas à procéder à l’installation de APC, je reçoit un msg d ‘erreur concernant la commande -ln (il me demande de faire ln –help pôur l’aide mais je toruve rien !

  3. Bonjour,

    Je ne veux pas jouer mon kéké, mais je soupçonne que la faute repose en partie, non sur votre hébergement, mais sur ce que vous hébergez.

    Je parle de ce que je connais : mon cas personnel. J’ai quitté un XXLplan parce que j’arrivais aux limites de mon hébergement, tant en ressources CPU (environ 25 pics au-delà de 25% de la capacité CPU par jour) que du côté des bases de données (+10€/mois rien que pour un SQLprivé 256 MB capable de gérer une BDD de 4 Go.)

    Je suis passé à un Kimsufi 16G, avec installation par un infogérant (nom de boîte Syrelis, fortement recommandé) de debian squeeze, suhosin, Zend, Webmin+Virtualmin.

    Et j’ai pu faire héberger sur ce serveur un total de 60 000 visiteurs uniques wordpress et 30 000 visiteurs uniques sur du non-wordpress (CMS maison extrêmement léger mais générant une dizaine d’appels MYSQL à l’ouverture).

    Au bout d’une semaine, j’ai du faire un seul ajustement : augmenter à 300 le nombre de threads Apache permis.

    Et depuis, tout tourne parfaitement, avec un délai de chargement ridiculement bas (un tiers de seconde, contre facilement deux-trois secondes en XXLplan), une consommation de RAM et de CPU atteignant 60% de la capacité totale aux heures de pointe.

    Alors, bien sûr, mes blogs wordpress et mon CMS ont un cache (wp-supercache, cache maison simpliste pour le CMS), bien sûr ils ont des templates simples et pas des machines à gaz…

    Mais si je compare à ce que vous écrivez, “quelques milliers” de visiteurs vous faisant quitter un XXLplan (franchement : ça aurait été “quelques dizaines de milliers”, vous auriez plutôt écrit ça, hein ?), à mon avis ça veut dire que **quelque-chose** aurait pu être optimisé de votre côté, non sur l’hébergement, mais sur le blog.

    Je pense que vous avez encore beaucoup de marge d’amélioration pour peu que vous trouviez ce qui cause cette consommation de ressources 🙂

  4. bonjour, tuto intéressant toutefois je ne crois pas qu’APC cache fonctionne avec suPHP (la compilation de PHP) présente dans la release 2 d’OVH, etes vous sur que APC tourne ? que donne votre apc.php ?

  5. Excellent tutoriel sur l’optimisation de WordPress.

    C’est vrai qu’il est dommage que la plupart des utilisateurs de Wp soient (comme moi) sur un hébergement mutualisé et ne peuvent donc pas optimiser aussi bien leur serveur, notamment avec memcached dont tu parles ici.

    Je sais que d’autres optimisent également leur serveur avec mod_pagespeed de Google.

  6. Apache2 en config par défaut c’est pas le top non plus. Passez plutôt en worker (mais il faut une petite configuration de PHP supplémentaire) voire même utilisez carrément Nginx.

    Ensuite memcache + apc + W3 total cache c’est effectivement excellent. Et pour parachever un peu tout ça: Cloudflare.

    Avec ça un 16G est largement suffisant. (N’ayant aucune idée du nombre de visite je m’avancerai pas jusqu’à dire qu’un 2G irait, mais je suis pas loin de le penser)

    • Bonsoir,

      Du côté de la conf Apache pure, plusieurs choses ont été modifiées telles que MaxClients, ServerLimit, MaxKeepAliveRequests, KeepAliveTimeout, etc. Nginx, jamais pu m’y pencher sérieusement mais selon certains pros, il ne convient pas forcément à toutes les utilisations…

      Oui, je pense que c’est la meilleure chose en effet 🙂

      Concernant le serveur en lui-même, vu la différence de prix, autant prendre le plus performant. Le truc c’est qu’il n’y a pas qu’un seul site hébergé dessus mais une dizaine, mais ça vous ne pouviez pas le savoir 😉

      Merci pour le com’ !

  7. Tout d’abord.

    Je ne connais pas réellement les besoins du site, mais je pense que le 16G aurait pu largement suffire. Le problème de lenteur semble plutôt provenir de l’admin qui ne sait pas correctement configurer / optimiser le serveur. L’utilisation de la R2 OVH le prouve indirectement. (caché par l’excuse du manque de temps)

    L’article n’apporte aucune information concernant Apache, son mpm, ses mods (utilisé sur la release OVH), le tunning (mysql?), éventuellement un reverse proxy de cache ?

    Concernant la sécurité, l’utilisation de mod_security est un must have. Et pourquoi pagespeed de google, ça ne peut pas faire de mal.

    Le sujet traité ici est uniquement W3 Total Cache, qui explique (partiellement) les quelques cliques souris à faire sans comprendre grand chose derrière.

    Les chiffres parlent d’eux même :
    http://tools.pingdom.com/fpt/#!/FUby0JQK5/https://www.undernews.fr/
    http://gtmetrix.com/reports/www.undernews.fr/FTSEU8wP
    http://loads.in/
    http://webwait.com/

    ~5 secondes pour charger la page d’accueil avec le cache du navigateur.

    C’est clairement pas “”une solution viable, évolutive et efficace”” à mon sens.

    Bon courage quand même, pour la suite. J’espère que la solution actuelle vous convient, après tout, c’est l’essentiel ! 🙂

    • Salut.

      Concernant le 16G, il n’existait pas en fait en 2010 (il fait parti de l’offre 2011). Donc, il n’y avait que 4 Go de RAM avant et maintenant 16 😉
      Certes, je ne suis pas un pro de la gestion serveur (je suis développeur, pas webmaster). Et non, ce n’est pas une excuse.

      Alors pour les mods : tous ceux par défaut dans Apache 2 avec en plus le mod_evasive.

      Je n’ai jamais testé le mod_security encore, mais ça ne saurait tarder !

      Il est vrai que je ne me suis pas attardé sur le pourquoi du comment : le but ici n’est que de fournir une solution possible et rapide.

      Pour finir, les chiffres sont pas excellents pour cause de la structure du site comme je l’ai expliqué dans l’article (thème lourd, trop de plugins, etc). Cependant, le temps de chargement de la page d’accueil avant optimisation frôlait les 10 secondes :/ Preuve que tout cela améliore considérablement le temps de chargement (et en plus, la charge du serveur est elle aussi très allégée !).

      Voila voila.

Les commentaires sont fermés.