Question

I am developing a website that has some sort of realtime update.
Now the website is generated with a javascript variable of the current ID of the dataset.
Then in an interval of some seconsd an AJAX call is made passing on the current ID, and if theres something new the server returns it along with the latest ID which is then updated in the javascript.
Very simple, but here comes the Problem.

If the user opens the same page multiple times, every page does this AJAX requests which produces heavy serverload.

Now I thought about the following approach:

The website is loaded with a javascript variable of the current timestamp and ID of the current dataset.
My desired refresh interval is for example 3 seconds.

In the website an interval counter counts up every seconds, and everytime the timestamp reaches a state where (timestmap % 3===0) returns true, the content is updated.
The link looks like http://www.example.com/refresh.php?my-revision=123&timestamp=123456

Now this should ensure that every browser window calls the same URL.
Then I can turn on browser level caching.

But I don’t really like this solution.
I would prefer adding another layer of data sharing in a Cookie.
This shouldn’t be much of a problem, I can just store every request in a cookie named by timestamp and data revision with a TTL of 10 seconds or so and check for its exitence first.

BUT

The pages will do the request at the same time. So the whole logic of browser caching and cookie might not work because the requests occour simultanously and not one after another.

So I thought about limiting the current connections to 1 server side. But then I would need at least an extra vhost, because I really dont want to do that for the whole page.
And this lets me run into problems concerning cross-site policies!

Of course there are some super complicated load balancing solutions / server side solusions bound to request uri and ip adress or something but thats all extreme overkill!

It must be a common problem! Just think of facebook chat. I really don’t think they do all the requests in every window you have open…

Any ideas? I’m really stuck with this one!

Maby I can do some inter-window Javascript communication? Shouldnt be a problem if its all on the same domain?

A thing I can do of course is server side caching. Which avoids at least DB Connections and intensive calculations… but it still is an request which I would like to avoid.

Answer 1

The first thing is: Do server-side caching anyway, using Memcache or Redis or whatever. So you’re defended against three machines doing the requests. But you knew that.

I think you’re onto the right thing with cookies, frankly (but see below for a more modern option) — they are shared by all window instances, easily queried, etc. Your polling logic could look something like this:

On polling interval:

• Look at content cookie: Is it fresher than what you have? If so, use it and you’re done.
• Look at status cookie; is someone else actively polling (e.g., cookie is set and not stale)? If yes, come back in a second.
• Set status cookie: I’m actively polling at (now).
• Do request

On response:

• If the new data is newer than the (possibly updated) contents of the content cookie, set the content cookie to the new data
• Clear status cookie if you’re the one who set it

Basically, the status cookie acts as a semaphore indicating to all window instances that someone, somewhere is on the job of updating the content.

Your content cookie might contain the content directly, or if your content is large-ish and you’re worried about running into limits, you could have each page have a hidden iframe, each with a unique name, and have your Ajax update write the output to the iframe. The content cookie would publish the name of the most up-to-date iframe, and other windows seeing that there’s fresh content could use window.open to get at that iframe (since window.open doesn’t open a window if you use the name of an existing one).

Be alert to race conditions. Although JavaScript within any given page is single-threaded (barring the explicit use of web workers), you can’t expect that JavaScript in the other windows is necessarily running on the same thread (it is on some browsers, not on others — heck, on Chrome it’s not even the same process). I also don’t know that there’s any guarantee of atomicity in writing cookies, so you’ll want to be vigilant.

Now, HTML5 defines some useful inter-document communication mechanisms, and so you might consider looking to see if those exist and using them before falling back on this cookie approach, since they’ll work in modern browsers today but not in older browsers you’re probably having to deal with right now. Still, on the browsers that support it, great!

Web storage might also be an option worth investigating as an aspect of the above, but your clients will almost certainly have to give your app permissions and it’s also a fairly new thing.