Re: 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]