Question

I asked a question a while back on here regarding caching data for a calendar/scheduling web app, and got some good responses. However, I have now decided to change my approach and stat caching the data in javascript.

I am directly caching the HTML for each day’s column in the calendar grid inside the $(‘body’).data() object, which gives very fast page load times (almost unnoticable).

However, problems start to arise when the user requests data that is not yet in the cache. This data is created by the server using an ajax call, so it’s asynchronous, and takes about 0.2s per week’s data.

My current approach is simply to block for 0.5s when the user requests information from the server, and cache 4 weeks either side in the inital page load (and 1 extra week per page change request), however I doubt this is the optimal method.

Does anyone have a suggestion as to how to improve the situation?

To summarise:

• Each week takes 0.2s to retrieve from the server, asynchronously.
• Performance must be as close to real-time as possible. (however the data is not needed to be fully real-time: most appointments are added by the user and so we can re-cache after this)
• Currently 4 weeks are cached on either side of the inial week loaded: this is not enough.
• to cache 1 year takes ~ 21s, this is too slow for an initial load.

Answer 1

As I read your description, I thought of 2 things: Asynchrony and Caching.

First, Asynchrony

Why would you block for 0.5s? Why not use an ajax call, and in the callback, update the page with the retrieved info. There is no blocking for a set time, it is done asynchronously. You’d have to suppress multiple clicks though, while a request is outstanding, but that shouldn’t be a problem at all.

You can also pre-load the in-page cache in the background, using setInterval or better, setTimeout. Especially makes sense if the cost to compute or generate the calendar is long and the data size is relatively small – in other words, small enough to store months in the in-page cache even if it is never used. Sounds like you may be doing this anyway and only need to block when the user jumps out of the range of cached data.

Intelligent Caching

I am imagining the callback function – the one that is called when the ajax call completes – will check if the currently selected date is on the “edge” of the cached data – either the first week in cache or the last week (or whatever). If the user is on the edge, then the callback can send out an additional request to optimistically pre-load the cache up to the 4 week limit, or whatever time range makes sense for your 80% use cases.

You may also consider caching the generated calendar data on the server side, on a per-user basis. If it is CPU- and time-intensive to generate these things, then it should be a good trade to generate once and keep it in the server-side cache, invalidating only when the user makes an update. With x64 servers and cheap memory, this is probably very feasible. Depending on the use cases, it may make for a much more usable interaction, the 2nd time a user connects to the app. You could even consider pre-loading the server-side cache on a per-user basis, before the user requests any calendar.