1

I have a web application which provides a dashboard-type display to users on our local network. It gives status updates on a number of different processes and systems via AJAX polling of the server. We're getting to the point where the load on the server is getting to be too much (it's old hardware with insufficient memory). We will be upgrading within the next couple of months, but I'm considering switching from polling the server to websockets and pushing events to the clients.

Given that the number of requests to the server is going to be drastically reduced, since the server will be pushing notifications to the clients, I think the server load should be reduced. Is this correct?

Edit

The application is written in PHP using the Laravel framework and is running on a set of Docker containers with Apache as the web server using the ratchet library to implement the server side of the websockets. Changing from PHP to another implementation like node is not practical, but changing web servers is possible.

Kryten
  • 15,230
  • 6
  • 45
  • 68
  • Tell us more about your stack, and in particular what server-side tech will be supplying that half of the websockets implementation. – T.J. Crowder May 26 '15 at 22:24
  • Take a look at http://stackoverflow.com/questions/10028770/html5-websocket-vs-long-polling-vs-ajax-vs-webrtc-vs-server-sent-events, might be worth the read – lhoworko May 26 '15 at 22:24
  • ajax is often used with php, sockets with node.js. if you replace php with node.js, your cpu use will go down, but none of your code will work... its not a fair comparison. if you compare node.js ajax to node.js websockets, sockets can reserve more ram, but ajax uses more cpu and ram spikes. – dandavis May 26 '15 at 23:00

1 Answers1

2

I've implemented a number of push (websocket) and polling mechanisms (HTTP), in my experience if there are multiple client machines all continuously polling the server for status updates and you switch that around so that the server instead fires a status update out to each client when one occurs there are a number of potential benefits:

  1. Data is only sent out to the client on an initial connection and subsequently when updates occur (so less often). No requests to check for updates that haven't happened.
  2. The server only has to perform the work to generate a response when a new client connects or on a subsequent update (though caching could also resolve this problem).
  3. In my experience writing websocket and HTTP APIs, websocket is more efficient as there's no overhead for connecting and authorizing each request, only the first connection has that overhead, after that data can be sent over the same connection (both directions) without the need to connect and re-authorize the client (e.g key, username & password - if that's a requirement).

Make sure you're using a web sever that is designed to handle websocket (long connections in general), my experience is with Tornado which is non-blocking and well suited but many web servers do or can be configured to.

Chances are that there's a solution that will work if you stick with polling too (e.g caching the status of the dashboard each time it's updated so that the request simply calls a static file). But in answer to your question - yes I believe based on the description you've provided, that the approach you're considering would reduce the overhead, potentially dramatically depending on how CPU intensive the currently polled views are.

Anthony Blackshaw
  • 2,549
  • 2
  • 16
  • 20
  • Thanks very much for you comments. They've helped me understand this problem more completely. – Kryten May 28 '15 at 14:47