Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122038
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <CAMrTa2GMApdyYrGQvxU1oQPqpdYa1CkHeFYcmxuyrRpkgYpa3w@mail.gmail.com> <CADU7aou-8rYd9AEjLWnLmbK7_fJoG6JWMr_+03rzfQmccni9QQ@mail.gmail.com>
In-Reply-To: <CADU7aou-8rYd9AEjLWnLmbK7_fJoG6JWMr_+03rzfQmccni9QQ@mail.gmail.com>
Date: Mon, 25 Dec 2023 10:56:26 -0800
Message-ID: <CAMrTa2HNg34=26pOfsnfz6KfT-6LrefJRahowi-K=qEZ9UJZ5w@mail.gmail.com>
To: =?UTF-8?Q?K=C3=A9vin_Dunglas?= <kevin@dunglas.fr>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000206ce8060d5a203a"
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000206ce8060d5a203a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 25, 2023 at 8:19=E2=80=AFAM K=C3=A9vin Dunglas <kevin@dunglas.f=
r> wrote:

>
> On Sun, Dec 24, 2023 at 10:44=E2=80=AFPM Jordan LeDoux <jordan.ledoux@gma=
il.com>
> wrote:
>
>>
>>
>> On Sat, Dec 23, 2023 at 12:34=E2=80=AFPM K=C3=A9vin Dunglas <kevin@dungl=
as.fr> wrote:
>>
>>> Hello and Merry Christmas!
>>>
>>> One of the main features of FrankenPHP is its worker mode, which lets y=
ou
>>> keep a PHP application in memory to handle multiple HTTP requests.
>>>
>>> Worker modes are becoming increasingly popular in the PHP world. Symfon=
y
>>> (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 provi=
de
>>> engines supporting worker modes.
>>>
>>> According to benchmarks, worker modes can improve the performance of PH=
P
>>> applications by up to 15 times.
>>> In addition to FrankenPHP, which is basically a SAPI for Go's integrate=
d
>>> web server, a new generation of SAPIs is currently under development.
>>> Several SAPIs written in Rust (including one by the RoadRunner team) ar=
e
>>> 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, etc=
.,
>>> the existence of a common infrastructure would standardize the way work=
er
>>> 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 a=
nd
>>> 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. Ar=
e
>> you imagining something that is geared specifically towards HTTP request=
s,
>> 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 publ=
ic
> API to handle HTTP requests with a long-running PHP worker script will be
> 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 existing
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 and
awesome, but the world runs on Apache and Nginx for HTTP requests.

Jordan

--000000000000206ce8060d5a203a--