Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128790
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com>
Date: Mon, 6 Oct 2025 14:29:19 -0300
Message-ID: <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c49f97064080cc6b"
From: deleugyn@gmail.com (Deleu)

--000000000000c49f97064080cc6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi!

On Mon, Oct 6, 2025 at 1:43=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com> =
wrote:

> Hi.
> > This is simply not true.  The example you're replying to is quite commo=
n.
>
> It=E2=80=99s probably my poor English. So I=E2=80=99ll try to rephrase th=
e 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=E2=80=99s 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 =E2=80=94 you can do that. But now you don=E2=
=80=99t 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=E2=80=99t supported. So when people want to do things like that, they
> simply choose another language.
> I=E2=80=99m not saying that async isn=E2=80=99t supported in CGI mode... =
but..
> it=E2=80=99s just that a gain of a few milliseconds is unlikely to be not=
iceable.
>

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.

--=20
Marco Deleu

--000000000000c49f97064080cc6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi!</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 6, 2025 at 1:43=
=E2=80=AFPM Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond=
.ht@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Hi.<br>
&gt; This is simply not true.=C2=A0 The example you&#39;re replying to is q=
uite common.<br>
<br>
It=E2=80=99s probably my poor English. So I=E2=80=99ll try to rephrase the =
idea:<br>
The majority of database queries are executed sequentially, step by<br>
step. Not all queries. Not always. But most of them.<br>
This is true even in languages that already have async.<br></blockquote><di=
v><br></div><div>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 ti=
me, if you&#39;re tasked with optimizing the time it takes for a certain HT=
TP Endpoint to execute then caching data OR rethinking query execution flow=
 are among the top contenders for change. What I&#39;m trying to say is tha=
t I would look at this from a different lensis. You&#39;re right that just =
because async is already available doesn&#39;t mean that queries will take =
advantage of it by default. But for the critical parts of a system that req=
uires 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.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<br>
&gt; That is *A benefit*.=C2=A0 It is not the *only benefit*.=C2=A0 Being a=
ble to compress the time of each request in a shared-nothing model is absol=
utely valuable.<br>
(It=E2=80=99s important not to overestimate this model, otherwise lately yo=
u<br>
sometimes hear complaints that the ultra-trendy immutable philosophy<br>
leads to terrible performance :))<br>
<br>
A stateful worker does not automatically mean active sharing of state<br>
between requests. It gives the developer the choice of what can and<br>
cannot be shared. You have a choice. If you want all services to<br>
follow the immutable model =E2=80=94 you can do that. But now you don=E2=80=
=99t have<br>
to pay for compilation or initialization. You have complete creative<br>
freedom.<br></blockquote><div><br></div><div>Talking about stateful workers=
 and shared-state here is a bit ambiguous, at least for me, tbh. When you s=
ay the developer has a choice, my interpretation is that you mean to say th=
at the PHP Developer can choose what to share and what not to share by defi=
ning static variables, much like most other languages implement the Singlet=
on Pattern. In PHP, especially with the share-nothing model, even static va=
riables are cleared out. While there&#39;s no denying that there is value i=
n creating a shareable space for performance gains, and this is seen in pop=
ularization of Swoole, Laravel Octane, FrankenPHP Worker Mode, etc; there&#=
39;s still a point to be made about the fact that 30 years worth of PHP cod=
e exists in the wild assuming that static variables gets cleared out betwee=
n requests and as such are a non-trivial task to port them to newer executi=
on models. This is where I think Larry&#39;s point comes strong with the fa=
ct that most these new &quot;modern / non-legacy&quot; execution models are=
 just a rounding error in the amount of PHP code being executed everyday an=
d 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 ma=
ke adjustments in the next PHP upgrade to e.g. parallelize database queries=
.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; Remember, in the wild, PHP-FPM and mod_php are by orders of magnitude =
the most common ways PHP is executed.=C2=A0 React, Swoole, etc. are roundin=
g errors in most of the market.=C2=A0 And the alternate runtime with the mo=
st momentum is FrankenPHP, which reuses processes but is still &quot;one re=
quest in a process at a time.&quot;<br>
<br>
Almost no one wants to spend time building code with a technology that<br>
isn=E2=80=99t supported. So when people want to do things like that, they<b=
r>
simply choose another language.<br>
I=E2=80=99m not saying that async isn=E2=80=99t supported in CGI mode... bu=
t..<br>
it=E2=80=99s just that a gain of a few milliseconds is unlikely to be notic=
eable.<br></blockquote><div><br></div><div>If you have a report that execut=
es 3 queries and each query averages between 4 to 5 seconds, this report ta=
kes 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 m=
e would be the ability to keep the applications contextual logic within a s=
ingle execution unit. One very common route that is taken with today&#39;s =
options is to break those 3 queries into separate HTTP endpoints and let th=
e frontend stitch them together which provides a very similar performance g=
ain by taking advantage of JS/Browser parallel requests since PHP is unable=
 to do so.</div></div><div><br></div><span class=3D"gmail_signature_prefix"=
>-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">=
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></div><=
/div></div></div>

--000000000000c49f97064080cc6b--