Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D3271E.2080207@php.net>
References: <DDA98D4F-2105-415A-B921-01A622091FA9@php.net>
	<54D217E7.8030407@php.net>
	<54D2AE91.8090800@gmail.com>
	<54D3271E.2080207@php.net>
Date: Fri, 6 Feb 2015 00:49:06 +0700
Message-ID: <CAEZPtU65NirGfES1qiic45Ui3qY45X+k370o2BSj3kbwLendjg@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: PHP internals <internals@lists.php.net>, Stas Malyshev <smalyshev@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3bb8eae1872050e5aeb57
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
From: pierre.php@gmail.com (Pierre Joye)

--001a11c3bb8eae1872050e5aeb57
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Feb 5, 2015 3:17 PM, "Michael Wallner" <mike@php.net> wrote:
>
> Hi Stas!
>
> On 05/02/15 00:43, Stanislav Malyshev wrote:
> > Hi!
> >
> >> Points explicitely marked for discussion in the RFC itself:
> >>
> >> * pecl/propro
> >>   Proxies for properties representing state in internal C structs
> >>   https://wiki.php.net/rfc/pecl_http#peclpropro
> >>
> >> * pecl/raphf
> >>   (Persistent) handle management within objects instead of resources
> >>   https://wiki.php.net/rfc/pecl_http#peclraphf
> >>   Also, take special note of the INI setting:
> >>   https://wiki.php.net/rfc/pecl_http#raphf_ini_setting
> >
> > I'm still not sure why we need these two, to be frank. E.g., for the
> > former I can kind of get it, though I don't see any use-case that reall=
y
> > requires going to such lengths, for the latter I'm not even sure what
> > the case for that is - i.e., why exactly would one need persistent HTTP
> > connections surviving the request?
>
> Uh, for me it's actually the reverse :) While propro is nice to have, I
> think raphf is far more of practical use. Why should HTTP, or even more
> HTTPS or HTTP2, be any different than another service, especially when
> HTTP APIs are so common nowadays.
>
> Compare the timings accessing google 20 times sequentually:
>
> With default of raphf.persistent_handle.limit=3D-1 (unlimited):
> =E2=96=88 mike@smugmug:~$ time php -r 'for ($i=3D0;$i<20;++$i) {(new
> http\Client("curl","google"))->enqueue(new http\Client\Request("GET",
> "http://www.google.at/"))->send();}'
>
> 0.03s user 0.01s system 2% cpu 1.530 total
>
>
> With raphf effectively disabled:
> =E2=96=88 mike@smugmug:~$ time php -d raphf.persistent_handle.limit=3D0 -=
r 'for
> ($i=3D0;$i<20;++$i) {(new http\Client("curl","google"))->enqueue(new
> http\Client\Request("GET", "http://www.google.at/"))->send();}'
>
> 0.04s user 0.01s system 1% cpu 2.790 total

While I like the idea, I would not take it as it. Many things could affect
it and I am not sure the persistent resource is what spare times. Any
profiling info with delta?

--001a11c3bb8eae1872050e5aeb57--