Will frequent polling overload the server? If so, what's the best way of implementing live updates?

Question

I don't know which is the most efficient way to do. I am seeking a better algorithm.

Let us take some example like Facebook when user posts a post, it will be updated to his friend without any page refresh and we know its by ajax request. But how can we know that some one has posted a new thing? may be like putting a timer for every 2 seconds and sending an ajax request for some table and checking if some user posted something. Right?

But is there a way to do without setting a timer because performing the operation for every 2 seconds may cause severe server issue I think so? Just want to know if there is a better way instead of setting a timer?

Answer 1

Long polling is a great technique but as with any solution the efficacy depends on many variables including hardware setup and hence there are no absolute solutions.

Please be aware that Long polling you are keeping the connection alive which may cause performance issues with many clients.

You solution should take into account :-

1. Does it need to be almost realtime (for example a stockticker)
2. How often the ajax data/output changes (chat vs new comment)
3. How often does the event that causes changes to ajax data/output triggers. This will dictate how the cache is generated.

You should be a frugal when it comes to ajax. Request & response should be done on a need basis. The success of a ajax implementation will be incomplete without a well thought out caching solution which is more event based rather than request based.

Below is a simplified version of one of the techniques we found useful in a project:-

1. Every Ajax poll request that is made will contain output_hash which is the digest of the data returned by the server previously.
2. Server checks this output_hash against the recent hash of the output it will have generated, from data source preferably stored in cache.
3. If it is different then it will serve the new content along with new output_hash. Else a small response / Not modified to indicate there is no new content.

In our solution we also did dynamic calculation of the interval of the next poll. Keeping the interval dynamic allows the server to control the request. For example let's assume most comments / answers happen in the first 1 hour, beyond that there is no point having the interval time as 1 sec, so the server can increase that to 2,3 or even 5 sec dynamically as the time increases, rather than hard coding the interval as 2 sec. Similarly the interval time can be decreased if there is flurry of activity in an old post.

We also checked for idle clients and other things.

Answer 2

Currently what Facebook and Google employ, is a technique called long polling.

It's a simple system whereby the client makes an AJAX request to the server. The server takes the request and checks to see if it has the data the request needs. If not, the request is left open but deferred by the server. The second the server has the data, the request is handled and returned to the client.

If you open up facebook, you'll see requests being posted to Facebook which take around 55 seconds to complete. Same goes for Gmail and a few other web applications that seem to have some kind of push system.

Here's a simple example of how these requests might be handled:

1. Client:

   • Initial AJAX request which has the timestamp 0

2. Server:

   • Compare request with timestamp 0 by checking the timestamp of the data on the server. Lets say the data on the server has the timestamp 234.
   • The client stamp is different from the current stamp on the server data so we return with the new data.

3. Client:

   • Client gets the data and immediately posts a new AJAX request with timestamp 234.
   • Then we process the new data and update the web page appropriately.

4. Server:

   • Compares request with timestamp 234 with the current stamp of the data on the server.
   • The stamp values are the same so we go to sleep.
   • Server data is update and stamp value is now timestamp 235.
   • Sleeping requests are woken up and returned with update value.

You can read a more in-depth explanation of more modern mechanisms for live updates.

Answer 3

Just my two cents but I have previously solved a similar problem by having 2 webservices. Basically one with a method along the lines of HaveNewData() and another GetData() (In my case I had a number of webservices I wanted to call).

So basically call HaveNewData() on a regular basis (I think in any case every 2 seconds is a bad design and unnecessary) and return a simple 0 or 1 for this method (minimal data). If HaveNewData() returns 1 then make your expensive webservice call. Alternatively you could also just return a null value in the primary webservice when no new data is available and in my experience this scales at least "pretty" reasonably.