what's the skinny on long polling with ajax and webapi…is it going to kill my server? and string comparisons

Question

I have a very simple long polling ajax call like this:

(function poll(){
    $.ajax({ url: \"myserver\", success: function(data){
        //do my stuff here

            


        

Answer 1

I agreee with SLaks - i.e. use SignalR if you need realtime web with WebApi http://www.asp.net/signalr. Long polling is difficult to implement well, let someone else handle that complexity i.e. use SignalR (natural choice for WebApi) or Comet.

SignalR attempts 3 other forms of communication before resorting to long polling, web sockets, server sent events and forever frame (here).

In some circumstances you may be better of with simple polling i.e. a hit every second or so to update... take a look at this article. But here is a quote:

when you have a high message volume, long-polling does not provide any substantial performance improvements over traditional polling. In fact, it could be worse, because the long-polling might spin out of control into an unthrottled, continuous loop of immediate polls.

The fear is that with any significant load on your web page your 30 second ajax query could end up being your own denial of service attack.

Even Bayeux (CometD) will resort to simple polling if the load gets too much:

Increased server load and resource starvation are addressed by using the reconnect and interval advice fields to throttle clients, which in the worst-case degenerate to traditional polling behaviour.

As for the second part of you question.

If you are using long polling then your server should ideally only be returning an update if something actually has changed thus your UI should probably "trust" the response and assume that a response means new data. The same goes for any of the Server Push type approaches.

If you did move back down towards simple polling pullmethod then you can use the inbuilt http methods for detecting an update using the If-Modified-Since header which would allow you to return a 304 Not Modified, so the server would check the timestamp of an object and only return a 200 with an object if it had been modified since the last request.