PHP 7 vient de sortir en décembre dernier et promet des gains importants de performance. La tentation étant trop forte, j’ai upgradé mon serveur durant le week-end. Et effectivement, sur WordPress, pas besoin de tests pour sentir la différence.
Ce post va donc expliquer comment migrer de manière assez « safe » son serveur Debian vers cette nouvelle version de PHP en s’appuyant sur les packages mis à disposition par Dotdeb. Lire la suite
Opcache-status et Opcache-gui sont deux interfaces très pratiques pour superviser l’état de Zend Opcache. Elles permettent de mieux comprendre son fonctionnement et d’en améliorer le paramétrage. Elles sont toutes les deux assez similaires, à ceci près qu’Opcache-gui est un peu plus détaillée et permet de vider le cache, ce qui s’avère utile lors de tests.
Bien évidemment, il est nécessaire d’avoir avant installé et activé Zend Opcache !
Lire la suite
Zend Opcache (ex Zend Optimizer+) est un accélérateur PHP et il fonctionne plutôt bien. Comment ? Il faut savoir que les scripts PHP doivent être compilés en PHP bytecode à chaque exécution, et on constate pour cette raison des temps de réponse de l’ordre de 500ms sur un back-end PHP faisant tourner un WordPress. Zend Opcache stocke et optimise ce code compilé pour une ré-utilisation ultérieure. Et il est plutôt performant.
Zend Opcache est compatible avec PHP depuis la version 5.2 et y est même intégré depuis la 5.5. Malheureusement il n’est pas disponible sur Debian (Wheezy en 7.5) à l’heure actuelle. Alors comment faire ?
Lire la suite
Suite à l’article précédent, on dispose maintenant, grâce aux mécanismes de cache de W3 Total Cache (W3TC), d’un site WordPress relativement bien optimisé et résistant aux pannes PHP/MySQL. Il ne reste plus maintenant qu’à précharger ce cache afin qu’une version de chaque page y soit déjà présente à chaque nouvelle visite. Ce point est particulièrement important avec les paramètres « Inline CSS minification » et « Inline JS minification » qui assomment le CPU avec, sur ce blog, 6 à 8s pour générer la page d’accueil.
Lire la suite
Ce post continue le précédent sur l’optimisation de WordPress avec Nginx et W3 Total Cache (W3TC). Après avoir passé une configuration standard et vérifié le bon paramétrage de la compression Gzip, il est temps de passer à la configuration de W3TC. Est-il besoin de rappeler que c’est le bon moment pour réaliser un back-up de la de données? A priori les opérations suivantes sont sans danger, mais on ne sait jamais.
Lire la suite
WordPress est un outil de blog très populaire, mais il faut le reconnaître tel quel, il est très consommateur de ressource. L’affichage des pages est abominablement lent même sur un site à faible trafic sur un serveur robuste. Ce post va donc présenter des optimisations très efficaces qui permettront à la fois de descendre à un affichage de pages sous la demi-seconde et de permettre à votre serveur d’encaisser un trafic plus important. Je me sers ici de W3 Total Cache (W3TC) qui est assez bon, on peut lui préférer WP Super Cache, pourquoi pas, mais la configuration de Nginx sera différente.
OS : Debian 7.5 stable (Wheezy) (64bits)
Nginx : nginx/1.6.0
PHP : 5.5.12-1 avec Zend Engine v2.4.0 et Zend OPcache v7.0.4
W3 Total Cache : Version 0.9.4 avec les paramètres suivants
J’ai donc passé une mise à jour du package php5-fpm tout à l’heure. Généralement, c’est relativement sans risque. Sauf que mes sites web affichaient ensuite une erreur 502 !
Un tour rapide sur les logs d’erreurs de nginx donne:
1 | 2014/05/10 17:45:19 [crit] 17131#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: xx.xxx.xxx.xx, server: phil.writesthisblog.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "phil.writesthisblog.com" |
Je vais donc consulter le site qui gère les repositories et effectivement :
Please note that if you’re using an Unix socket to make PHP-FPM talk to your web server, you’ll have to set the listen.owner and listen.group directive to the right user/group (usually www-data), for each of your pool. Don’t change the permissions on the socket from 0660 to 0666 (too permissive), it would avoid the CVE-2014-0185 fix.
La solution consiste donc à dé-commenter les lignes listen dans /etc/php5/fpm/pool.d/www.conf:
1 2 3 4 5 6 7 8 9 | root@server:~# cat /etc/php5/fpm/pool.d/www.conf | grep -A 7 for\ unix\ socket ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0660 listen.owner = www-data listen.group = www-data listen.mode = 0660 |
Il ne reste plus qu’à recharger php5-fpm avec un service php5-fpm restart.
Bilan, 20 min d’interruption du site (et encore), ce n’est pas un drame. Mais il faut toujours se méfier des mises à jour automatiques. Mieux vaut les limiter au strict minimum (sécurité) et passer régulièrement sur son serveur appliquer les autres à la main. En cas de crash, on peut intervenir rapidement et on a une idée de l’origine du problème. Idéalement, on dispose d’un serveur de maquette sur lequel on test chaque manipulation, mais il s’agit de moyens plus généralement mis en œuvre sur des infrastructures professionnelles. Sur un serveur personnel, c’est moins évident…
Nginx est un serveur web concurrent d’Apache très populaire, mais il est bien plus encore. Il peut aussi être utilisé comme reverse-proxy, load-balancer, terminaison ssl etc. Personnellement, je le trouve bien plus simple et cohérent à configurer qu’Apache. Ce post va proposer et expliquer une configuration basique pour faire tourner nginx avec du php sous Debian.
Concernant les configurations que l’on peut trouver dans les tutos sur internet, j’appellerai à la plus grande méfiance (à commencer par le mien) ! Pour vous en convaincre, je vous conseille de faire un tour sur la page des pièges de config du wiki nginx. La erreurs référencées se retrouvent fréquemment dans la plupart des tutos quand ces derniers n’utilisent pas des éléments de config obsolètes. Bien évidemment, je m’inspire des docs officielles (ici et là) pour mes propres configurations.
Lire la suite