Sitellite is one of a breed of real-time, or dynamic, CMS systems.  This has the advantage of content being always fresh, 100% personalizable for each specific user, and the ability to more easily render complex pages that collect data from multiple sources.  It also has a potential usability advantage, because the editing of the web site can be done <em>inline</em>, making it more natural for web site editors to use.  The down-side is that each web page request calls the database again, and also increases the load on the server.

The alternative, called "static publishing", is a method whereby static HTML pages are generated and then uploaded to the server by the CMS system, which lives externally to the web site itself.  This can drastically increase the web site's performance for visitors, but has as drawbacks the difficulties of personalization, fresh content, and page complexity, which can often lead to performance problems when publishing changes to the live web site, due to the number of pages that need updating when a single page is changed (navigation, summaries, syndications, etc.).

We chose the former method for Sitellite, because there are more solutions to the performance problems within a real-time CMS than there are to the static nature of the latter group of CMSes.  Namely, content caching.

Caching in General

Content caching can be a complicated matter, and an awareness of these complexities is the key to choosing the right method of caching for any given situation.  Sometimes, no caching is even the best solution.

Caching can be broken down into three types:

Whole-page caching

The advantages of caching whole pages is that it is easier to accomplish, and the performance increase is often greater than caching only parts of the page.  This is because very little processing overhead is required to serve a cached web page.

However, the downside of whole-page caching is that personalization and dynamic features (ie. interaction, forms, real-time data requests) become very limited, if not nearly impossible.

Partial-page caching

The advantages of caching partial pages is that you can still include personalized data in the non-cached parts of the page, but can reduce the processing overhead of each page request by cutting out the need to repeat the queries and logic of specific, repetitive pieces of content.  This can include sidebars, pages themselves, or any other type of query

Query-level caching

Query level caching is where the results of a database query are cached prior to the rendering of the content into the web site templates.  This can help reduce the load on the underlying database server for frequent database requests, which if properly applied, can often provide just the boost your web site needs to make the visit a better experience for your visitors.

Query-level caching is usually yields lower performance gains than partial-page caching, since it only eliminates the expense of a database query, and does not affect template processing in any way.  Still, it is a good solution for quickly improving the speed of key database queries in a web application.

Next: Caching in Sitellite

Page 1: Caching in General
Page 2: Caching in Sitellite
Page 3: Partial-page caching
Page 4: Query-level caching

All Tutorials