Page MenuHomePhabricator

Evaluate PHP alternatives to NodeJS for Aphlict
Closed, WontfixPublic


After D11143, we could possibly rewrite the Aphlict server in PHP. This would remove the current NodeJS dependency.

Event Timeline

joshuaspence raised the priority of this task from to Normal.
joshuaspence updated the task description. (Show Details)
joshuaspence added a subscriber: joshuaspence.

I think we need to compare the upsides/downsides to this, for example, memory-wise, which can handle more connections concurrently on the same amount of ram, from what I understand, this is where NodeJS excels (using less ram for more connections), (I may be wrong)

There's also a WebSocket framework called Ratchet, which is built upon React. I used it for some small apps in the past and it worked quite well for me.

This task is about removing an external dependency (for security and simplicity), not really swapping one for another.

Okay, that sounds reasonable.

I'd really like to see this happen. So far I haven't used Aphlict simply because I don't want to manage the extra dependency.

epriestley renamed this task from Remove NodeJS dependency to Evaluate PHP alternatives to NodeJS for Aphlict.Nov 30 2015, 1:46 PM
epriestley removed a subscriber: cburroughs.
epriestley added a subscriber: cburroughs.

This is very unlikely to happen.

I selected NodeJS for scalability, effectively as the only selection concern.

I believe the maintenance burden this dependency represents is very small, based on my experience administrating this install and the Phacility cluster. Because I have operational responsibilities in the cluster I am strongly motivated to reduce the administrative cost of Phabricator, and removing the Node dependency isn't even on my radar. (It has basically run untouched since we launched, except for one reboot to swap an expired SSL certificate.)

I also think this dependency is less important to reduce setup costs on because it's optional and only enhances Phabricator. Installs can get set up without it, and pursue it later. You can configure it against an active install without any real disruption or risk.

I would be compelled to consider revisions to this approach if I were given evidence that:

  1. PHP can scale about as well as Node in this role (as a server handling many concurrent connections); or
  2. managing Node is unreasonably burdensome, and the burdens are of a nature which we can only really alleviate by dropping the Node dependency.

My belief is that PHP can not scale meaningfully in this role and is at least 2-3 orders of magnitude behind Node, and possibly so far behind Node that it is not suitable for anything but a toy server. Even if PHP can handle this task reasonably well for midsized installs on a single host, I don't want two servers, and I'd obviously rather have the one that works at scale. But perhaps I have bought into the hype too much and Node and PHP are approximately comparable here. I'd consider a PHP alternative if it is no more than 4x worse than Node in terms of handling large volumes of connections and traffic.

From experience, I believe Node is very easy to manage as a dependency. I have no direct evidence to the contrary.

I don't want to shipping two servers (an "easy" PHP server and a "scalable" Node server), particularly given that I believe Node is also easy. Getting notifications running isn't, at least currently, important enough to justify the costs of doing this.

I don't want to swap Node for another different external dependency unless that dependency is dramatically better on some dimension and no worse on any major dimension. I believe no such alternative exists (which is why I selected Node).

On ReactPHP specifically:

Here's something-like-a-benchmark I found suggesting that ReactPHP is much slower than Node, presumably even with the React extension installed (so this would swap a Node dependency for a PHP extension dependency -- I believe the PHP extension likely represents a greater burden for administrators):

The most important metric for Aphlict is probably "maximum active simultaneous connections". It's possible that the gap here is less severe than HTTP-like open-request-close I/O thoroughput rates.

Note that ReactPHP's authors do not consider ReactPHP to be an alternative to NodeJS ,at least as of last year:

(See slides 33-34: "Is React PHP a NodeJS Challenger? NO".)

React is also enormous, requires Composer, and requires a newer version of PHP than the minimum we support.

If you want to move this forward:

  • provide evidence that a small, pure PHP server can scale about as well at this task as Node; and/or
  • provide evidence that Node is unreasonably burdensome to set up or manage, in ways that we can't fix without swapping it for something else.

To clarify: I certainly don't this dependency to be simply swapped for another dependency. Also having 2 server implementations isn't desirable either. I can't judge whether a PHP implementation can challenge the NodeJS implementation because I'm lacking the experience in PHP.

eadler added a project: Restricted Project.Jan 9 2016, 12:49 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
epriestley claimed this task.

To the best of my current knowledge, there are no actual problems with the Node server (empirically, it is easy to install and maintain, stable, and works well) and no viable pure PHP alternatives anyway, so I have currently have no plans to ever pursue this. See above for a description of the type of new information which could affect these plans.

eadler removed a project: Restricted Project.Feb 18 2016, 12:25 AM