It has never been simpler to implement queues in Pimcore with Symfony Messenger. Are you interested in learning how to speed up response times and assign time-consuming activities to qualified services?
On this page 6 sections
Spend less time waiting and let Symfony Messenger handle the task for your Pimcore application in the background.
Symfony Messenger: What is it?
Applications can better manage queues with the aid of Symfony Messenger, especially when interacting with other systems or assigning tasks to other services. Symfony Messenger is considerably simpler to integrate into your project because Pimcore replaced all previous asynchronous queues with it.
A real-world example in use
Let's imagine your website has a contest entry form, even a very basic one with just three fields:
- firstname
- message
Additionally, it is extremely comparable to the class definition for the objects that will be kept in Pimcore.
The controller processes the contact form, stores the object in the database, and delivers a precise email.
This does indeed function well, but is there a better approach?
What is the issue?
Prior to the introduction of Symfony Messenger, it took roughly 4 seconds to process the contact form, save the object, and send an email.
Why? Communication with the SMTP server in charge of sending emails is the main cause. When skipping this step and simply saving the object, processing time is drastically different. The distinction can influence how consumers perceive the usability and performance of the website.
The magic of queues
This is the reason Pimcore took the place of the old asynchronous queues and Symfony Messenger was developed. There must be two classes:
- CompetitionApplicationMessage, which stores data, is the CompetitionApplication in this case.
- CompetitionApplicationMessageHandler, which in this case is responsible for saving the object and sending the email.
Now, in the controller, call CompetitionApplicationMessage by injecting the MessageBusInterface into the function in charge of receiving requests rather than running the saving object and sending an email. Remind yourself to switch your services. Tell your handler that it is now a message handler using yaml configuration.
It's a lot of fun. The form is still processing after nearly 4 seconds, which is a huge letdown.
The key is asynchronicity.
Symfony Messenger automatically completes tasks. You must write the config/packages/messenger.yaml configuration file with a definition of how the message should be executed and handled in order to make it asynchronous. MESSENGER_TRANSPORT_DSN An environmental variable indicates which transporter will be responsible for queues. It can be Redis, RabbitMQ, or even a database. For queue tasks to execute correctly using cron or supervisord cyclically, the command php bin/console messenger:consume async must be run.
Results
We may observe a substantial improvement in performance by using Symfony Messenger to process our form asynchronously.
Additionally, when using a system to control processes like supervisord, the logic carried out within our task is charged to the service in charge of handling the processes rather than the application, which can result in a huge improvement in perceived performance and stability when there is high traffic and a large number of processes.
Another benefit is that if the SMTP service is down, the task won't be recognized as finished and will instead make three attempts to restart. There would never be a retry if the logic was still in the controller and the email wasn't sent appropriately. The amount of retry attempts and the gaps between them can be controlled using Messenger's setup.
