SymfonyCloud: Better support for Symfony Messenger
Symfony Messenger allows to easily and quickly move the processing of heavy tasks to the background.
It also very popular to send tasks in the background like sending emails. It can do so without even changing your code.
So, it's no surprises that it has already been downloaded more than 4.5M times even if it is only available since Symfony 4.1.
To celebrate its popularity, SymfonyCloud has improved its support when using workers, the feature allowing running Symfony Messenger consumers.
Simpler workers commands
SymfonyCloud comes with some helpers that determines the best way, and the best moment to do some tasks on SymfonyCloud such as building Symfony's cache, running migration, restarting PHP-FPM, etc.
Until recently, for faster worker boot time, it was recommended to prefix your
1 2 3 4 5 6 7 8 9
# .symfony.cloud.yaml workers: mails: commands: start: | set -x -e (>&2 symfony-deploy) symfony console messenger:consume --time-limit=3600 --memory-limit=64M
This is not necessary anymore as SymfonyCloud will automatically determine if
it is running a worker container and will then automatically run the new
symfony-start helper, allowing for a simple configuration:
1 2 3 4 5
# .symfony.cloud.yaml workers: mails: commands: start: symfony console messenger:consume --time-limit=3600 --memory-limit=64M
Integration to project:init
SymfonyCloud provides a command to generate the initial configuration for
your project with some good sensible defaults:
When this command detects that your project has
it will now add a default worker with an optimized configuration.
If you already have a configuration generated, you can run
::init --dump to discover what it would generate for you today. Don't
hesitate to run it, you might discover a few nice tweaks!
New "XS" container size
Let's finish with the most exciting addition: the new
XS container size.
At Symfony SAS, we've been huge users of background workers for years. We know that when using highly optimized frameworks such as Symfony, these workers tend not to consume much memory. In addition, when your workers spend most of their time waiting for database queries, API calls or emails to be sent, they do not consume much CPU either. This is why allocating a big chunk of resources for a single process can be quite frustrating!
This is over: today we are officially unveiling the new
XS container size. It
allows allocating only half the CPU share that is normally be granted to an
container and comes with new extended configuration settings
to tweak how the amount of memory to allocate is computed; allowing you to
fine-tune and optimize the use of you plan's resources.
This container size is a perfect match with Symfony Messenger consumers that only process small tasks such as sending emails:
1 2 3 4 5 6 7 8 9
# .symfony.cloud.yaml workers: mails: size: XS resources: base_memory: 64 # Keep in sync with the `memory-limit` flag value memory_ratio: 128 commands: start: symfony console messenger:consume --time-limit=3600 --memory-limit=64M emails
Combined with the Messenger Doctrine Transport, this makes background processing on SymfonyCloud easily accessible - even with the Standard plan - and give more room to your main application to grow.
As a bonus, this size is also available for web containers, making a great value if you host an SPA and want to keep a maximum of resource for the PHP application.
This new size and its configuration controls open several new possibilities. We reworked our documentation with a dedicated cookbook containing several scaling and performance tips.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.