Jusqu’à l’AFUP Day 2025, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Débrider la capacité des Workers Par ce retour d'expérience, découvrez les principes fondamentaux des workers en PHP et plongez dans les défis complexes qu’ils posent lorsqu’il s'agit de gérer la montée en charge et d'accélérer les traitements. Nous aborderons des problématiques clés telles que les collisions et leurs solutions avec la gestion de la mémoire partagée ou le sharding par exemple. Nous aborderons aussi des stratégies de monitoring et d’observabilité. Vous repartirez avec des patterns d’optimisation efficaces et réplicables, applicables à une grande variété de cas d’usage.

Maurice 16/05/2025 14:45-15:25

Nos workers sont souvent basés sur des librairies existantes (messenger, enqueue, etc…). Avant d’optimiser notre propre code, dirais-tu qu’il faut maîtriser et configurer parfaitement ces librairies ?

Bien sûr, ces librairies offrent déjà de nombreuses fonctionnalités indispensables que l’on ne souhaite pas recoder (optimisation de la mémoire, retry, observabilité, ou encore généricité et intégration avec les autres composants du framework). Elles couvrent la majorité des usages, et ce n’est que lorsque l’on est convaincu d’en avoir atteint les limites que l’on peut envisager d’aller plus loin.

De plus, maîtriser leur paramétrage et leur configuration permet de mieux comprendre leur fonctionnement et les fonctionnalités nécessaires à une utilisation optimale des workers.

Enfin, il ne faut pas oublier que, plus on s’éloigne des standards, plus le coût de maintenance augmente et plus le risque d’accroître la dette technique est élevé.

La principale différence entre un worker et une request est la durée de vie du processus PHP et sa mémoire. Selon toi, est-il préférable de monitorer la vie entière d’un worker ou bien de monitorer uniquement chaque traitement individuellement ?

Les deux approches sont complémentaires. Lorsqu’on parle de monitoring, il faut d’abord identifier les risques, car c’est précisément ce que l’on souhaite être capable de détecter, voire d’anticiper. Sinon, ce ne sont que de jolies courbes colorées destinées à satisfaire la hiérarchie.

Lorsque l’on travaille avec des workers, on devient rapidement aveugle : il n’y a pas d’utilisateur pour signaler une erreur sur la page d’accueil. Le monitoring est donc notre seul moyen de savoir ce qui se passe.

Le monitoring des workers dans leur globalité doit permettre de détecter les fuites mémoire, les workers bloqués, les cadences de traitement… Il s’agit d’un monitoring plus orienté infrastructure, à l’image de celui d’un serveur web, où l’on mesure le nombre de requêtes par minute, le nombre d’erreurs et les temps de réponse.

Le monitoring de chaque traitement, en revanche, relève davantage du monitoring métier, à l’instar du suivi des ajouts au panier dans une boutique en ligne. Cette partie est d’autant plus importante en fonction de la criticité des tâches, de leur variété, du volume ou de la fréquence de traitement, ainsi que de leur complexité.

Hormis la capacité de traitement, quels sont les défis les plus importants que tu as rencontrés en lien avec les workers ?

Le premier défi est probablement d’être _fail-safe_, c’est-à-dire de garantir qu’en cas de défaillance, il soit possible de réparer rapidement et sans impact sur le business, si ce n’est un délai supplémentaire. Cela passe évidemment par l’utilisation d’une file de messages en amont, mais aussi par un design transactionnel des workers. Autrement dit, en cas d’erreur lors du traitement d’une tâche, aucune donnée ne doit être sauvegardée afin de pouvoir retraiter la tâche dans son intégralité et d’éviter un état intermédiaire dont il serait difficile de sortir.

Le second défi concerne sans doute l’ordonnancement et la gestion des collisions. L’une des solutions pour garantir des tâches transactionnelles peut être de les découper en unités plus petites, mais cela crée des dépendances où l’ordre d’exécution devient critique, ce qui complique la gestion lorsqu’on exécute plusieurs workers en parallèle. De même, le risque de collisions est un enjeu important : si deux workers parallèles travaillent sur les mêmes données, l’un peut écraser les modifications enregistrées par l’autre, entraînant des incohérences.

Enfin, il y a forcément l’observabilité, car selon le niveau de détails des informations que l’on souhaite avoir, cela peut avoir un coût sur les performances (traces, logs, alertes).

Une conférence présentée par

Julien MERCIER-ROJAS

Leaddev / Architecte freelance avec 20+ ans d'expérience en PHP et gestion de projet, Julien accompagne les entreprises dans l'industrialisation de leurs projets web: architecture, gestion de la charge, processus qualité, méthodologie.

Autres intervenants