Comment maîtriser le backlog d’une file d’attente PHP sans aggraver le problème

Une file de travaux permet d’exécuter des tâches en dehors du chemin immédiat d’une requête : envoyer des notifications, traiter des fichiers ou synchroniser des données. Mais lorsque davantage de travaux arrivent que les consommateurs ne peuvent en terminer, un backlog se forme. Le retard peut se manifester par une confirmation tardive, des données obsolètes ou des tâches qui ne se terminent jamais, avec des conséquences pour les utilisateurs comme pour les équipes qui exploitent l’application.

Pour décider de la marche à suivre, il ne suffit pas de regarder le nombre de messages en attente. Leur ancienneté, leur rythme d’arrivée et d’achèvement, le type de travail et l’état des dépendances comptent également. Ajouter des consommateurs peut aider si la capacité manque, mais aussi multiplier les requêtes vers une base de données déjà saturée. Une réponse sûre commence par mesurer et reconnaître le schéma observé.

Ce que révèle le backlog et les métriques manquantes

Le nombre de travaux en attente est un instantané, pas une explication. Il peut augmenter pendant un pic puis diminuer sans intervention, ou rester stable tandis que le travail le plus ancien prend de l’âge. Par conséquent, pour évaluer comment maîtriser le backlog d’une file d’attente PHP, il est utile d’observer conjointement :

• Taux d’entrée : travaux acceptés par unité de temps.
• Taux de sortie : travaux terminés par unité de temps, en distinguant les travaux achevés des tentatives ayant échoué.
• Ancienneté : durée d’attente du travail le plus ancien, ainsi que les percentiles d’attente s’ils sont disponibles.
• Durée de traitement : temps nécessaire au traitement de chaque type de travail et évolution de cette durée.
• Erreurs et nouvelles tentatives : proportion d’échecs, nombre de tentatives et présence de travaux envoyés dans une file d’erreurs ou de quarantaine.
• État des consommateurs et des dépendances : processus actifs, redémarrages, utilisation du processeur et de la mémoire, connexions à la base de données et latence des services externes.

Le taux de sortie doit représenter le travail utile achevé : compter chaque tentative comme une tâche évacuée peut masquer un cycle d’échecs et de nouvelles tentatives. Il est également important de segmenter les données par file ou classe de tâche. Une moyenne globale peut dissimuler le fait qu’un type de travail bloque les autres.

Diagnostiquez le schéma avant de modifier la capacité

Comparez les métriques sur une période adaptée à l’exploitation et au comportement habituel du système. Les schémas orientent l’enquête, mais ne prouvent pas à eux seuls la cause.

• Entrée durablement supérieure à la sortie : la capacité peut être insuffisante, le volume peut avoir augmenté ou la durée des travaux peut s’être allongée. Examinez les changements récents, la composition du trafic et les temps de traitement par type de tâche.
• Consommateurs actifs, mais sortie presque nulle : recherchez les processus bloqués, les attentes sans fin, les deadlocks, l’épuisement du pool de connexions ou les appels externes sans limite de temps. Examinez les logs et les traces corrélés par identifiant de travail.
• Durée des travaux et latence des dépendances en hausse : les consommateurs peuvent attendre la base de données, une API ou le stockage. Davantage de processus peuvent accroître la contention et dégrader la latence.
• Échecs répétés pour les mêmes travaux : il peut s’agir de données invalides, d’une condition irrécupérable ou d’un défaut. Vérifiez la politique de nouvelles tentatives : réessayer trop rapidement peut provoquer une tempête de charge.
• Une file augmente tandis que les autres avancent : vérifiez les priorités, la répartition des consommateurs et le risque qu’une classe de travail monopolise les ressources.

Recherchez également les changements de configuration et les déploiements récents. Vérifiez que la télémétrie distingue un consommateur occupé d’un processus actif qui ne progresse pas ; constater qu’un processus est actif ne garantit pas que des travaux soient achevés.

Estimez la capacité d’évacuation à partir des données observées

Si le taux de sortie soutenu dépasse le taux d’entrée, la file peut diminuer tant que cet écart se maintient. À titre d’approximation opérationnelle, le temps nécessaire au traitement du backlog dépend du nombre de travaux en attente divisé par la capacité nette d’évacuation : la capacité de sortie moins l’entrée sur la même période. Si cet écart est nul ou négatif, prolonger le délai d’attente ne résoudra pas l’accumulation.

