Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Daniel Lowrey <rdlowrey@php.net>
Message-ID: <551AD4BE.8010108@luni.fr>
Date: Tue, 31 Mar 2015 19:09:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
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: HTTP/2 and Websocket support in 7.x versions
From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=)

Le 31/03/2015 16:40, Daniel Lowrey a écrit :
> 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 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'm not saying that we should drop the current web SAPIs to the ground, 
I'm just advancing the idea of enhancing it or find some other way - in 
parallel of existing SAPIs - to bring these functionalities, maybe a 
specific SAPI.

CLI SAPI is already using an unique RINIT/RSHUTDOWN cycle, programs such 
as ReactPHP or the one I built with php-uv -and probably the one you 
mentioned building yourself- suffers from brutal crashes on fatal errors 
and does not take benefit from the request isolation. These issues will 
be indirectly and partially addessed with the ZE now sending exceptions 
instead of E_ERROR.

Now, about asynchronous operations, PHP developers are also often 
Javascript developers, may it be front end or back end on Node. Lots of 
them are used to asynchronous calls, others will simply learn to be used 
to it or continue to use the current synchronous functionalities and 
SAPIs, I see this as an opt-in.

Lots of PHP developers don't know what is a process or a thread and 
doesn't feel the need to dig the subject and I'm perfectly ok with that, 
each project finds his own needs and solutions. That said, then why 
should concerned developers suffer from missing functionalities?

> 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.

Is this server running with php-uv?

The issue here is that there is no simple and uniform way to implement 
it. Agree with me or not, it is clearly reserved to a small part of 
seasoned PHP developers, used to concurrent programming, extension 
writing/compilation and asynchronous development.

It is a border-line way of developing with PHP, not portable at all as 
long as php-uv isn't available anywhere but on your own dedicated server 
(if your SysOP even accepts to install a considered self-maintained and 
possibly vulnerable extension).

> 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).

I'm just bringing some ideas here, as long as I'm not a php-src 
developer. I know some notions but I don't have the distance required to 
find -by myself- the best solutions.

Yes php-uv is a great tool, but still incomplete (and IMO missing an OOP 
API).

> 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.

I can't tell if the existing stream API can integrate libuv I/O 
handling, especially async ones. I figured out that it was nearly 
impossible to integrate php-uv in an userland streamWrapper.



Now, that said and to come back to the main subject, HTTP/2 is coming 
*now* in production on large scale websites and will be present in a 
large amount of web traffic in the next couple of years. PHP can't 
afford to miss the boat or to force each developer reimplement his own 
protocol layer.

Possible solutions would be :

1. About multiplexing :
   1.a. integrate php-uv in the core in its current form and let 
developers implement their own protocol layer
   1.b. transform some project like ReactPHP into an extension (using 
Zephir and/or native C)
   1.c. create a new SAPI or extend an existing one, which woud offer 
the possibility of manipulating the resource multiplexing queue. PHP 
would still be in the Apache2/CGI stack, but would notify the server to 
send a resource list

2. About push: same as 1.a. and 1.b.

Grégory