Exécuter PHP à une vitesse fulgurante à l’edge avec WASM

• PHP représente actuellement environ 75 % des sites web sur Internet
• PHP n’est peut-être pas le langage de programmation le plus « sexy », mais il joue un rôle important depuis la naissance d’Internet
• Il est désormais possible d’exécuter PHP entièrement avec Wasmer et Wasmer Edge (bêta ouverte)

Pourquoi l’exécution de PHP sur WebAssembly est importante

• Les propriétés de WebAssembly permettent de limiter en toute sécurité les ressources auxquelles un programme peut accéder
• PHP peut être exécuté de manière sécurisée sans le surcoût de la virtualisation de l’OS ou du matériel
• L’équipe Wasmer a investi énormément de temps pour que PHP fonctionne parfaitement et le plus rapidement possible sur WebAssembly
• L’activation du cache d’opcodes dans WebAssembly a permis d’obtenir jusqu’à 3 fois plus de vitesse

Offrir une scalabilité de type serverless aux apps PHP

• Fournir une scalabilité de type serverless à toutes les apps PHP peut débloquer une valeur énorme
• Il est possible d’exécuter des apps PHP à l’edge en ne payant qu’une fraction du prix facturé par les fournisseurs cloud
• Toutes les applications PHP peuvent être exécutées avec Wasmer, sans avoir à craindre qu’une app brise son sandbox et fasse des choses nuisibles qu’elle ne devrait pas faire

Les frameworks PHP les plus populaires peuvent tourner sur Wasmer et Wasmer Edge

• WordPress
• Symfony
• Laravel
• Tous les templates PHP : https://wasmer.io/templates?language=php
• Remarque : la prise en charge par Wasmer Edge des volumes de système de fichiers personnalisés est en cours. Les apps déployées qui utilisent SQLite (comme WordPress ou Symfony) ne conservent actuellement les modifications de base de données qu’en mémoire, et pas encore de façon persistante

Tirer le meilleur parti de WebAssembly et de PHP

• En activant le cache d’opcodes, WordPress peut tourner 3 fois plus vite sans aucune modification, en passant de 600 ms à 200 ms

Essayer par vous-même

• Si vous lancez habituellement php -S localhost:8000 ., vous pouvez désormais l’exécuter entièrement en sandbox via Wasmer :

  wasmer run php/php --mapdir:/app:. -- /app -S localhost:8000  
  

• WordPress peut aussi être exécuté facilement en local. Après avoir cloné le dépôt WordPress, lancez wasmer run . --net à la racine (Wasmer 4.3.1 requis)
• Un PHP CLI pleinement fonctionnel est fourni, s’exécutant sur le serveur dans un environnement entièrement sandboxé
• Plus besoin de vous inquiéter qu’une app accède à des éléments comme /etc/passwd

Une prouesse technique

• Faire fonctionner PHP parfaitement sur WebAssembly avec Wasmer n’a pas été simple
• En suivant le processus, de nombreux problèmes ont été résolus :
  • Découverte d’un bug obscur dans l’implémentation de longjmp/setjmp nécessaire à l’utilisation des blocs try/catch dans PHP, où la stack était écrasée et n’était pas correctement restaurée
  • Découverte et correction d’un bug qui rendait les appels HTTP sortants 10 fois plus lents
  • Activation par défaut de PHP opcache pour obtenir jusqu’à 3 fois plus de performance
  • Nombreuses petites corrections dans la couche de virtualisation du système de fichiers et le réseau (IPv6)
• Si vous aviez suivi un précédent billet de blog expliquant comment exécuter WordPress avec Wasmer, vous savez qu’il fallait effectuer de nombreuses modifications de code (autrement dit des hacks) pour changer le comportement de WordPress et éviter de déclencher des cas limites bloquants
• Dans la dernière version de Wasmer, WordPress, Laravel et Symfony fonctionnent sur Wasmer sans aucune modification de code

Vitesse

• Exécuter PHP à sa vitesse de base ne suffisait pas, l’objectif était de le faire tourner aussi vite que possible sur WebAssembly
• PHP dispose du module Zend Opcache, qui accélère fortement l’exécution
• Le module de cache d’opcodes optimise et met en cache le bytecode dans lequel le code source PHP est transformé, ce qui évite de perdre du temps à analyser l’AST des fichiers déjà traités
• Comme le cache d’opcodes peut multiplier par 3 le nombre de requêtes qu’une app peut traiter, il semblait évident de l’activer sur WebAssembly
• Mais le cache d’opcodes (et le chargement des modules Zend) était désactivé par défaut, car il nécessitait dlopen, dlsym, etc., indisponibles dans Wasm
• Une quête singulière a donc commencé : activer le cache d’opcodes dans PHP
  • Après des recherches, une nouvelle méthode de liaison statique a été trouvée ; de nombreux éléments ont dû être corrigés au passage, mais cela a finalement fonctionné
• Temps WordPress sur Wasm sans Opcache : ~620 ms
• Temps WordPress sur Wasm avec Opcache activé : ~205 ms
• Le simple fait d’activer Opcache apporte déjà un gain de vitesse de 3x !
• Il a été constaté qu’il restait encore de nombreuses améliorations possibles pour rapprocher PHP des performances natives (à suivre !)

Davantage d’opportunités s’ouvrent

• Cela ouvre davantage de possibilités pour des projets comme WordPress Playground, qui dépendent aujourd’hui d’Emscripten pour exécuter PHP dans le navigateur
  • Ces projets pourraient être transformés en packages capables de tourner à la fois dans le navigateur et à l’edge
• Une approche totalement révolutionnaire du cold-start est en préparation (Cloudflare & Fly.io, on vous a à l’œil !)
• Une période passionnante s’annonce pour le marché de l’edge

[tsboard]

Personnellement, je trouve assez impressionnant et étonnant que PHP soit encore utilisé de manière aussi active. Haha. On dit qu’après son époque de mauvaise réputation, le langage a beaucoup changé, et ça me donne presque envie de réessayer PHP.

[xguru]

Sur Hacker News comme sur GeekNews, beaucoup de gens n’aiment pas PHP, haha.
Mais tant que la technologie du web ne sera pas complètement remplacée par autre chose, j’ai l’impression qu’il continuera à être utilisé.
Je pense qu’il ne faut pas se focaliser sur la « langue », mais plutôt le voir comme l’une des technologies adaptées au « web ».