Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125907 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 5D15C1A00BD for ; Mon, 4 Nov 2024 19:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1730747734; bh=phkJi/kBwxRmPbhQCZZUwhLBnOS0Bzlaq/gkFWNZx10=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=C9dUK9j4SF2K1y+ABuKELWlAhgdpT78XxD5On8Ts/q5oXqkduSu9jn1Qgfyb3M1Y7 o4cQjOrNbZ58fuHdDunZCmWuzUE5X8rSs7Ajg/QwVinnFXR8Ke+EQUvknKtRBR6vOV ejoHOhQeNhxZy+ySh+wNVMx/VRO9hkCG4JGeO6azLCXlixIrIp9U0eb2eeX1faKHCc 4pdpvouqV1RM2LP5ZS6pSTSOhqcvk7Dx+suxI8SnGlGViYuFPk0cjjUHJVdB3vaLh5 BRYhInTeJ7ZliTSl6j4CHW1xhkWx0VDPZJTelIHC2irBVICG3p/deCKpP9UFE10wZf ANLpctJA+3sXw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8E6FC180037 for ; Mon, 4 Nov 2024 19:15:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 4 Nov 2024 19:15:32 +0000 (UTC) Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-5ebc0992560so2768497eaf.0 for ; Mon, 04 Nov 2024 11:13:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730747581; x=1731352381; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=phkJi/kBwxRmPbhQCZZUwhLBnOS0Bzlaq/gkFWNZx10=; b=oXLkKYqt0EZP0lJjzhxYp66ZjjDtXktand/cL6QC7DQyWFN/5Vgyq3qQVVF+uQ6rkS LH+1kvVu74PQZ2eN89w/+HYIhrWcUae/Qk0P0CavhgsW0bVUzTLSkkB1deAAk2kdUvYr cJ5jhan7T/NzMfr5bcLjm7nw5cDIadBV1AXy9Ze/E4h/cyY8HYARcWE36nlXwq06jjHS JPE5krIisOEhFYfhzH68GbDgJDMZsha+N+UQsSbNfSCCE5W8ZbFmXb5fHK8xkL4MwYPl O5Dzgt5oEKIk+J6K1i+2gNW47hS7omXJN/CrmZnSAIWlHqpCmbm7CoPbk5DXB3gB2krX lbJQ== X-Gm-Message-State: AOJu0Yw898YM1moK9Vj65D8l8Kd4UQILf1XbVwsCi77AulVxVPLfcA5W 5K1NLPPkCF+8yiBQ9QoEh6nKWvvaJYDawy4rl0ZeSH+Hdxo36fjuGTXk8f25dC+BOkEp1MlyQAX sz+FzmpUb9QISWghkTucrPscdBVM= X-Google-Smtp-Source: AGHT+IE2D8ScyNeFNZsyptktPjKzMbRRX0uenqRuHjQvw4aVDQwgjIoWksJLVkN0TCZOGuG7xj7ur1QI5eMeME33dLA= X-Received: by 2002:a05:6820:1ad5:b0:5e1:e65d:5148 with SMTP id 006d021491bc7-5ec2397a323mr22224774eaf.6.1730747580959; Mon, 04 Nov 2024 11:13:00 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 4 Nov 2024 20:12:49 +0100 Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Persistent CurlShareHandle objects To: erictnorris@gmail.com Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c254b806261b1214" From: bukka@php.net (Jakub Zelenka) --000000000000c254b806261b1214 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 4, 2024 at 2:21=E2=80=AFPM Jakub Zelenka wrote: > Hi, > > On Wed, Oct 9, 2024 at 10:18=E2=80=AFPM Eric Norris > 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 a= nd > 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 som= e > 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 h= ow > 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 concept 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 implementation in the current form. Regards Jakub --000000000000c254b806261b1214 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 4, 2024 at 2:21=E2=80=AFPM Ja= kub 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 form= ally 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 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.

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'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.

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.

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's done= currently for resources. The better way is to have SAPI managed API IMHO.<= /div>


Just for t= he reference I voted yes on RFC because that's just about the concept a= nd 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.

Regards

Jakub
--000000000000c254b806261b1214--