Q:

Going from setTimeout AJAX call to Long Polling with timeout

I have created a site which auto refreshes a DIV every 15 seconds using a timeOut.
This works pretty solid, but it can take up to 5 minutes before the DIV is actually updated, which means the script will do the call 20 times before a change happens. Pretty good waste of costly bandwidth and server performance :)
I have been reading a lot about doing Long Polling instead and I've been giving it a go.
My AJAX call was:
intval = window.setTimeout(function() {
  $.ajax({
    type: 'GET',
    cache: false,
    url: 'url',
    beforeSend: function() { $('#timerimg').attr('src', 'img/icons/loading.gif'); },
    success: function(data) { $('#ajaxcontent').html(data); },
    complete: function() { $('#timerimg').attr('src', 'img/icons/stop.gif'); }
  });
}, 15000);

This function was placed inside the page being refreshed all the time, which made the timeout-function to being kept repeated.
Now I have tried to follow http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery to create a simple Long Polling function
(function poll() { 
  $.ajax({ 
    type: 'GET',
    cache: false,
    url: 'url',
    success: function(data) { $('#ajaxcontent').html(data); },
    complete: poll,
    timeout: 30000
  });
})();

If I am setting the url to hi.txt and making that write Hello World! then it finished constantly and doing a new poll. Which obviously means A LOT of simultaneous polls.
How do I correct this?
AND:
The autorefreshing DIV is a large chart with calculations from a huge SQL-Server query. So maybe it should just check if there has been the slightest change in the .getRows() (compared to the original) after the SQL query?
I am doing the whole thing in jQuery and ASP-Classic.

A:

Long polling is not a client only solution. Long polling requires the server to hold the call until something changes. This means that you will be using up one of your concurrent connections for EVERY client logged in. This can be a problem with some service providers that limit concurrency, so check your ISP policy before you get a 503.
Also you are addressing more than one issue here. The server should keep track of whether or not the last request needs to be updated, or to just send you back the cached response. If you are using long polling, then the server will hold your connection until it has changed.
Previously you were using interval polling. I would suggest continuing that route (with server side caching) instead of dedicating half of your IE bandwidth (2 concurrent max) for an infrequent update. Just have the server kick back a "false" response to your inquiry if things haven't changed.

