Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hristov.com from 91.196.125.214 cause and error)
Message-ID: <551AB705.5040001@hristov.com>
Date: Tue, 31 Mar 2015 18:02:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAH8MpnknSgzZEpsgqwfNMq5h8C5eM5RVREjvLwCA5YxLhMKc6Q@mail.gmail.com> <551AAB20.6060100@luni.fr> <CAH8MpnnxmD5+cd1jmndBTV7XA5TQTseXVE-p-D0tsqMh7=ZfDw@mail.gmail.com>
In-Reply-To: <CAH8MpnnxmD5+cd1jmndBTV7XA5TQTseXVE-p-D0tsqMh7=ZfDw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: HTTP/2 and Websocket support in 7.x versions
From: php@hristov.com (Andrey Hristov)

  Hi,
On 31.03.2015 17:40, Daniel Lowrey wrote:
> On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat <gregory@luni.fr> wrote:
>
>> Le 31/03/2015 15:56, Daniel Lowrey a écrit :
>>> HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
>>> exists. The protocol impacts the actual HTTP server and has nothing to do
>>> with the SAPI runtime which is simply handed information about the HTTP
>>> request once the server parses it. The protocol used to communicate those
>>> details between the client and the HTTP server does not concern the web
>>> SAPI. There is no need for any sort of "support for h2" in PHP; it's the
>>> web server's concern. Apache and nginx will add support for h2 and PHP
>> will
>>> continue working as it always has.
>>>
>>> That said, the php web SAPI derives exceedingly little benefit from the
>>> advent of HTTP/2.0. h2 is designed to allow multiplexing of many requests
>>> over the same TCP connection but the PHP web SAPI still has the same
>>> bottleneck it had before h2: one thread/process per request.
>>>
>>> As for websockets, you *can* do that using the web SAPI right now if you
>>> wished but this would be inadvisable because long-lived connections will
>>> quickly fill the bottleneck in every PHP web application (concurrent
>>> threads/processes for each "request").
>>>
>>> Instead, the appropriate solution for websockets would be to implement a
>>> socket server directly in the CLI that speaks the websocket protocol.
>>>
>>> Would it be useful to have raw incremental parsing functionality for
>>> HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure,
>> but
>>> this falls more in the realm of an extension than anything else as few
>>> people are implementing full-blown http and websocket servers in the CLI
>>> right now.
>>>
>>
>> Hi Daniel,
>>
>> Your message is focusing on the solution I can find today in the wild,
>> not about the need mys previous message was about, namely multiplexing
>> and message push.
>>
>> Anyway I'm aware of this and I understand your point, but why should'nt
>> we be able, natively, to exploit HTTP/2 enhancements, particurlarly
>> resources multiplexing and data push?
>>
>> Why woud we restrain to exploit 20 years old protocol features,
>> deliberately omitting new ones that are already implemented on other
>> platforms?
>>
>> Grégory
>>
>
> You're right -- I was addressing the status quo.
>
> The issue here is this: the web SAPI is historically the most stable thing
> about PHP. Supporting things like message push and multiplexing would
> require a fundamental change in what the web SAPI is. You would have to
> junk the entire model and create something completely new. It wouldn't be
> PHP anymore because you couldn't use the thread/process per-request model;
> users could no longer rely on the ease and simplicity of every function
> call being a simple synchronous operation.

this ain't exactly true. Currently in MT environment the task of data 
separation is pushed to the TSRM by using TLS. Now, if TSRM is 
reimplemented in a fashion that the data is not stored by using TLS but 
other mechanism and cooperative multitasking is not something that can't 
be done. The truth is that userland is isolated from the process data 
space so for it it won't make a difference. It's just that using threads 
for separation is the easiest thing (after process per script).
The good thing is that TSRM is an abstraction for its clients.
>
> This kind of major paradigm shift is something that couldn't remotely be
> considered for PHP7. Even if it were possible you have to consider the web
> SAPI's target demographic. This demographic knows nothing about
> non-blocking IO and multitasking.
>
> I used to be a proponent of integrating things like this directly into the
> core of PHP. However I no longer consider this to be a good idea. Why?
> Because all of the functionality needed to implement these things yourself
> is available in extensions *right now.* I've personally worked on a
> closed-source userland non-blocking HTTP+websocket server over the last
> couple of years that clears 80,000 requests per second with 10,000
> simultaneous clients running PHP7 on a single box with an i2600K cpu.
>
> Instead of massively changing the fundamental nature of the PHP web SAPI I
> believe we should focus on improving PHP as a language and not a web
> framework. By doing so we make it increasingly possible to implement things
> like this directly in userland with good performance. This can be
> accomplished right now by simply focusing on extension development (like
> php-uv which you mentioned and I've contributed to myself).
>
> Would I personally prefer to re-implement everything in PHP on top of libuv
> and bake non-blocking and threaded concurrency directly into the language
> with async functions and promises? Absolutely. But you're talking about a
> massive amount of work here. In standard internet parlance ... ain't no one
> got time for that.
>

Best,
Andrey