Questions regarding FrankenPHP and async processes

[gabrielius914]

Hey,

1. does the message consumer load the PHP application (services, kernel, etc) each time the message is received (like with the request)?
2. is it possible to improve Symfony Messenger's consumers performance with FrankenPHP worker mode or it only applies for HTTP requests?

[dunglas]

Hey,

1. No, it loads it only one time per process.
2. FrankenPHP worker mode is only for HTTP requests, but as FrankenPHP provides a ZTS version of PHP, this paves the way for new usages even in CLI. @alli83, @jwage and I are working in something specifically for Symfony Messenger. Stay tuned!

[nathan-de-pachtere]

Hey !

Any updates on the "something specifically for Symfony Messenger" you're working on? 😊

[alli83]

Hey!

still under review. @dunglas @nicolas-grekas

[IndraGunawan]

hey @alli83 , thanks for your work.

can you share the PR? i would love to see that

[alli83]

here is the PR: symfony/symfony#53964

[withinboredom]

the original, deleted, comment replied to:

That PR is about consuming the messages concurrently, is there a way to consume the message using frankenphp on standard way without concurrency? so i can take advantage without waiting the PR to be released

i know i can run the command using supervisord but if there is a frankenphp way it would be great

I'm actually did something like this for $dayJob. It's not open source ... yet (working on it!). But currently it is running in production. You can wire up frankenphp to SQS or RabbitMq and it runs your php concurrently upon receiving a message by wrapping the event in a http request. Hooking it up to other sources is relatively simple, but these are the ones we use at work. It isn't integrated with Symfony or anything like that, but for now, having a worker script boot up the kernel and dispatch is good enough. There are probably existing libraries out there, but it took us about an hour for the initial version and it has slowly grown.

I also have a PoC way to dispatch work between workers. So, you can create two worker pools, one for async work and another for requests. The web workers can then dispatch tasks to the async pool. It's still a super alpha/idea. But you could use this to dispatch emails, do other things, etc. Eventually, I want the API to have an "overflow" where it can dispatch to a global queue (looking at nats because it can be embedded in go) where if the local queue is empty, it can pick up items off the global queue (which may have many, many frontend servers running that can pick up the work).

This could allow for "packing" quite a bit of compute "on the edge" and then dispatching overflow back to less busy regions via the global queue, at the expense of some latency for the jobs.

There is still a long way to go with this idea though, but I've been working on it off-and-on for a few weeks, between other things.