Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125906
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO2Zizv7mrzmxxiJ8t8yYVLGb-=KgwyvWUffo3ohdaOW-A@mail.gmail.com>
In-Reply-To: <CA+NMNO2Zizv7mrzmxxiJ8t8yYVLGb-=KgwyvWUffo3ohdaOW-A@mail.gmail.com>
Date: Mon, 4 Nov 2024 14:21:34 +0100
Message-ID: <CAEKnhAE_M5m01G+vVjESKcc6ZH8uh_E67Xf0-Ogfk2VQi=Jnvg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Persistent CurlShareHandle objects
To: erictnorris@gmail.com
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000093ee9e0626162ae3"
From: bukka@php.net (Jakub Zelenka)

--00000000000093ee9e0626162ae3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Oct 9, 2024 at 10:18=E2=80=AFPM Eric Norris <eric.t.norris@gmail.co=
m> 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
includes mysqlnd, redis and its other users) are quite primitive and not
that well managed. This might occasionally result in incorrect clean up and
possibly 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
connections. For extension it could work by registering the pool with some
connect 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 potentially 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 concept
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
eventually need for streams if they ever get them converted to objects.
There are likely many application successfully using persistent resources
and it could 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.

Regards

Jakub

--00000000000093ee9e0626162ae3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Wed, Oct 9, 2024 at 10:18=E2=80=AFPM Eric Norri=
s &lt;<a href=3D"mailto:eric.t.norris@gmail.com">eric.t.norris@gmail.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hel=
lo all,<br>
<br>
After receiving some feedback about<br>
<a href=3D"https://github.com/php/php-src/pull/15603" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/php/php-src/pull/15603</a>, I&#39;m form=
ally proposing an<br>
RFC to add persistent curl share handles here:<br>
<a href=3D"https://wiki.php.net/rfc/curl_share_persistence" rel=3D"noreferr=
er" target=3D"_blank">https://wiki.php.net/rfc/curl_share_persistence</a><b=
r>
<br></blockquote><div><br></div><div>I think what&#39;s really needed for t=
his is to have some infrastructure for connection pooling. The current pers=
istent connections in streams (which includes mysqlnd, redis and its other =
users) are quite primitive and not that well managed. This might occasional=
ly result in incorrect clean up and possibly having too many connections op=
en.</div><div><br></div><div>What I think we need is a new internal API tha=
t would be handled by SAPI. So basically some generic API that SAPI would h=
ook into and manage the connections. For extension it could work by registe=
ring the pool with some connect and clean up callbacks and various paramete=
rs (e.g. timeout and maybe something else). Then it would be just getting t=
he connections from it. It should be quite generic so it can support also c=
url handles so the actual connection should be opaque. The point here is th=
at SAPI should handle the pool and deal with timeouts / clean up. This coul=
d work pretty well for the threaded SAPI&#39;s. FPM is a bit limited as it&=
#39;s per worker but it could potentially set its own limits and could stil=
l better handle timeouts and clean ups.</div><div><br></div><div>I think th=
ere should be not such a big oppositions to the general concept because thi=
s is already rooted in PHP in the form of persistent resources and this jus=
t tries to implement the same for objects which we might eventually need fo=
r streams if they ever get them converted to objects. There are likely many=
 application successfully using persistent resources and it could be quite =
problematic to drop the whole concept.</div><div><br></div><div>Basically w=
hat I want to say is that we have got chance to implement it properly for o=
bjects and we should not end up with the same sort of way how it&#39;s done=
 currently for resources. The better way is to have SAPI managed API IMHO.<=
/div><div><br></div><div>Regards</div><div><br></div><div>Jakub</div></div>=
</div>

--00000000000093ee9e0626162ae3--