Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122040
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <CAMrTa2GMApdyYrGQvxU1oQPqpdYa1CkHeFYcmxuyrRpkgYpa3w@mail.gmail.com>
 <CADU7aou-8rYd9AEjLWnLmbK7_fJoG6JWMr_+03rzfQmccni9QQ@mail.gmail.com> <CAMrTa2HNg34=26pOfsnfz6KfT-6LrefJRahowi-K=qEZ9UJZ5w@mail.gmail.com>
In-Reply-To: <CAMrTa2HNg34=26pOfsnfz6KfT-6LrefJRahowi-K=qEZ9UJZ5w@mail.gmail.com>
Date: Mon, 25 Dec 2023 20:13:58 +0100
Message-ID: <CADU7aoty+w+BDdG5ERHqQ0JrhrZZgVrYCp3wxqG0oHL2-Mb5cw@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000cfdb4c060d5a5e5e"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: kevin@dunglas.fr (=?UTF-8?Q?K=C3=A9vin_Dunglas?=)

--000000000000cfdb4c060d5a5e5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 25, 2023 at 7:56=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gmail.=
com>
wrote:

>
>
> On Mon, Dec 25, 2023 at 8:19=E2=80=AFAM K=C3=A9vin Dunglas <kevin@dunglas=
.fr> wrote:
>
>>
>> On Sun, Dec 24, 2023 at 10:44=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gm=
ail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 23, 2023 at 12:34=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dung=
las.fr> 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 thes=
e
>>>> frameworks (API Platform, Sulu...) now support a worker mode.
>>>>
>>>> In addition to FrankenPHP, projects such as RoadRunner and Swoole
>>>> provide
>>>> 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 PH=
P
>>>> itself, to enable other SAPIs to use it.
>>>>
>>>> In addition to sharing code, maintenance, performance optimization,
>>>> etc.,
>>>> the existence of a common infrastructure would standardize the way
>>>> worker
>>>> scripts are created and provide a high-level PHP API for writing worke=
r
>>>> 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
>>>> used),
>>>> 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#L245
>>>>
>>>> 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,
>>>> --
>>>> K=C3=A9vin Dunglas
>>>>
>>>
>>> Much like Larry, I'm curious what sort of scope you imagine for this.
>>> Are you imagining something that is geared specifically towards HTTP
>>> requests, or would this be a more generic "PHP Application Worker" that
>>> might be spawned to handle other types of applications? Could we have a
>>> worker listen to a specific port and respond to or handle all requests =
on
>>> that port/device?
>>>
>>> Jordan
>>>
>>
>> Ho Jordan,
>>
>> Yes, the scope I imagine is geared specifically towards HTTP requests.
>> Something more generic than common primitives for SAPIs and a shared pub=
lic
>> API to handle HTTP requests with a long-running PHP worker script will b=
e
>> hard to do outside of SAPIs because they depend on a lot of external
>> concerns such as the programming language the SAPI is using.
>>
>
> So you want to introduce a SAPI that doesn't work with any of the existin=
g
> HTTP solutions people use that only supports HTTP requests? Or am I
> misunderstanding something?
>
> This sounds a bit like you want to merge in a tool that is designed for
> your personal product directly into core. FrankenPHP may be incredible an=
d
> awesome, but the world runs on Apache and Nginx for HTTP requests.
>
> Jordan
>

As explained in the initial message and in my reply to Jakub, the main
targets are emerging SAPIs. We have no interest (quite the contrary) in
moving this code from FrankenPHP to PHP core (harder maintenance, slower
iterations as more collaboration will be involved...), but I do think that
having a "standard" and shared infrastructure and API for worker modes
between new generation SAPIs will be beneficial to the community as a whole
(no need - as at present - to write a different worker script for each
engine having a worker mode, sharing of optimizations, security patches
etc...).

We're talking roughly about a C function of a few dozen lines, not
something very big.

--000000000000cfdb4c060d5a5e5e--