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]
