Application Review and Caching for Web Development

Last week was very interesting. With the application growing quickly, we thought it was time to take a break from the rapid pace of development, and have a think about the architecture of the site. For added insight, we engaged an external consultant to spend a week with us, study the application and the code base, and advise us on what areas we need to improve on.

A week later, and I’m pleased to report that the application is in pretty good shape. It’s never easy to find time for refactoring, but the areas we intend to address over the coming months are;

• An alternative way to store persistent variables. Currently these are stored as client variables on the database, but finally we intend to move to session variables, with sticky sessions across our cluster.    
• A more consistent approach to object instantiation, using Lightwire to create every object as a singleton in the application scope
• A rewrite of many of our function calls to ensure that all functions are correctly encapsulated
• An extension of the current caching methodology to cover a wider range of elements

The caching question is particularly interesting. Our pages are a mixture of static and dynamically generated content. Each request builds the html, css and javascript from values stored in the database. Traditionally these have been split into three separate requests. The advantage of this is that the page can start downloading before everything has been generated. The disadvantage is the lack of persistence of information across the three requests, meaning more work for the application and database. Recently we had an insight. While the html for most pages depends on the user and their viewing rights and session information, the same cannot be said for the css and javascript. There is really no need to generate this on every request, and so we’ve rewritten this to save the generated values for each page on the database. Whenever a site is updated in Mission Control, the data is wiped for that site, and then rebuilt the first time a user browses a page. This code has already been written and will go online in the next release, which should improve performance somewhat.

So much for those. But the html is trickier. As I said, this varies from viewer to viewer, and so simply saving a generated version for a page will not work. Even saving a version for each combination of page and viewer will not work, although whether you’d want to do that would be debatable anyway. This is because as a user logs in and logs out, adds and removes items from their shopping cart etc…, what they expect to see changes. However, what is true is that the html for each page is made up of lots of smaller layout items. What we may be able to do is cache those elements of the page that are consistent between viewers. So for example, everyone sees the same version of the blog widget. This could be cached, and any page that includes that widget can draw from the cache. Not everyone sees the same version of the featured products widget, as some products are only available to certain groups of users. However, the html that draws a specific product may be the same. This means we can cache the layout of each product individually, and just retrieve from cache those products that the user is entitled to view, in whatever order they choose. The possibilities are endless, and I think this will be a fun project.

Where to cache is also under review. Currently we cache some dynamically generated content within the application scope, in a structure that we create and manage explicitly.  It is hard to know just what the impact on memory is of putting large amounts of data into memory in this way. The worry is that as we start to add bigger and bigger objects into cache, such as large queries, say, the size of the application structure will become too large and have an unpredictable effect on site performance. As an alternative, we are looking to replace this method of caching with <a href=”http://ehcache.org/”>EHCache</a>. This should have many advantages over the way we currently do things, including;

• A more efficient caching and removal mechanism
• The option to run this outside the application as its own thread
• The ability to cache data over the whole cluster using <ahref=”http://terracotta.org/”>terracotta</a>, rather than duplicated on each server
• Detailed statistics and dashboards of the size and impact of cached objects

Of course, all of the above just pertains to dynamic content. There are other caching mechanisms for handling static content such as caching in the browser, caching in the load balancer etc.

So in summary, a really useful exercise last week, with a fair amount of work off the back of it. Perhaps I’ll write about some of the other results of last week in more detail next time.