Transition vers une plateforme 2018 En route vers PHP 7+

, par marcimat

Nursit utilise depuis ses débuts (2012) une plateforme de travail (serveurs, système d’exploitation Debian, Apache, PHP, différents scripts maisons, …).
Nous transformons, cette année 2018, notre architecture pour une plateforme 2018 qui intègre différents grands changements internes et des mises à jour logicielles, avec tout particulièrement l’arrivée de PHP 7 (enfin !) et de meilleures performances.

Nous allons passer dans les prochains mois l’ensemble de notre parc serveur (appelé des Clusters chez nous) sur la nouvelle plateforme 2018. Nous avons déjà commencé d’ailleurs, ce qui permet d’affiner notre nouvelle architecture.

Comment se fait la migration ?

Dans le détail, pour chaque serveur en plateforme 2012-2017, nous :

  • louons un nouveau serveur professionnel (souvent donc avec du matériel plus récent), toujours avec un disque SSD pour stocker le système d’exploitation et les sites,
  • migrons les sites sur la nouvelle plateforme ; nous mettons parfois les gros répertoires de données [1] sur un disque HDD sur le serveur,
  • vérifions que tout va bien,
  • arrêtons la location de l’ancien serveur quelque temps plus tard.

Qu’est-ce qui change sur les serveurs ?

Outre le matériel physique, nous utilisions sur la plateforme 2012-2017 ces logiciels :

  • Debian 7 ou 8,
  • Apache 2.2 ou 2.4,
  • Apache prefork + mod_php,
  • PHP 5.4 ou 5.6,
  • Varnish 4 ou 5.

Sur la nouvelle plateforme 2018, nous avons :

  • Debian 9,
  • Apache 2.4,
  • Apache worker + fastcgi + php-fpm + HTTP/2,
  • Varnish 6,
  • PHP 7.1 (par défaut), modulable entre 5.6 et 7.2 pour chaque site.

De plus, la plupart de nos scripts internes a été migrée et réarchitecturée en utilisant Symfony Console. Ce qui facilite beaucoup notre usage.

Une petite partie de nos scripts, ceux génériques pour SPIP, a été déplacée dans l’outil SPIP-Cli.

Qu’est-ce qui change pour nos utilisateurs ?

Essentiellement l’arrivée de PHP 7.1 par défaut sur les sites. Il faut donc vérifier les plugins maison utilisés. Cependant nous pouvons rétrograder un site en version PHP 5.6 s’il y a vraiment besoin.

Également, les personnes utilisant SPIP et des dépôts GIT ou SVN pour gérer leurs squelettes et plugins ont désormais dans leur interface un bouton pour les mettre à jour. Il faut toujours nous demander pour la première récupération de vos sources afin de faire les bons branchements, gérer les clés SSH éventuelles.

Un peu de performance ?

Nous savions que PHP 7 était plus économe, et effectivement, nous avons pu le constater nettement avec la nouvelle plateforme. Mais le passage simplement à la nouvelle plateforme en PHP 5.6 apporte également un grand gain. Voici un résultat pour un gros site en SPIP, sur le même serveur :

Passage de la plateforme 2012-2017 à 2018 en PHP 5.6

  • de ×2.5 à ×3.5 en calcul
  • de ×5 à ×7.5 en hit dans le cache

Passage de PHP 5.6 à PHP 7.1

  • ×2 en moyenne dans toutes les configs

Passage de 2012-2017/PHP 5.6 à 2018/PHP 7.1

  • de ×6 à ×7 en calcul
  • de ×10 à ×15 en hit dans le cache

Mais ce n’est pas tout. L’ajout de HTTP/2 pour les sites HTTPS accélère beaucoup le transfert des données vers les navigateurs sur les connexions ADSL ou mobiles lentes. Ce protocole conserve une connexion HTTPS ouverte pour obtenir d’autres fichiers du serveur, au lieu d’en recréer une pour chaque fichier.

On gagne 1/3 à 2/3 du temps de transfert, en fonction du nombre de fichiers CSS/JS à récupérer. C’est particulièrement visible lorsque le compresseur CSS/JS est désactivé car dans ce cas les fichiers CSS et JS du site ne sont pas fusionnés.

En rodage

On en est à régler quelques détails, à peaufiner tout cela. Nous avons déjà migré 2 clusters, et l’aventure semble se dérouler aux petits oignons. Nous sommes donc contents et confiants :)

Notes

[1Tel que certains répertoires IMG chez SPIP.