Qu’est-ce que Symfony Messenger ?
Symfony Messenger est un composant qui aide les applications à gérer les files d’attente, en particulier lors de la communication avec d’autres systèmes ou de la délégation de travail à différents services. Depuis que Pimcore a remplacé toutes les files d’attente asynchrones existantes par Symfony Messenger, il est encore plus facile de l’implémenter dans votre projet.
Cas d’utilisation dans la vraie vie
Disons qu’il y a un formulaire de concours sur votre site, même très simple avec trois champs :
Et c’est très similaire à la définition de classe quels objets seront stockés dans Pimcore.
Le responsable du traitement gère le formulaire de contact, enregistre l’objet dans la base de données et envoie un e-mail avec des données exactes.
<iframe frameborder="0" height="350" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
Eh bien, cela fonctionne déjà bien, mais y a-t-il un moyen encore meilleur ?
Où est le problème?
Avant l’implémentation de Symfony Messenger, le traitement du formulaire de contact, la sauvegarde de l’objet et l’envoi d’un e-mail prenaient environ 4 secondes.
Pourquoi? La raison principale est la communication avec le serveur SMTP responsable de l’envoi des e-mails. Il y a une énorme différence dans le temps de traitement lorsque l’on ignore cette partie et que l’on enregistre simplement l’objet. La différence est perceptible et peut affecter la façon dont les utilisateurs perçoivent les performances et la convivialité du site Web.
Magie des files d’attente
C’est précisément pourquoi Symfony Messenger a été créé, et Pimcore a remplacé ses files d’attente asynchrones existantes. Deux classes doivent être créées :
- ConcurrenceApplicationMessagequi stocke les données, ConcoursApplication dans ce cas
- CompetitionApplicationMessageHandlerCompetitionApplicationMessageHandlerqui dans ce cas est responsable de la sauvegarde de l’objet et de l’envoi de l’e-mail.
<iframe frameborder="0" height="350" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
<iframe frameborder="0" height="350" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
Maintenant, dans le contrôleur, au lieu d’exécuter l’objet de sauvegarde et d’envoyer un e-mail, appelez ConcurrenceApplicationMessage en injectant le MessageBusInterfaceMessageBusInterfaceMessageBusInterfaceMessageBusInterface dans la méthode responsable du traitement des demandes. Encore une fois, n’oubliez pas de changer votre services.yaml configuration et dites à votre gestionnaire qu’il s’agit maintenant d’un gestionnaire de messages.
<iframe frameborder="0" height="350" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
<iframe frameborder="0" height="160" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
C’est très excitant. Mais il y a une grosse déception car le formulaire est encore en traitement pendant environ 4 secondes.
L’asynchronicité est la clé
Par défaut, Symfony Messenger exécute les tâches immédiatement. Pour le rendre asynchrone, vous devez créer config/packages/messenger.yaml fichier de configuration avec une définition de la manière dont le message doit être exécuté et géré. MESSENGER_TRANSPORT_DSN la variable environnementale indique quel transporteur sera responsable des files d’attente. Il peut s’agir de redis, de RabbitMQ ou même d’une base de données. Pour que les tâches de la file d’attente s’exécutent correctement à l’aide de cron ou de superviseur de manière cyclique, la commande php bin/console messenger : consommer asynchrone doit être exécuté.
<iframe frameborder="0" height="200" src="https://pimcore.com/en/resources/blog/data:text/html;charset=utf-8,
Résultats
En traitant notre formulaire de manière asynchrone avec Symfony Messenger, nous pouvons constater une augmentation significative des performances.
De plus, en utilisant un système pour contrôler les processus tels que superviseurd, la logique exécutée dans notre tâche est imputée au service responsable de la gestion des processus, plutôt qu’à l’application, qui, avec un trafic élevé et un grand nombre de processus, peut donner une augmentation gigantesque de performances et stabilité perçues.
Un autre avantage est que dans une situation où le service SMTP n’est pas disponible, la tâche ne sera pas marquée comme terminée et il y aura trois tentatives pour la redémarrer. Si la logique restait dans le contrôleur et que l’e-mail n’était pas envoyé correctement, il n’y aurait jamais de nouvelle tentative. Selon la configuration de Messenger, le nombre de nouvelles tentatives et les intervalles entre elles peuvent être gérés.
