In my opinion, PHP must add asynchronous and concurrent support as soon as possible, and
asynchronous IO must be regarded as a first-class citizen.
Over the past few decades, the one-process-one-request model of PHP-FPM has been remarkably
successful; it is simple and reliable. However, modern web applications do much more than merely
reading from databases or caches, or handling internal HTTP requests—frequent cross-domain
requests have become the norm.
The response times for these external HTTP calls are often unpredictable. Under the PHP-FPM model,
delays or timeouts from certain external APIs can easily trigger a cascading failure, bringing down
the entire system.
Since the emergence of ChatGPT in 2024, many software systems have been trying to integrate AI
models from OpenAI, Anthropic, Google Gemini, and others.
These APIs often take tens of seconds to respond, and PHP-FPM with multi-process is almost
unavailable in such scenarios.
Only asynchronous I/O offers a real solution to these challenges.
Wordpress, as the PHP application with the largest number of users, may need to add LLM capabilities
in the future.
If PHP cannot provide support, Wordpress developers may also consider abandoning PHP and using other
programming languages that support asynchronous IO for refactoring.
PHP must set aside its past achievements and fully embrace the Async IO tech stack.
Tianfeng Han
10/10/2025
------------------ Original ------------------
From: "Rowan Tommins [IMSoP]"<[email protected]>;
Date: Tue, Oct 7, 2025 05:26 AM
To: "php internals"<[email protected]>;
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
On 06/10/2025 20:18, Larry Garfield wrote:
> The core point is this: Any async approach in core needs to treat the FPM use case as a
first-class citizen, which works the same way, just as reliably, as it would in a persistent CLI
command. That is not negotiable.
>
> If for no other reason than avoiding splitting the ecosystem into async/CLI and sync/FPM
libraries, which would be an absolute disaster.
I 100% agree. In fact, perhaps the single biggest benefit of having a
core async model would be to reverse the current fragmentation of
run-times and libraries.
On 06/10/2025 19:50, Edmond Dantes wrote:
> If you want to improve performance, you need to optimize SQL queries,
> not try to execute them in parallel. This can bring down the entire
> database (like it did today 🙂 )
You talk as though "the database" is a single resource, which can't be
scaled out. That's not the case if you have a scalable cluster of
SQL/relational databases, or a dynamically sharded NoSQL/document-based
data store, or are combining data from unconnected sources.
> a project with several tens of
> thousands of lines of code was adapted for Swoole in 2–3 weeks. It
> didn’t work perfectly, sometimes it would hang ...
2-3 weeks of development to get to something that's not even production
ready is a significant investment. If your application's performance is
bottlenecked on external I/O (e.g. data stores, API access), the
immediate gain is probably not worth it.
For those applications, the only justification for that investment is
that it unlocks a further round of development to use asynchronous I/O
on those bottlenecks. What would excite me is if we can get extensions
and libraries to a point where we can skip the first part, and just add
async I/O to a shared-nothing application.
--
Rowan Tommins
[IMSoP]