Mise en place technique de ce blog

Commençons par le sujet technique qui m’a occupé ces derniers temps: la mise en œuvre de ce blog!

Installer un blog, même auto-hébergé, n’est pas compliqué.

Oui, sauf que je me pose quelques contraintes (machines peu puissantes, passage par un reverse-proxy), et que ça entraîne pas mal de complications…

Sommaire

240px-WordPress_logo.svg

Configuration de WordPress à travers un reverse-proxy

Dans mon installation, il y a 2 serveurs : un Apache frontal (serveur1) qui s’occupe entre autres du cryptage SSL (pour la partie administration), et qui est configuré en reverse-proxy pour un second serveur Apache/PHP (serveur2) où est installé le blog (WordPress 3.9.1)

D’abord, je suis tombé sur un premier os: j’avais eu la mauvaise idée de ne pas utiliser le même préfixe d’URL sur les 2 serveurs : http://serveur1/wordpress et http://serveur2/wordpress_mossroy

Ca pose des problèmes, ne serait-ce que pour les cookies, qui sont affectés à un Path donné : quand ils sont générés par serveur2, ils le sont pour le Path qu’il connait, c’est-à-dire /wordpress_mossroy. Mais, côté navigateur, il ne les envoie pas puisqu’on est sur /wordpress. Il y a une parade : utiliser la directive ProxyPassReverseCookiePath d’Apache : https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreversecookiepath

Et ça fonctionne … sauf que, après essais, ça n’empêche pas certains plugins WordPress de s’appuyer quand même sur ce Path.

Au final, j’ai trouvé une solution plus simple : utiliser le même Path sur les 2 serveurs (j’ai finalement mis / tout court). Un NameVirtualHost côté serveur2 me permet de l’installer physiquement où je veux, pas forcément dans /var/www

Workaround quand l’URL déclarée dans WordPress ne correspond pas à celle sur laquelle il est accessible

Oui, ça m’est arrivé plusieurs fois pendant mes tests : WordPress demande à ce qu’on lui dise quelle est son URL publique. Et il l’utilise pour construire certains liens. Mais quand cette URL publique ne fonctionne pas, cela arrive à tout bloquer… y compris la page d’admin où on voudrait corriger ça ;-)

Voilà la commande qui m’a sauvée plusieurs fois (requête SQL à lancer sur la base MySQL de WordPress) :

update wp_options set option_value="http://la_bonne_url_publique" where option_name="siteurl";

Configurer l’administration en HTTPS

D’abord, pour que WordPress veuille bien fonctionner en HTTPS depuis un reverse-proxy, il faut rajouter dans le wp-config.php :

define('FORCE_SSL_ADMIN', true);
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';

Source : http://codex.wordpress.org/Administration_Over_SSL

Ca modifie bien les liens qui pointent vers les pages d’admin vers leur version https.

Mais il reste un hic, causé à nouveau par l’utilisation du reverse-proxy : si je pointe vers http://serveur1/wp-admin , il me renvoie vers https://serveur2/wp-admin au lieu de https://serveur1/wp-admin

La solution est de rajouter en plus de la réécriture d’URL côté Apache (c’est décrit dans le même lien ci-dessus) :

# Redirection vers la version HTTPS pour l'administration
RewriteEngine on
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://serveur1%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

Mise en place d’un cache pour accélérer l’affichage des pages

Le blog tourne actuellement sur un serveur ARM à 1GHz (dual-core). Ce n’est pas très puissant, et les pages mettent quelques secondes à s’afficher, même sans montée en charge.

Un appel unitaire vers une page du site met environ 2.5 secondes à répondre. C’est beaucoup trop long.

Temps de réponse sans cache

Mettre en place un cache a du sens dans ce contexte : le contenu ne change pas très souvent : lors de l’ajout/modification d’un article (mais aussi lors de l’ajout d’un commentaire).

Après quelques recherches, j’ai choisi d’utiliser un plugin WordPress adapté à cela : WP Super Cache.

Une fois activé, l’affichage de la même page passe à 200ms environ :

Temps de réponse avec cache

Pour le paramétrage du plugin,  j’ai fait un rapide test de montée en charge avec l’outil Gatling (en suivant http://javamind-fr.blogspot.fr/2013/10/premier-scenario-de-tests-avec-gatling.html)

Avec 10 utilisateurs simultanés :

Paramétrage Temps de réponse moyen d’une page en cache (ms)
mode réécriture + fichiers compressés 480
mode réécriture + fichiers non compressés 602
mode PHP + fichiers compressés 544
mode PHP + fichiers non compressés 623
mode Legacy + fichiers compressés 550
mode Legacy + fichiers non compressés 590

Les préconisations de l’auteur du plugin sont donc justes : j’ai activé le mode réécriture, et la compression des fichiers de cache.

Par ailleurs, je suis à nouveau tombé sur un problème lié à l’utilisation d’un reverse-proxy, et ai dû le contourner avec un lien symbolique dans le répertoire du cache : http://wordpress.org/support/topic/plugin-wp-super-cache-cache-not-refreshed-behind-a-reverse-proxy-workaround.

Et j’ai encore un petit souci de préchargement du cache à cause du fait que ma partie administration est en HTTPS : https://wordpress.org/support/topic/how-to-preload-cache-in-http-version-when-admin-is-in-https.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *