6

I have a web application that relies on very "live" data - so it needs an update every 1 second if something has changed.

I was wondering what the pros and cons of the following solutions are.

Solution 1 - Poll A Lot

So every 1 second, I send a request to the server and get back some data. Once I have the data, I wait for 1 second before doing it all again. I would detect client-side if the state had changed and take action appropriately.

Solution 2 - Block A Lot

So I start a request to the server that will time-out after 30 seconds. The server keeps an eye on the data on the server by checking it once per second. If the server notices the data has changed it sends the data back to the client, which takes action appropriately.

Scenario

Essentially, the data is reasonably small in size, but changes at random intervals based on live events. The thing is, the web UI will be running something in the region of 2,000 instances, so do I have 2,000 requests per second coming from the UI or do I have 2,000 long-running requests that take up to 30 seconds?

Help and advice would be much appreciated, especially if you have worked with AJAX requests under similar volumes.

Fenton
  • 241,084
  • 71
  • 387
  • 401
  • 2
    It strongly depends on kind of data and requests. Probably you can create (and update) static json files and request them. Since they are static - they can be served by some good webserver (like nginx) very fast. – zerkms May 07 '11 at 14:11
  • Real interesting question +1. – Pete Wilson May 07 '11 at 14:16
  • @zerkms - I'm interested, can you expand in an answer? @Pete Wilson - thanks - I'm working on a web-browser based real-telephony system, which is really cool as it presents the kind of problems you just don't get in most apps you write. – Fenton May 08 '11 at 18:18

3 Answers3

2

Consider a better architecture. Implementing this kind of messaging system is trivial to do right in something like nodeJS. Message dispatch will be instantaneous, and you won't need to poll for your data on either side.

You don't need to rewrite your whole system: The data producer could simply POST the updates to the nodeJS server instead of writing them to a file, and as a bonus, you don't even need to waste time on disk IO.

If you started without knowing any nodeJS, you could still be done in a couple hours, because you can just hack up the chat example.

geocar
  • 9,085
  • 1
  • 29
  • 37
2

One common solution for such cases is to use static json files. Server-side scripts update them when the data is changed and they are served by fast and light webserver (like nginx). Since files are static and small - webserver will do that right in cache, in very fast manner.

zerkms
  • 249,484
  • 69
  • 436
  • 539
  • This sounds like a good idea - is it likely you will get contention while writing the file (i.e. we service 1000s of client machines, so we would write this file once every 2 seconds, would this cause a problem if the clients tried to GET the file while we were updating it)? – Fenton May 09 '11 at 12:50
  • @Sohnee: don't update that file then. Create temporary file and perform `mv` (which is instant). – zerkms May 09 '11 at 13:12
0

I can't comment yet, but I would agree with geocar. Running live or almost live web services with just polling will be solution stuck between a rock and a hard place.

You could also look into web sockets to allow push as this sounds a better solution for this than just updating every second to 30 seconds.

Good luck!

al3xnull
  • 866
  • 1
  • 13
  • 29