Symfony News

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 command with symfony-deploy:

# .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:

# .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: symfony project:init

When this command detects that your project has symfony/messenger installed, it will now add a default worker with an optimized configuration.

If you already have a configuration generated, you can run symfony project ::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 S 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:

# .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.


Sponsor the Symfony project.


About us

What a Symfony developer should know about the framework: News, Jobs, Tweets, Events, Videos,...

Find us on Twitter

Find us on Facebook

ADS