Partial patient calendar caching with Memcached

In Ankhos, we display a lot of information in different places, the most comprehensive of which is the patient’s calendar. I’ll talk about what we put on the calendar, what it looks like, and one of the tricks we have used to make it very fast.

Ankhos tracks everything from treatment schedules to nursing notes to appointment times and lab results.  That can end up being a lot of data, touching a lot of database tables if the patient has an involved history. So how do we show all of this information at once, while still having a fast, painless user experience?

Here is an example picture of what an somewhat involved calendar might look like (this is actually sort-of tame. I was trying to find one without much identifying data):

Ankhos calendar example

Patient calendars in Ankhos can become very complex.

You are able to scroll up and down depending on how long of a history the patient has and how far out treatments are scheduled (or based on preferences).  A straightforward way to increase the performance of this page is through caching.  We went with Memcached. It is insanely simple to use and very fast.   There are lots of tutorials on how to speed up flat-page or low-change page performance on their site (My favorite is their tutorial… in anecdotal format ).

 

One problem still remained, however. Ankhos allows the user to drag and drop treatments,  create comments directly on the calendar and have new treatment orders appear immediately.  Caching the entire calendar may make it load quickly, but each time an action is performed, the whole thing needs to be ‘recalculated’, as one action could have the potential to affect long swaths of time (e.g. Discontinuing a treatment).  This would dramatically increase response latency when manipulating the calendar (a bad thing).

 

Consider two different calendar operations: 1.  jotting a margin note that affects one date and 2.  dragging  a 6 month Carboplatin regimen from Tuesdays to Thursdays.

 

Our goal is to make the difference in response latency be a function of the size of the change, not the size of the calendar, so that these two operations would ‘feel’ like they took  roughly the same amount of time.

To accomplish this goal we have split up our calendar cache.  Instead of caching the entire calendar as one HTML chunk, we store the rendered HTML of each week  separately and render single weeks in the calendar only if they ‘miss’ the cache. Our cache key would be something like  “ANKHOS:CAL_WEEK:1234:2011-10-02”. If all of the calendar weeks are in cache, displaying the calendar is as fast as string concatenation.

 

This way when we made a large drag and drop operation or just a single date modification, we can expire the weeks that are affected by these dates and re-render only those weeks.

 

This scheme has served us very well and has made calendar manipulation a pleasant experience. I hope this idea gives someone  a head start on their partial-caching problem.

 

Tags: , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: