Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122029
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3
MIME-Version: 1.0
Message-ID: <c100955e-59f6-444d-9b77-c218b7975cd2@app.fastmail.com>
In-Reply-To: 
 <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
References: 
 <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
Date: Sun, 24 Dec 2023 09:21:05 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Dec 23, 2023, at 2:34 PM, K=C3=A9vin Dunglas wrote:
> Hello and Merry Christmas!
>
> One of the main features of FrankenPHP is its worker mode, which lets =
you
> keep a PHP application in memory to handle multiple HTTP requests.
>
> Worker modes are becoming increasingly popular in the PHP world. Symfo=
ny
> (Runtime Component), Laravel (Octane), and many projects based on these
> frameworks (API Platform, Sulu...) now support a worker mode.
>
> In addition to FrankenPHP, projects such as RoadRunner and Swoole prov=
ide
> engines supporting worker modes.
>
> According to benchmarks, worker modes can improve the performance of P=
HP
> applications by up to 15 times.
> In addition to FrankenPHP, which is basically a SAPI for Go's integrat=
ed
> web server, a new generation of SAPIs is currently under development.
> Several SAPIs written in Rust (including one by the RoadRunner team) a=
re
> currently under development.
>
> These SAPIs, along with existing SAPIs, could benefit from a shared
> infrastructure to build worker modes.
>
>
>
> The FrankenPHP code is written and should be easy to move around in PHP
> itself, to enable other SAPIs to use it.
>
> In addition to sharing code, maintenance, performance optimization, et=
c.,
> the existence of a common infrastructure would standardize the way wor=
ker
> scripts are created and provide a high-level PHP API for writing worker
> scripts that work with all SAPIs that rely on this new feature.
>
> SAPIs will still have to handle fetching requests from the web server =
and
> pausing the worker to wait for new requests (in FrankenPHP, we use
> GoRoutines for this, in Rust or C, other primitives will have to be us=
ed),
> but almost everything else could be shared.
>
> For reference, here's the FrankenPHP code I propose to integrate into
> libphp: https://github.com/dunglas/frankenphp/blob/main/frankenphp.c#L=
245
>
> The public API is documented here:
> https://frankenphp.dev/docs/worker/#custom-apps
>
> I'd like to hear what the community thinks about this. Would you be
> interested in this functionality in PHP? Should I work on an RFC?
>
> If there's interest, I can work on a patch.
>
> Cheers,

In concept, I love this and would be ecstatic to see it happen.

In practice, I want to understand the implications for user-space code. =
 Does this mean FPM could be configured in a way to execute a file like =
that shown in the docs page above?  Or would it only work with third par=
ty SAPIs like FrankenPHP?  I assume the handler function would be differ=
ently named.  Is passing in super-globals the right/best way to handle e=
ach request, or would it be sensible to have some other abstraction ther=
e?  (Whether a formal request object a la PSR-7 or something else.)  To =
what extent would user-space code run this way have to think about concu=
rrency, shared memory, persistent SQL connections, etc?  Does it have an=
y implications for fiber-using async code?

Depending on the details, this could be like fibers but for 3rd party SA=
PIs (something about 4 people in the world actually care about directly,=
 everyone else just uses Revolt, Amp, or React, but mostly it doesn't ge=
t used), or completely changing the way 90% of the market runs PHP, whic=
h means frameworks will likely adapt to use that model primarily or excl=
usively (ie, less of a need for a "compile" step as a generated containe=
r or dispatcher is just held in memory automatically already).  The latt=
er sounds exciting to me, but I'm not sure which is your intent, so I do=
n't know if I'm going too far with it. :-)

Please advise on what the implications would be for the non-SAPI-develop=
ing PHP devs out there.

--Larry Garfield