Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender)
Message-ID: <54D32FA7.8040807@gmail.com>
Date: Thu, 05 Feb 2015 00:53:59 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, 
 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>
In-Reply-To: <54D32D89.7010509@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
From: smalyshev@gmail.com (Stanislav Malyshev)

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 Malyshev
smalyshev@gmail.com