Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128791
Date: Mon, 6 Oct 2025 20:47:48 +0200 (CEST)
To: Deleu <deleugyn@gmail.com>, Edmond Dantes <edmond.ht@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>,
	php internals <internals@lists.php.net>
Message-ID: <453862111.154105.1759776468063@email.ionos.de>
In-Reply-To: <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_154104_964033218.1759776468059"
Importance: Normal
UI-OutboundReport: notjunk:1;M01:P0:iSN3PTsdjvo=;0mk6ko8XLMfMAWicIAlw5+5iyA2
 0zmrbRFfeLviIkXxD//u12v1IoFv9FOd2HQp1PkoYMDTwU4AhKe8O2niNJ8zwRV0DOIVusrvQ
 t1/ueFf8SZk7e1e8QDZEh7HFFX0MKw2kULeh5UcqVXeV5Er0u2PP+0GJLzb3dL2IoPjCQxhCU
 0gOmMfNG/6hslSBtjGt+mTMlBxCzFUW1NYb5syRLPZ/ircv0rk0pCu5yUhST8cPhBmyQeSWoY
 cXH+m6GggOCIUUoJKqRm/FqM5zYth3sQH8tw9t8GdOXKVZtS2XVaWA9YKw2bFyg4qb8XjFrXe
 5aAzDSny6QEfPHQVxtA5VIlYxJhajqbL5TadUUFdPXa0q3JSeUe274MZKXHXGT7q8XSXr96+f
 7/v+22I7UlaG6ynny23Tj320hyPDPiGorI4v7U9LEDZVNs10AlltraeQxbGiR1s5/kmRjbg+U
 MQzYoWpYmJ1Bcrh/K2QCNArOWhcimjTd7OUDiLdM/QkMIcoQwnz6Jk80GzN9UoKnrFDfToNJf
 37zZhX+DwGcIh8O1Uz5TzU0PqKdTdx3MlfdgGsoXkzPngem45MvftCTmdPwdqdvUWX1y+iFFJ
 m7fZlQIoi7UAcdi/VJgeFioQk11Ck6pwjzOeKTel+m9WT9/fmRFMB/ko4ROQs1ZI8f28/FFSs
 +lkiBUsBoWQNq5osXKrTHwWbZqWacmGtQjMkL4Exfc5cGHLs/x1GH9XgFjgIkXx+pFZmELnls
 cedbVDwKciIUDKhGgPPrXIxN/UNYFJlaqeCFaGZ0SUAVSkzz5qMixJQuW3aWSvgHOHzpH0+Bj
 sAjHmZFSixptJWx4edD+EMiw47r2tMKXimsJhc05iKFcBZ4iHFv0n6aiVKYVdN5v3pb3rWeZI
 jQY7CbUIB9x9o+SZfPK8+sPRAdZl8fkHpr/hKfFcKfE2QdO3OmGkX9mfatfRn1SxVAQUyMEHG
 wqZdCUpxyqjHGvi7mfgYDFwIdfeJeQZZH4YU3xRO07n50L8D0FtIn7xmWNEylOGReFMgSL+WB
 hSQMQbdnt0oT+inR6qryq5OJ/qJc4Sj+ib/JeWv/PyLxffCZnMFBDvD4TJWxYw3Z+n1V26ICi
 7R4FYMcBNob27HhjWa9V+W6FYtr2Xaz1vuz8tCWqFsF3X/n9vq3sK7875ubxgoozUOgZOiBXb
 XaJEIDJr4NlkUIPw1xwFKCzkVEW2xlnCmE3ahyC8WFuJVwCK1zuOaEoCg6IT36ezVGJQSxjQ4
 zW6cUr/3YE87JTwBiqFESTWNcgFWf0rBzKnk48oZVhHqxs/PL2P7VKjwXF/BRG5L34MS3uqJJ
 sQIJ2eyRf3CLFC/xNSpsetHBVd6AoOyGG9jFNEJSKNmUs9nv8tLPSV0CAeJYgkm7XC6bBoxwK
 fPdfthcsk9vze9fR8D11YplXiev6p8mlOuf1Qtf7fHBJJOF5FAC3BzcclyM9+s/bUA80hZlmG
 ntsFdtIfccps8LjmuSupn1oNIo8PxPZn8XkbweM7egZd6H6+I8QCtqPU//9xSXTdhGXipROSN
 dqsp6HEKzOMJcawK6K1BmO9Irvuh5QwYiZUeP05NPf5S1KO6bIxM+NfP6Aqsjie4/emWrBDjV
 I+PURTNXphRC9WtRfBMg7dd0uBk4TrY9IradDFClC/PQvybq0cBSXodUEuCtkxMfYlnphDxvp
 idBgHE0gYt5KJsbjFvCbt9
