Hi,
On 31.03.2015 17:40, Daniel Lowrey wrote:
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat <greg...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
