Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81884
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54D33272.6050608@php.net>
Date: Thu, 05 Feb 2015 10:05:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>, 
 PHP Internals <internals@lists.php.net>
References: <DDA98D4F-2105-415A-B921-01A622091FA9@php.net> <54D217E7.8030407@php.net> <54D2AE91.8090800@gmail.com> <54D3271E.2080207@php.net> <54D32A38.9050004@gmail.com> <54D32D89.7010509@php.net> <54D32FA7.8040807@gmail.com>
In-Reply-To: <54D32FA7.8040807@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
From: mike@php.net (Michael Wallner)

On 05/02/15 09:53, Stanislav Malyshev wrote:
> Hi!
> 
>> Databases (see my pecl/pq example in the RFC), key/value stores, message
>> queues, whatever you can think of.
> 
> HTTP and databases are principally different. HTTP protocol is stateless
> message-oriented protocol, and database connection protocols have very
> little in common with HTTP.
> 
>> To demonstrate to ou how it would work out over multiple requests.
> 
> But this example doesn't demonstrate doing something that people
> actually would or should do. And it also doesn't demonstrate a need for
> persisting HTTP connections across requests. In fact, it may be harmful
> for HTTP servers if connections were not closed when the user is done
> with them but the server is forced to keep them open beyond the time
> needed to serve the actual client.
> 
>> Why do you think the connection should automatically be closed?
>> That's not the default case since HTTP/1.1, except the server is
>> explicitely configured to close each connection after serving.
> 
> If the client is done with the connection, it is natural to assume it is
> closed. If it's not, then client failing to finish the communication for
> some reason may leave connection in wrong state and the other client may
> unsuspectingly reuse it, leading to very weird results.
> 
>>>> █ mike@smugmug:~$ time php -d raphf.persistent_handle.limit=0 -r 'for
>>>> ($i=0;$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
>>>
>>> So, the difference is microscopic even here. But with proper HTTP
>>> handling - like batch requests or keepalive - it would be even less.
>>
>> Microscopic?! 50%?! Could you please elaborate? :)
> 
> Sorry, I looked at wrong number, there is a difference. But if you need
> to talk a lot to the same service, why not just use keepalive connection
> for all your requests? As I said, sharing connections between
> unsuspecting clients may lead to problems.
> 

Stas, we're talking in circles here :) Of course this is Keep-Alive.
Keep in mind that it's curl which is working under the hood, managing
alive connections for us. I just keep curl alive to take advantage of
that fact.

You can pass a persistent handle identifier (just a unique name) as
second argument to the constructor of http\Client, so you can group
related handles to max out that benefit.

-- 
Regards,
Mike