From: mails@thomasbley.de (Thomas Bley)

------=_Part_154104_964033218.1759776468059
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

  > Deleu <deleugyn@gmail.com> hat am 06.10.2025 19:29 CEST geschrieben:
> =20
> =20
>=20
> Hi!
>=20
>=20
> On Mon, Oct 6, 2025 at 1:43=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com=
 <mailto:edmond.ht@gmail.com>> wrote: > > Hi.
> > > This is simply not true.  The example you're replying to is quite com=
mon.
> >=20
> > It=E2=80=99s probably my poor English. So I=E2=80=99ll 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. > =20
> I find this a bit confusing to contextualize. I agree that most code writ=
ten 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 t=
asked with optimizing the time it takes for a certain HTTP Endpoint to exec=
ute 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 av=
ailable 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 execu=
tion duration, having async capabilities can easily drive the decision of h=
ow the code will be restructured to fulfill the need for performance improv=
ements.
>   > > > That is *A benefit*.  It is not the *only benefit*.  Being able t=
o 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 latel=
y you
> > sometimes hear complaints that the ultra-trendy immutable philosophy
> > leads to terrible performance :))
> >=20
> > 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. > =20
> 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 interpret=
ation is that you mean to say that the PHP Developer can choose what to sha=
re and what not to share by defining static variables, much like most other=
 languages implement the Singleton Pattern. In PHP, especially with the sha=
re-nothing model, even static variables are cleared out. While there's no d=
enying that there is value in creating a shareable space for performance ga=
ins, and this is seen in popularization of Swoole, Laravel Octane, FrankenP=
HP Worker Mode, etc; there's still a point to be made about the fact that 3=
0 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 po=
rt them to newer execution models. This is where I think Larry's point come=
s 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 e=
veryday and where support of async execution for FPM would be a game change=
r 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 databa=
se queries.
>   > > > Remember, in the wild, PHP-FPM and mod_php are by orders of magni=
tude the most common ways PHP is executed.  React, Swoole, etc. are roundin=
g errors in most of the market.  And the alternate runtime with the most mo=
mentum is FrankenPHP, which reuses processes but is still "one request in a=
 process at a time."
> >=20
> > 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, th=
ey
> > 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 n=
oticeable. > =20
> If you have a report that executes 3 queries and each query averages betw=
een 4 to 5 seconds, this report takes up to 15 seconds to run in PHP. The c=
apability of executing async code in FPM would mean a 3x performance gain o=
n 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 applic=
ations contextual logic within a single execution unit. One very common rou=
te that is taken with today's options is to break those 3 queries into sepa=
rate HTTP endpoints and let the frontend stitch them together which provide=
s a very similar performance gain by taking advantage of JS/Browser paralle=
l requests since PHP is unable to do so.
>   --
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Marco Deleu=20
I'd like to mention that running queries in parallel can give better perfor=
mance, 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, paral=
lel 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 que=
ry, column stores, simd and many other optimizations, parallelization is mo=
stly not necessary since the connection time for a new connection is often =
slower than executing a query.
=20
Regards
Thomas

------=_Part_154104_964033218.1759776468059
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!doctype html>
<html>
 <head>
  <meta charset=3D"UTF-8">
 </head>
 <body>
  <div>
   &nbsp;
  </div>
  <blockquote type=3D"cite">
   <div>
    Deleu &lt;deleugyn@gmail.com&gt; hat am 06.10.2025 19:29 CEST geschrieb=
en:
   </div>
   <div>
    &nbsp;
   </div>
   <div>
    &nbsp;
   </div>
   <div dir=3D"ltr">
    <div>
     Hi!
    </div>
    <br>
    <div class=3D"gmail_quote gmail_quote_container">
     <div class=3D"gmail_attr" dir=3D"ltr">
      On Mon, Oct 6, 2025 at 1:43=E2=80=AFPM Edmond Dantes &lt;<a href=3D"m=
