Async use cases

[EdmondDantes]

In this thread you may share examples of tasks you have already solved using async in PHP, or tasks that would be easier to solve with it.
You may include code examples if you wish.
This topic may become useful for shaping the API.

You will also help other PHP developers learn something new or look at old problems from a different perspective.
That’s why this thread can be extremely useful for everyone!

[danog]

IMO this is a given (otherwise we wouldn't even be having this discussion), but since it wasn't spelled out, concurrency allows for:

• Higher performance with entirely local caching
• HIgher performance by concurrent execution of I/O (read, write files at the same time, increasing throughput; fetch multiple URLs at the same time, over a single http/2 connection, increasing throughput and removing overhead (curl_multi_init was added for this reason))
• Much easier background execution of tasks
• Higher request throughput, due to the greatly reduced setup overhead per-request (non-async worker-mode can also help, but concurrency has the added performance benefit of reducing context switches)

Other languages have introduced concurrency for these reasons and many more, PHP is the only one left behind, and that's all there is to it.

[macropay-solutions]

1. Eloquent's eager loading executes in sync, one select per relation. When there are multiple (>30 relations), async would allow them to be executed async and then only their results will be parsed/loaded sync into the model.
   That would shorten the time needed for retrieving the data from QT1 + QT2 + ... + QT30 to MAX(QT1, QT2, ... , QT30). The hydration will take the same amount of time.

2. When importing CSVs and dispatching them in batches of 10 rows each (for example), to be processed in a queue job, that job could start processing async all 10 rows at once.

3. When updating a composed resource via API, you have to update the main table from DB and then its 1:1 related tables. If the updates can be made without a DB transaction, then in theory all involved tables could be updated async from a middleware.

This is if the async would not be restricted to single thread(worker). See related question about this.

[EdmondDantes]

Today I ran into a task where async would be useful.
The task: implement a progressive delay when entering a password.
The solution: if you call sleep in a regular PHP script, it keeps an entire worker occupied. If you use this approach, an attacker can easily flood the server. All they need is a few parallel threads trying wrong passwords, and the worker pool will be exhausted very quickly.

For a stateful server using coroutines, such a delay costs far fewer resources. At the same time, a stateful server gains additional options for preventing this type of attack, because the server knows all its connections and operations and can be optimized accordingly.

[ioweb-gr]

This maps directly to webhook delivery with exponential back off.

A common scenario is sending a callback to an ERP after a job completes. If the ERP responds with 429 you have to retry later. At the moment the only options are to republish the message with a delay block the worker with sleep or rely on cron based retry logic.

With coroutines the worker can keep the task alive and simply yield during the back off window while continuing to process other webhooks. When the delay expires the coroutine resumes and retries. This removes worker blocking reduces queue churn and makes the whole pipeline far more resilient.

Both cases deal with delaying execution without blocking a worker so the task can wait while the system keeps handling other work which is exactly what coroutines enable.

[marius-ciclistu]

Keeping alive so many sleeping PIDs will not have negative consequences? What if a SIGTERM arrives because of a scale down or deploy scenario? You have to dispatch a job for each sleeping PID. Risky...

[EdmondDantes]

This maps directly to webhook delivery with exponential back off.

Yes, this is one of the typical scenarios that PHP is currently missing.

[EdmondDantes]

Keeping alive so many sleeping PIDs will not have negative consequences? What if a SIGTERM arrives because of a scale down or deploy scenario? You have to dispatch a job for each sleeping PID. Risky...

Of course this would be a problem, which is why I’m saying that PHP cannot handle such scenarios at all.