What is the best technology for a chat/shoutbox system? Plain JS, JQuery, Websockets, or other?

Question

I have an old site running, which also has a chat system, which always used to work fine. But recently I picked up the project again and started improving and the user base has been increasing a lot. (running on a VPS)

Now this shoutbox I have (running at http://businessgame.be/shoutbox ) has been getting issues lately, when there are over 30 people online at the same time, it starts to really slow down the entire site.

This shoutbox system was written years ago by the old me (which ironically was the young me) who was way too much into old school Plain Old JavaScript (POJS?) and refused to use frameworks like JQuery.

What I do is I poll every 3 seconds with AJAX if there are new messages, and if YES, load all those messages (which are handed as an XML file which is then parsed by the JS code into HTML blocks which are added to the shoutbox content.

Simplified the script is like this:

The AJAX functions

   function createRequestObject() {
    var xmlhttp;

    if (window.XMLHttpRequest) { // code for IE7+, Firefox, Chrome, Opera, Safari
        xmlhttp = new XMLHttpRequest();
    } else { // code for IE6, IE5
        xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    }

    // Create the object
    return xmlhttp;
}

function getXMLObject(XMLUrl, onComplete, onFail) {
    var XMLhttp = createRequestObject();

    // Check to see if the latest shout time has been initialized
    if(typeof getXMLObject.counter == "undefined") {
        getXMLObject.counter = 0;
    }

    getXMLObject.counter++;

    XMLhttp.onreadystatechange = function() {
        if(XMLhttp.readyState == 4) {
            if(XMLhttp.status == 200) {
                if(onComplete) {
                    onComplete(XMLhttp.responseXML);
                }
            } else {
                if(onFail) {
                    onFail();
                }
            }
        }
    };

    XMLhttp.open("GET", XMLUrl, true);
    XMLhttp.send();
    setTimeout(function() {
        if(typeof XMLhttp != "undefined" && XMLhttp.readyState != 4) {
            XMLhttp.abort();

            if(onFail) {
                onFail();
            }
        }
    }, 5000);
}

Chat functions

function initShoutBox() {
    // Check for new shouts every 2 seconds
    shoutBoxInterval = setInterval("shoutBoxUpdate()", 3000);
}

function shoutBoxUpdate() {
            // Get the XML document
            getXMLObject("/ajax/shoutbox/shoutbox.xml?time=" + shoutBoxAppend.lastShoutTime, shoutBoxAppend);
    }

function shoutBoxAppend(xmlData) {
   process all the XML and add it to the content, also remember the timestamp of the newest shout
}

The real script is far more convoluted, with slower loading times when the page is blurred and keeping track of AJAX calls to avoid double calls at the same time, ability to post a shout, load settings etc. All not very relevant here.

For those interested, full codes here: http://businessgame.be/javascripts/xml.js http://businessgame.be/javascripts/shout.js

Example of the XML file containing the shout data http://businessgame.be/ajax/shoutbox/shoutbox.xml?time=0

I do the same for getting a list of the online users every 30 seconds and checking for new private messages every 2 minutes.

My main question is, since this old school JS is slowing down my site, will changing the code to JQuery increase the performance and fix this issue? Or should I choose to go for an other technology alltogether like nodeJS, websockets or something else? Or maybe I am overlooking a fundamental bug in this old code?

Rewriting an entire chat and private messages system (which use the same backend) requires a lot of effort so I'd like to do this right from the start, not rewriting the whole thing in JQuery, just to figure out it doesn't solve the issue at hand.

Having 30 people online in the chatbox at the same time is not really an exception anymore so it should be a rigid system.

Could perhaps changing from XML data files to JSON increase performance as well?

PS: Backend is PHP MySQL

Answer 1

I'm biased, as I love Ruby and I prefer using Plain JS over JQuery and other frameworks.

I believe you're wasting a lot of resources by using AJAX and should move to websockets for your use-case.

30 users is not much... When using websockets, I would assume a single server process should be able to serve thousands of simultaneous updates per second.

The main reason for this is that websockets are persistent (no authentication happening with every request) and broadcasting to a multitude of connections will use the same amount of database queries as a single AJAX update.

In your case, instead of everyone reading the whole XML every time, a POST event will only broadcast the latest (posted) shout (not the whole XML), and store it in the XML for persistent storage (used for new visitors).

Also, you don't need all the authentication and requests that end up being answered with a "No, there aren't any pending updates".

Minimizing the database requests (XML reads) should prove to be a huge benefit when moving from AJAX to websockets.

Another benifit relates to the fact that enough simultaneous users will make AJAX polling behave the same as a DoS attack.

Right now, 30 users == 10 requests per second. This isn't much, but it can be heavy if each request would take more than 100ms - meaning, that the server answers less requests than it receives.

The home page for the Plezi Ruby Websocket Framework has this short example for a shout box (I'm Plezi's author, I'm biased):

# finish with `exit` if running within `irb`
require 'plezi'
class ChatServer
    def index
        render :client
    end
    def on_open
        return close unless params[:id] # authentication demo
        broadcast :print,
                "#{params[:id]} joind the chat."
        print "Welcome, #{params[:id]}!"
    end
    def on_close
        broadcast :print,
                "#{params[:id]} left the chat."
    end
    def on_message data
        self.class.broadcast :print,
                    "#{params[:id]}: #{data}"
    end
    protected
    def print data
        write ::ERB::Util.html_escape(data)
    end
end
path_to_client = File.expand_path( File.dirname(__FILE__) )
host templates: path_to_client
route '/', ChatServer 

The POJS client looks like so (the DOM update and from data access ( $('#text')[0].value ) use JQuery):

    ws = NaN
    handle = ''
    function onsubmit(e) {
        e.preventDefault();
        if($('#text')[0].value == '') {return false}
        if(ws && ws.readyState == 1) {
            ws.send($('#text')[0].value);
            $('#text')[0].value = '';
        } else {
            handle = $('#text')[0].value
            var url = (window.location.protocol.match(/https/) ? 'wss' : 'ws') +
                        '://' + window.document.location.host +
                        '/' + $('#text')[0].value
            ws = new WebSocket(url)
            ws.onopen = function(e) {
                output("<b>Connected :-)</b>");
                $('#text')[0].value = '';
                $('#text')[0].placeholder = 'your message';
            }
            ws.onclose = function(e) {
                output("<b>Disonnected :-/</b>")
                $('#text')[0].value = '';
                $('#text')[0].placeholder = 'nickname';
                $('#text')[0].value = handle
            }
            ws.onmessage = function(e) {
                output(e.data);
            }
        }
        return false;
    }
    function output(data) {
        $('#output').append("<li>" + data + "</li>")
        $('#output').animate({ scrollTop:
                    $('#output')[0].scrollHeight }, "slow");
    }

If you want to add more events or data, you can consider using Plezi's auto-dispatch feature , that also provides you with an easy to use lightweight Javascript client with an AJAJ (AJAX + JSON) fallback.

...

But, depending on your server's architecture and whether you mind using heavier frameworks or not, you can use the more common socket.io (although it starts with AJAX and only moves to websockets after a warmup period).

EDIT

Changing from XML to JSON will still require parsing. The question is actually whether XML vs. JSON parsing speeds.

JSON will be faster on the client javascript , according to the following SO question and answer: Is parsing JSON faster than parsing XML

JSON seems to be also favored on the server-side for PHP (might be opinion based rather than tested): PHP: is JSON or XML parser faster?

BUT... I really think your bottleneck isn't the JSON or the XML. I believe the bottleneck relates to the multitude of times that the data is accessed, (parsed?) and reviewed by the server when using AJAX .

EDIT2 (due to comment about PHP vs. node.js)

You can add a PHP websocket layer using Ratchet... Although PHP wasn't designed for long running processes, so I would consider adding a websocket dedicated stack (using a local proxy to route websocket connections to a different application).

I love Ruby since it allows you to quickly and easily code a solution. Node.js is also commonly used as a dedicated websocket stack.

I would personally avoid socket.io, because it abstracts the connection method (AJAX vs Websockets) and always starts as AJAX before "warming up" to an "upgrade" (websockets)... Also, socket.io uses long-polling when not using websockets, which I this is terrible. I'd rather show a message telling the client to upgrade their browser.

Jonny Whatshisface pointed out that using a node.js solution he reached a limit of ~50K concurrent users (which could be related to the local proxy's connection limit). Using a C solution, he states to have no issues with more than 200K concurrent users.

This obviously depends also on the number of updates per second and on whether you're broadcasting the data or sending it to specific clients... If you're sending 2 updates per user per second for 200K users, that's 400K updates. However, updating all the users only once every 2 seconds, that's 100K updates per second. So trying to figure out the maximum load can be a headache.

Personally, I didn't get to reach these numbers on my apps, so I never got to discover Plezi's limits first hand... although, during testing, I had no issues with sending hundred of thousands of updates per second (but I did had a connection limit due to available ports and open file handle limits on my local machine).

This definitely shows how vast of an improvement you can reach by utilizing websockets (especially since you stated to notice slowdowns with 30 concurrent users).