Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82023
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54D47379.8030409@php.net>
Date: Fri, 06 Feb 2015 08:55:37 +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>, 
 Pierre Joye <pierre.php@gmail.com>
CC: 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> <CAEZPtU65NirGfES1qiic45Ui3qY45X+k370o2BSj3kbwLendjg@mail.gmail.com> <54D3CE01.4070903@php.net> <54D3D26A.6050405@gmail.com> <54D3D51C.8070108@php.net> <54D3D6A4.3020908@gmail.com>
In-Reply-To: <54D3D6A4.3020908@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
From: mike@php.net (Michael Wallner)

Hi Stas!

On 05/02/15 21:46, Stanislav Malyshev wrote:
> Hi!
> 
>> Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly
>> that? Let me know, if you wanted something else to be compared.
> 
> I wanted to know why we need persistent resources. You brought comparing
> persistent resources to reopening connection each time as an argument
> that we need persistent resources. This, however, is not a good argument
> for persistent resources, as the same performance improvement (or nearly
> the same, discounting the closing/opening between requests - which may
> be necessary anyway, see below) can be achieved without having
> persistent resources, just by implementing HTTP keepalive within the
> same connection object. It would also make it clearer who owns the
> connection and in which state it is, right now I'm not sure what exactly
> ensures the client can not end up with somebody else's connection in an
> unclean state.
> 

Are you saying performance is not the reason we use persistent handles?
Stas, I really don't understand what's the issue here for you.

Youself said that HTTP is a stateless protocol, so how would a
connection in an "unclean state" look like in your opinion?

There are just two states, alive and closed. I'm also not sure who that
"somebody else" might be, whose connection I'm about to re-use?

Curl caches connections the servers are fine with keeping alive, and I
cache curl handles grouped by the id you pass to the client constructor
and the authority of the url, that's all, nothing spooky.


-- 
Regards,
Mike