Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128794
Feedback-ID: id5114917:Fastmail
Message-ID: <d11875bb-5d3a-4446-9a0b-36bdb00f22dd@rwec.co.uk>
Date: Mon, 6 Oct 2025 22:22:53 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Language: en-GB
To: internals@lists.php.net
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CADuktwNP+t-DJbLCsnHHhztZYmOMGYde9rzNm+9B0SUsrNvV-g@mail.gmail.com>
 <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com>
 <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com>
 <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com>
 <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com>
 <CAMW7n8BWvf-bE6g7A_0vDW1Lf8hhTm-zuyNEY23DA0biNS-YSA@mail.gmail.com>
 <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
In-Reply-To: <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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]