ailto:edmond.ht@gmail.com">edmond.ht@gmail.com</a>&gt; wrote:
     </div>
     <blockquote>
      Hi.
      <br>
      &gt; This is simply not true.&nbsp; The example you're replying to is=
 quite common.
      <br>
      <br>
      It=E2=80=99s probably my poor English. So I=E2=80=99ll try to rephras=
e 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.
     </blockquote>
     <div>
      &nbsp;
     </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 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 t=
his from a different lensis. You're right that just because async is alread=
y 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 e=
xecution duration, having async capabilities can easily drive the decision =
of how the code will be restructured to fulfill the need for performance im=
provements.
     </div>
     <div>
      &nbsp;
     </div>
     <blockquote>
      <br>
      &gt; That is *A benefit*.&nbsp; It is not the *only benefit*.&nbsp; B=
eing able to compress the time of each request in a shared-nothing model is=
 absolutely valuable.
      <br>
      (It=E2=80=99s important not to overestimate this model, otherwise lat=
ely you
      <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.
     </blockquote>
     <div>
      &nbsp;
     </div>
     <div>
      Talking about stateful workers and shared-state here is a bit ambiguo=
us, at least for me, tbh. When you say the developer has a choice, my inter=
pretation 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 o=
ther 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 performanc=
e gains, and this is seen in popularization of Swoole, Laravel Octane, Fran=
kenPHP Worker Mode, etc; there's still a point to be made about the fact th=
at 30 years worth of PHP code exists in the wild assuming that static varia=
bles gets cleared out between requests and as such are a non-trivial task t=
o 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" execut=
ion models are just a rounding error in the amount of PHP code being execut=
ed everyday and where support of async execution for FPM would be a game ch=
anger 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 da=
tabase queries.
     </div>
     <div>
      &nbsp;
     </div>
     <blockquote>
      <br>
      &gt; Remember, in the wild, PHP-FPM and mod_php are by orders of magn=
itude the most common ways PHP is executed.&nbsp; React, Swoole, etc. are r=
ounding errors in most of the market.&nbsp; And the alternate runtime with =
the most momentum is FrankenPHP, which reuses processes but is still "one r=
equest in a process at a time."
      <br>
      <br>
      Almost no one wants to spend time building code with a technology tha=
t
      <br>
      isn=E2=80=99t supported. So when people want to do things like that, =
they
      <br>
      simply choose another language.
      <br>
      I=E2=80=99m not saying that async isn=E2=80=99t supported in CGI mode=
... but..
      <br>
      it=E2=80=99s just that a gain of a few milliseconds is unlikely to be=
 noticeable.
     </blockquote>
     <div>
      &nbsp;
     </div>
     <div>
      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. T=
he capability of executing async code in FPM would mean a 3x performance ga=
in on a report like this. That is far from just a few milliseconds gain. An=
d to be honest, the biggest gain for me would be the ability to keep the ap=
plications 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 pro=
vides a very similar performance gain by taking advantage of JS/Browser par=
allel requests since PHP is unable to do so.
     </div>
    </div>
    <div>
     &nbsp;
    </div><span class=3D"gmail_signature_prefix">-- </span>
    <br>
    <div class=3D"gmail_signature" dir=3D"ltr">
     <div dir=3D"ltr">
      <div dir=3D"ltr">
       <div dir=3D"ltr">
        <div dir=3D"ltr">
         <div dir=3D"ltr">
          <div dir=3D"ltr">
           <div dir=3D"ltr">
            Marco Deleu
           </div>
          </div>
         </div>
        </div>
       </div>
      </div>
     </div>
    </div>
   </div>
  </blockquote>
  <div>
   <br>
   I'd like to mention that running queries in parallel can give better per=
formance, 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, pa=
rallel execution can be even slower in worst case.
  </div>
  <div class=3D"default-style">
   For MySQL/MariaDB, parallel execution normally helps (see <a href=3D"htt=
ps://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#faq-mysql-support-mu=
lti-core">https://dev.mysql.com/doc/refman/8.0/en/faqs-general.html#faq-mys=
ql-support-multi-core</a>).
  </div>
  <div class=3D"default-style">
   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 oft=
en slower than executing a query.
  </div>
  <div class=3D"default-style">
   &nbsp;
  </div>
  <div class=3D"default-style">
   Regards
  </div>
  <div class=3D"default-style">
   Thomas
  </div>
 </body>
</html>
------=_Part_154104_964033218.1759776468059--