Long Polling Options: Nginx, PHP, Node.js

Question

I'm designing a long-polling app to broadcast small changes very rapidly to, possibly, a large number of users. The app will run in tandem with a website running a fairly standard cms. They'll both be running on one server, and to begin with so will the database.

I come very much from a LAMP environment and I'm definitely a developer and not a sys-admin. That said I'm not afraid to try out some new things.

I've spent the day researching my options and I'm hoping people can answer some questions and give me some recommendations.

I have narrowed it down to these:

    A. Apache and php for the website, Node.js for the app
    B. Nginx and php for both the website and app
    C. Nginx and php for website, Nginx and Node.js for the app

So the questions:

1. How does Nginx handle PHP's non-multi-threadingness ;). Will PHP prove as much a bottleneck as Apache would have for long polling?
2. I've heard it suggested that I use nginx as a reverse proxy in front of Apache and Node.js, is that a better solution than just nginx? If so, why?
3. Which option have you used/would recommend?

Bear in mind that ease of set-up could be a factor, I'm fairly comfortable with Apache but I've only played with Node and I've never installed Nginx.

I'll happily provide clarifications if anyone needs them.

Marelda

This may be a question for webmasters.stackexchange.com... – Coinsure

I considered it... I guess it is more configuration based. – Marelda

Answer 1

I would use option C: and would suggest an option D:

option D:

• Keepalived with HAProxy for load balancing (LB)
• Nginx for static and PHP scripts, using PHP-FPM, APC and Redis for caching
• Node.js (and other Node modules) for dynamic, realtime content

We currently use the first 2 parts of option D, coming from a LAMP background, and are currently implementing Node.js to serve some of our (system taxing) realtime apps. HAProxy does exactly that: proxies the traffic to all my backend servers, instead of having Nginx doing it. Reason for that, we have many backend HTTP/TCP/other servers and we require redundant and automatic failover to these servers. LB is simple to implement and works well.

So far, excellent results. Personally, the Nodes learning curve has so far has been difficult due to lack of documentation, but there is a very dynamic community out there.

Hope this helps.

Salters

Answer 2

I, personally would use only Node.js. Instead of a long poll, you can push new information to all available clients. Node.JS is extremely fast when delivering realtime content and is capable of doing everything in one package. Also, the client side and server side is written in javascript making it easier to develop, debug, and deliver. As a developer you can see the benefits of this.

Here is an example of an app using Node.js and the modules express, jade and NowJS. Of course this can also be used as a combination with your CMS running on apache and Node.JS serving the dynamic content. with either Nginx or a node script acting as a reverse proxy in front of this script and Apache.

A simple chat application

Server.js

var express = require('express')
  , app = express.createServer()
  , nowjs = require('now')

/* configure express server */
//...

app.get('/', function(req, res){
  res.render('chat')
})

var everyone = nowjs.initialize(app)

// Server scoped function called by single client
everyone.now.distributeMsg = function(msg){
  // Client scoped function of every connected client
  this.now.receiveMsg(msg)
}

app.listen(3000)

chat.jade

!!!
html
  head
    script(type='text/javascript', src='/nowjs/now.js')
  body
    #log
    input#entry(type='text')
    input#submit(type='button')

script
  $(function(){
    $('#submit').click(function(){
      now.distributeMsg($('#entry').val())
    })

    now.receiveMsg = function(msg){
      $('#log').append('<div>' + msg + '</div>')
    }
  })

Yes, it REALLY is that simple and wouldn't take many more lines of code to turn this into a full featured chat application. In fact your markup and CSS would take more lines than the application code. Amazing!

Adabelle