PHP Tour Clermont-Ferrand, édition 2016, le retour
Le 23 et 24 mai a eu lieu le PHP Tour 2016. Il s’agit de l’un des deux cycles de conférences qu’organise chaque année l’AFUP (Association Française des Utilisateurs de PHP). Retour sur cette édition placée sous le thème de La performance !
Image à la une : Elephpants by Rob Allen © Creative Commons
Retours d’expériences, nouveautés, discussions autour du langage et de son écosystème, la particularité de cet événement est qu’il est itinérant.
Cette année, il était à Clermont-Ferrand organisé en collaboration avec Clermont’ech (association de développeurs auvergnats).
Je vous propose de revenir sur cette édition 2016 au travers de trois conférences !
Soyez doux avec votre prod
Olivier Dolbeau et Benjamin De Bernardi, BlaBlaCar
Olivier Dolbeau et Benjamin de Bernardi sont venus nous raconter une partie de leurs aventures au sein de BlaBlaCar.
Proud to have 3 speakers from BlaBlaCar at phptour 2016 https://t.co/0ZiFscEd9h Thank you @Genes0r @odolbeau @ninsuo ! #ShareMoreLearnMore
— Nicolas Schwartz (@nicoschwartz) 14 mars 2016
Leur problématique était la suivante : beaucoup de fonctionnalités à tester sur un site à fort trafic dans un environnement de déploiement continu.
Ainsi, les utilisateurs pouvaient se retrouver impactés par un changement de fonctionnalité soudain, ne fonctionnant pas très bien ou pas comme ils l’auraient souhaité.
Et c’est là que lors d’une session de hackathon sont apparues les “features flags” appellées aussi “features toggles”, qu’on pourrait traduire par “interrupteurs de fonctionnalités”.
C’est quoi une feature toggle ?
C’est quand une fonctionnalité peut être activée au besoin pour une application donnée via une interface d’administration.
A quoi ça sert ?
L’utilisation des features toggles est variée. Les voici :
- Permettre aux personnes du métier d’activer ou désactiver une fonctionnalité au besoin
- Faire de l’A/B testing en n’ouvrant la fonctionnalité qu’à certains profils d’utilisateurs
L’A/B testing est une technique utilisée en marketing qui permet de donner des variantes d’un produit à différents utilisateurs afin d’identifier la meilleure d’entre elles.
- Faire du Canary testing
L’idée est de n’ouvrir une fonctionnalité qu’à une partie des utilisateurs pour éviter que d’éventuels bugs n’impactent l’ensemble des personnes utilisant l’application.
L’expression “Canary testing” vient des mineurs qui utilisaient des canaris afin de repérer les gaz toxiques. Quand les canaris arrêtaient de chanter, ça signifiait qu’il fallait fuir.
- Cacher une fonctionnalité qui n’est pas encore prête
Comment ça marche ?
Il faut une interface d’administration pour activer et désactiver la fonctionnalité.
Dans le code, ça va se traduire par vérifier à l’aide d’un “if” si la fonctionnalité est activée. Si elle l’est, on exécute une portion de code.
Il existe des solutions sur le marché pour implémenter les “features flags”.
BlaBlaCar a fait le choix d’une solution qu’ils ont personnalisé notamment au niveau de l’interface d’administration, mais d’autres sociétés développent leur propre produit.
Sur le sujet, BlaBlaCar n’est pas encore industrialisé puisqu’ils ont mis ce processus en place lors d’un hackathon.
Ils espèrent cependant pérenniser cette démarche.
Je ne connaissais pas le concept des “features flags” et cette conférence m’a permis d’en voir rapidement les avantages et la mise en place. Cela semble vraiment permettre d’être “doux avec sa prod” !
La conférence était également l’occasion de percevoir les difficultés d’une telle solution : code en plus à maintenir, penser à supprimer les “if” quand on décide qu’une fonctionnalité est activée à tout jamais, …
C’était une bonne première entrée dans le sujet.
Retour d’expérience : réaliser des Workers en PHP
Fabien de Saint Pern est venu nous parler de workers.
Le problème dans une application est souvent le suivant. On commence par demander une fonctionnalité assez basique. Au premier développement, les temps de réponse sont assez bons.
Mais finalement le métier demande d’ajouter des exports, des envois d’emails, …
La fonctionnalité ne parvient alors plus à être performante et il s’agit de nouveaux développements ne nécessitant pas d’être faits en synchrone.
Il y a plusieurs manières d’y répondre.
Comme l’explique Fabien de Saint Pern, on peut par exemple ajouter du cache, dénormaliser en passant à un système NoSQL. Puis, on peut utiliser des workers et tirer ainsi partie du fait qu’il n’est pas nécessaire d’effectuer les traitements de manière synchrone.
C’est quoi un worker ?
Un worker, c’est un processus qui s’exécute en arrière plan. Il s’agit d’une boucle infinie qui va exécuter un certain code s’il y a un message à traiter.
Pour réaliser cela, on peut utiliser des “brokers de messages” qui servent à implémenter ces workers.
La solution la plus connue en terme de “broker de messages” qui est actuellement utilisée par M6Web est RabbitMQ. Cependant, il en existe d’autres comme Kafka, qui offre de meilleures performances.
Un “producer” publie un message qui est mis en attente dans un “exchange”. Il est ensuite routé vers une ou plusieurs “queues” selon sa configuration.
Puis il est consommé de manière asynchrone par un “consumer”.
Les pièges
Le conférencier met en garde contre les memory leaks et les crashs. Il explique aussi que parfois un simple cron est plus efficace que de passer par un worker, qui rajoute de la complexité.
Les bundles d’M6Web
Afin de mettre en place un système de workers, M6Web a développé des bundles open source comme le DaemonBundle pour créer des démons ou comme AMQPBundle qui permet de gérer les messages en utilisant l’extension AMQP (Advanced Message Queue Protocol) de PHP.
Dans les salons, on entend souvent parler de workers, RabbitMQ, … Nous avions là une conférence qui nous présentait un retour d’expérience sur le vif du sujet.
J’ai particulièrement apprécié que Fabien de Saint Pern présente les bundles qu’M6Web a développé et fasse mention de Kafka, un autre “broker de messages” moins connu, mais plus performant.
J’ai un peu travaillé avec RabbitMQ, ce qui m’a fait découvrir le monde des workers, mais j’aimerais beaucoup tester Kafka qui a l’air prometteur.
En route vers le multi-tâche
Le constat est qu’en PHP, on ne peut pas faire du multi-tâche ou du moins pas nativement ou pas sans mettre en place une certaine infrastructure.
Il existe bien des solutions comme les workers, les sous-processus ou encore des extensions.
Et puis sont arrivés les générateurs.
Les générateurs, selon la définition officielle sont “une façon simple de mettre en place des itérateurs sans le coût ni la complexité du développement d’une classe qui implémente l’interface Iterator”.
Julien Bianchi explique que pour lui c’est assez triste de résumer ainsi les générateurs parce qu’ils apportent le mot-clef “yield” qui “ressemble à une fonction return […] fournit une valeur de code et […] met en pause l’exécution de la fonction générateur”.
Chaque “yield” est donc une occasion pour changer de tâche.
C’est de là qu’est parti Julien Bianchi pour créer la librairie async-generator qui permet de faire des traitements en parallèle.
Les inconvénients sont qu’elle ne sert qu’à manipuler des flux et qu’il faut avoir PHP7 au moins pour s’en servir. Elle présente cependant l’avantage de faire du multi-tâches avec du code natif sans avoir besoin d’ajouter d’extension ni de mettre en place une certaine infrastructure.
A l’heure où le monde du web se tourne vers l’asynchrone (notamment avec Node.js) et poursuit dans sa recherche de gagner de plus en plus en performance, l’arrivée de librairies qui permettent de faire des traitements parallélisés avec du code natif en PHP me semble la bienvenue.
Ce fut très agréable de participer à cette édition avec ses conférences variées, son apéro habituel du 1er soir. De plus, en tant que conférencière, cela permet d’avoir une vision du salon différente et de pouvoir échanger davantage avec l’ensemble des speakers.
