Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125911
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO2Zizv7mrzmxxiJ8t8yYVLGb-=KgwyvWUffo3ohdaOW-A@mail.gmail.com>
 <CAEKnhAE_M5m01G+vVjESKcc6ZH8uh_E67Xf0-Ogfk2VQi=Jnvg@mail.gmail.com> <CAEKnhAFPuog5P28a-_PvvVheupMpL+ch3jwGjP8T7w09O4uX+g@mail.gmail.com>
In-Reply-To: <CAEKnhAFPuog5P28a-_PvvVheupMpL+ch3jwGjP8T7w09O4uX+g@mail.gmail.com>
Reply-To: erictnorris@gmail.com
Date: Tue, 5 Nov 2024 11:50:25 -0500
Message-ID: <CA+NMNO0P12_nH2yJfGVKFVqYgF=McF9GGOPZWMT=pKCtLYh5Fg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Persistent CurlShareHandle objects
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: eric.t.norris@gmail.com (Eric Norris)

On Mon, Nov 4, 2024 at 2:13=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote:
>
> On Mon, Nov 4, 2024 at 2:21=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrot=
e:
>>
>> Hi,
>>
>> On Wed, Oct 9, 2024 at 10:18=E2=80=AFPM Eric Norris <eric.t.norris@gmail=
.com> wrote:
>>>
>>> Hello all,
>>>
>>> After receiving some feedback about
>>> https://github.com/php/php-src/pull/15603, I'm formally proposing an
>>> RFC to add persistent curl share handles here:
>>> https://wiki.php.net/rfc/curl_share_persistence
>>>
>>
>> I think what's really needed for this is to have some infrastructure for=
 connection pooling. The current persistent connections in streams (which i=
ncludes mysqlnd, redis and its other users) are quite primitive and not tha=
t well managed. This might occasionally result in incorrect clean up and po=
ssibly having too many connections open.
>>
>> What I think we need is a new internal API that would be handled by SAPI=
. So basically some generic API that SAPI would hook into and manage the co=
nnections. For extension it could work by registering the pool with some co=
nnect and clean up callbacks and various parameters (e.g. timeout and maybe=
 something else). Then it would be just getting the connections from it. It=
 should be quite generic so it can support also curl handles so the actual =
connection should be opaque. The point here is that SAPI should handle the =
pool and deal with timeouts / clean up. This could work pretty well for the=
 threaded SAPI's. FPM is a bit limited as it's per worker but it could pote=
ntially set its own limits and could still better handle timeouts and clean=
 ups.
>>
>> I think there should be not such a big oppositions to the general concep=
t because this is already rooted in PHP in the form of persistent resources=
 and this just tries to implement the same for objects which we might event=
ually need for streams if they ever get them converted to objects. There ar=
e likely many application successfully using persistent resources and it co=
uld be quite problematic to drop the whole concept.
>>
>> Basically what I want to say is that we have got chance to implement it =
properly for objects and we should not end up with the same sort of way how=
 it's done currently for resources. The better way is to have SAPI managed =
API IMHO.
>>
>
> Just for the reference I voted yes on RFC because that's just about the c=
oncept and user API which I think is fine and it's inline with persistence =
that we already have. But note that it doesn't mean that we will accept imp=
lementation in the current form.

Thank you for your feedback, and for your vote! I'm open to
implementation changes, so feel free to leave comments on the pull
request in the event this passes.

I'm also open to your idea of having a connection pooling mechanism in
the SAPI, and would be interested in helping draft that as an RFC if
that is necessary. I had noted something like this in the 'Future
Scope' section of this RFC, but wanted to aim small since this was my
first RFC.

Eric