[wp-hackers] GSoC 2014: WebSockets in WordPress

[Bryan Petty]

On Tue, Mar 18, 2014 at 11:50 AM, Atanas Penchev <atanaspich at gmail.com> wrote:
> Besides the use of WebSockets, I am also thinking of using the React server
> for serving request, which could provide a significant performance boost,
> as mentioned in this post:
> http://marcjschmidt.de/blog/2014/02/08/php-high-performance.html

That article is pretty nice, and even points out some of the downsides
and technical issues involved, which are also very critical to
WordPress as well, so let me just briefly cover them to the best of my
knowledge.

1. While Symfony contains a Request/Response system that he talks
about in that article, in WordPress, it's much worse. A bunch of core
functions and plugins directly access superglobals for $_REQUEST and
$_SERVER values. As pointed out, those are entirely unreliable in the
environment of asynchronous requests.
2. Also a problem for asynchronous requests: hooks. These are bound by
global context, meaning hooks would have no idea what request/client
was being served, which DB resource to use (what if we were in a
transaction?), or what output stream to echo out to. ReactPHP was
built with MVC architectures and template engines in mind - neither of
which we use. And as far as backwards compatibility goes, there's
likely nothing we can do to handle any of those while staying
compatible with existing plugins.

So, even if we managed to work our way around blocking IO calls (PDO,
DNS, etc), this means that we still can't use async requests. It's
best to just forget about it (especially for GSoC). That doesn't mean
we can't still use WebSockets or React, it just means that we can't
use async/promise. Of course, this defeats most of the performance
gains React likes to gloat about, but it would still cut back on PHP
initialization.

Unfortunately, without async, this introduces another problem. It
means we will be performing blocking calls (which was likely going to
happen anyway with PDO). And since we'll be blocking, we won't want
one user blocking requests from another user, so we would likely want
to avoid re-using connections across sessions. We probably already
want to anyway since authorization checks also rely on request/session
identity stored in global values. This is a difficult task which I'm
not sure has a solution with a fixed server pool configuration. It's
not going to scale with 50+ concurrent admin users (including authors
writing posts) leaving heartbeat WebSockets open to individual PHP
processes on different ports.

Maybe I'm wrong about some of this, and hopefully someone else on the
list can correct me or point out other solutions I'm not aware of to
these problems. But this is all probably worth some discussion before
any students jump head-first into this for GSoC.

Regards,
Bryan Petty