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
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.
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 :
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.