Cette estimation est indicative, et ne garantit pas une heure de rétablissement. Elle suppose que le rythme reste stable et que les travaux présentent une composition et un coût similaires. Quelques travaux longs, les nouvelles tentatives ou les limites imposées par une dépendance peuvent modifier le résultat. Utilisez des taux observés sous une charge réelle et réestimez après chaque intervention. Pour des tâches de coûts différents, effectuez le calcul par classe de travail ou mesurez le temps de service, et pas seulement le nombre de messages.

Intervenez dans l’ordre et en fixant des limites

Privilégiez des mesures réversibles et bien délimitées. Avant de modifier le nombre de consommateurs, convenez de l’impact que chaque dépendance peut tolérer et de la manière d’annuler le changement.

1. Limitez les nouvelles entrées si possible : mettez en pause les producteurs non essentiels, appliquez des limites ou reportez les tâches peu prioritaires. Évitez de supprimer des travaux sans règle métier, journalisation et mécanisme de récupération.
2. Isolez les travaux problématiques : limitez le nombre de tentatives, appliquez un délai croissant lorsque cela convient et redirigez les échecs persistants vers une file d’erreurs pouvant être examinée. Ne les ignorez pas : ces travaux peuvent nécessiter une correction et un retraitement.
3. Protégez les priorités : séparez les tâches urgentes des tâches de maintenance ou de traitement en masse, et vérifiez que les priorités ne condamnent pas les files moins urgentes à attendre indéfiniment.
4. Ajustez progressivement la concurrence : modifiez le nombre de consommateurs par petits paliers et observez le débit et la saturation. Respectez des limites cohérentes avec les connexions disponibles, le processeur, la mémoire et les quotas des services externes.
5. Corrigez la cause : en présence de requêtes lentes, de blocages ou d’appels sans timeout, résolvez ce goulot d’étranglement avant de maintenir davantage de processus en parallèle.

L’idempotence est particulièrement importante lorsqu’un travail peut être exécuté plusieurs fois. Concevez les effets externes et les écritures de manière à tolérer les nouvelles tentatives, ou mettez en place des mécanismes de déduplication adaptés. Vérifiez également ce qui se passe si le consommateur s’arrête après avoir produit l’effet, mais avant d’accuser réception du message.

Définissez des seuils et une procédure de rétablissement

Établissez des seuils à partir des exigences de service, et non d’une valeur universelle. Une alerte peut combiner l’ancienneté maximale ou le percentile d’attente, la tendance du backlog, l’écart entre l’entrée et la sortie et le taux d’erreurs. L’ancienneté est souvent plus directement liée à l’impact pour l’utilisateur qu’un décompte isolé ; le volume aide à évaluer l’ampleur du problème.

Documentez qui intervient, quelles files cette personne peut mettre en pause, quelles dépendances elle doit consulter et quels changements nécessitent une approbation. Pendant l’incident, consignez l’heure, l’hypothèse, l’action et l’effet observé. Après chaque ajustement, vérifiez que le taux de sortie augmente sans hausse inacceptable de la latence de la base de données, des erreurs externes, de l’utilisation des ressources ou des défaillances de l’application.

Considérez le rétablissement comme confirmé lorsque l’ancienneté et le volume diminuent durablement, que les travaux s’achèvent correctement et que les dépendances retrouvent un niveau stable. Ne déclarez pas le problème résolu simplement parce que le compteur baisse : des messages peuvent avoir été supprimés ou accumulés dans une autre file.

Liste de contrôle pour prévenir une nouvelle accumulation

• Mesurez-vous l’entrée, la sortie utile, l’ancienneté, la durée et les nouvelles tentatives pour chaque file ?
• Les travaux ont-ils des limites de temps et une politique de nouvelles tentatives finie et adaptée ?
• Des alertes signalent-elles l’absence de progression, et pas seulement le volume ?
• La concurrence maximale respecte-t-elle les limites des dépendances partagées ?
• Est-il possible d’isoler une classe problématique sans arrêter tout le traitement ?
• Existe-t-il une procédure documentée pour mettre en pause, reprendre et retraiter les travaux en toute sécurité ?
• Les métriques et les effets secondaires sont-ils vérifiés après des changements de code, de charge ou de configuration ?

Une file saine n’est pas nécessairement vide : des variations normales peuvent survenir. Le critère pratique est que les travaux s’achèvent dans les limites du niveau de service prévu, que les échecs soient visibles et que le système conserve une marge pour absorber les pics. Mesurer ce comportement permet d’agir avant qu’une accumulation ne se transforme en interruption de service pour les utilisateurs.