> Deleu <[email protected]> hat am 06.10.2025 19:29 CEST geschrieben:
>
>
>
> Hi!
>
>
> On Mon, Oct 6, 2025 at 1:43 PM Edmond Dantes <[email protected]
> <mailto:[email protected]>> wrote: > > Hi.
> > > This is simply not true. The example you're replying to is quite common.
> >
> > It’s probably my poor English. So I’ll try to rephrase the idea:
> > The majority of database queries are executed sequentially, step by
> > step. Not all queries. Not always. But most of them.
> > This is true even in languages that already have async. >
> I find this a bit confusing to contextualize. I agree that most code written
> was probably written following the principle of 1-query-at-a-time, even in
> languages that already support async. But at the same time, if you're tasked
> with optimizing the time it takes for a certain HTTP Endpoint to execute then
> caching data OR rethinking query execution flow are among the top contenders
> for change. What I'm trying to say is that I would look at this from a
> different lensis. You're right that just because async is already available
> doesn't mean that queries will take advantage of it by default. But for the
> critical parts of a system that requires optimization of the execution
> duration, having async capabilities can easily drive the decision of how the
> code will be restructured to fulfill the need for performance improvements.
> > > > 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.
> > (It’s important not to overestimate this model, otherwise lately you
> > sometimes hear complaints that the ultra-trendy immutable philosophy
> > leads to terrible performance :))
> >
> > A stateful worker does not automatically mean active sharing of state
> > between requests. It gives the developer the choice of what can and
> > cannot be shared. You have a choice. If you want all services to
> > follow the immutable model — you can do that. But now you don’t have
> > to pay for compilation or initialization. You have complete creative
> > freedom. >
> Talking about stateful workers and shared-state here is a bit ambiguous, at
> least for me, tbh. When you say the developer has a choice, my interpretation
> is that you mean to say that the PHP Developer can choose what to share and
> what not to share by defining static variables, much like most other
> languages implement the Singleton Pattern. In PHP, especially with the
> share-nothing model, even static variables are cleared out. While there's no
> denying that there is value in creating a shareable space for performance
> gains, and this is seen in popularization of Swoole, Laravel Octane,
> FrankenPHP Worker Mode, etc; there's still a point to be made about the fact
> that 30 years worth of PHP code exists in the wild assuming that static
> variables gets cleared out between requests and as such are a non-trivial
> task to port them to newer execution models. This is where I think Larry's
> point comes strong with the fact that most these new "modern / non-legacy"
> execution models are just a rounding error in the amount of PHP code being
> executed everyday and where support of async execution for FPM would be a
> game changer for code that is too hard to lift-and-shift into worker mode,
> but not so hard to make adjustments in the next PHP upgrade to e.g.
> parallelize database queries.
> > > > 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."
> >
> > Almost no one wants to spend time building code with a technology that
> > isn’t supported. So when people want to do things like that, they
> > simply choose another language.
> > I’m not saying that async isn’t supported in CGI mode... but..
> > it’s just that a gain of a few milliseconds is unlikely to be noticeable. >
> >
> If you have a report that executes 3 queries and each query averages between
> 4 to 5 seconds, this report takes up to 15 seconds to run in PHP. The
> capability of executing async code in FPM would mean a 3x performance gain on
> a report like this. That is far from just a few milliseconds gain. And to be
> honest, the biggest gain for me would be the ability to keep the applications
> contextual logic within a single execution unit. One very common route that
> is taken with today's options is to break those 3 queries into separate HTTP
> endpoints and let the frontend stitch them together which provides a very
> similar performance gain by taking advantage of JS/Browser parallel requests
> since PHP is unable to do so.
> --
>
>
>
>
>
>
>
>
> Marco Deleu
I'd like to mention that running queries in parallel can give better
performance, but it depends on the resources available on the database server.
In case disk IO is the bottleneck and a single database server is used,
parallel execution can be even slower in worst case.
For MySQL/MariaDB, parallel execution normally helps (see
https://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#faq-mysql-support-multi-core).
For modern analytical databases using by default multiple CPU cores per query,
column stores, simd and many other optimizations, parallelization is mostly not
necessary since the connection time for a new connection is often slower than
executing a query.
Regards
Thomas
