Re: PHP True Async RFC Stage 4
| From: | Larry Garfield | Date: | Mon, 06 Oct 2025 15:28:07 +0000 |
| Subject: | Re: PHP True Async RFC Stage 4 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-128788@lists.php.net to get a copy of this message | ||
On Mon, Oct 6, 2025, at 12:34 AM, Edmond Dantes wrote:
> Hello.
>
>> Just a quick question - other methods that tried to provide async/parallel type
>> functionality previously were only available via the CLI.
>
> TrueAsync itself is integrated into PHP in such a way that it is
> always active. The scenario you described is technically possible (Of
> course, this can also be useful for sending telemetry in a way that
> doesn’t interfere with request processing.), but it’s not particularly
> relevant in the context of modern development.
>
> Why?
>
> Because client requests are usually processed sequentially, step by
> step. Parallel tasks are rare.
This is simply not true. The example you're replying to is quite common.
It's even more common for the database. WordPress, Drupal, and many other such systems
frequently run different DB queries to build different components of a page. (Blocks, widgets,
components, the names differ.) Being able to do those in parallel is a natural optimization that we
were thinking about in Drupal nearly 15 years ago, but it wasn't viable at the time.
> Therefore, from the server’s
> perspective, the main benefit of concurrency is the ability to handle
> multiple requests within a single process.
That is *A benefit*. It is not the *only benefit*. Being able to compress the time of each request
in a shared-nothing model is absolutely valuable.
Remember, in the wild, PHP-FPM and mod_php are by orders of magnitude the most common ways PHP is
executed. React, Swoole, etc. are rounding errors in most of the market. And the alternate runtime
with the most momentum is FrankenPHP, which reuses processes but is still "one request in a
process at a time."
> The same thing that Swoole,
> AMPHP, and other modern backend solutions do.
>
> And this is one of the reasons why FPM is morally outdated and
I am going to assume this is a translation issue, because "morally outdated" is the wrong
term here. "Morally outdated" is how you'd describe "racial segregation is
good, actually." Not "this technology is slower than we need it to be." You
probably mean "severely outdated" or something along those lines.
Which, as I explained above, is simply not true. PHP is going to be running in a mostly
shared-nothing environment for the foreseeable future. Those use cases still would benefit from
async support.
--Larry Garfield