Enabling dynamic content caching for database-driven web sites

Abstract

Web performance is a key differentiation among content providers. Snafus and slowdowns at major web sites demonstrate the difficulty that companies face trying to scale to a large amount of web traffic. One solution to this problem is to store web content at server-side and edge-caches for fast delivery to the end users. However, for many e-commerce sites, web pages are created dynamically based on the current state of business processes, represented in application servers and databases . Since application servers, databases, web servers, and caches are independent components, there is no efficient mechanism to make changes in the database content reflected to the cached web pages. As a result, most application servers have to mark dynamically generated web pages as non-cacheable. In this paper, we describe the architectural framework of the CachePortal system for enabling dynamic content caching for database-driven e-commerce sites. We describe techniques for intelligently invalidating dynamically generated web pages in the caches, thereby enabling caching of web pages generated based on database contents. We use some of the most popular components in the industry to illustrate the deployment and applicability of the proposed architecture.

Caching Dynamic Web Content: Designing and Analysing an Aspect-Oriented Solution

“…Requests BrowseCategories and BrowseRegions have an almost 100% hit rate, while requests BuyNow and PutComment have the least cache hit ratios. While most of the misses in the last two categories were cold misses, 4 for ViewItem and ViewBids, most of the misses were due to invalidation of the cached entries. Figure 17 shows the relative benefits experienced by different requests for TPCW, running with 400 clients.…”

“…Typically, pages can be set to timeout so that the cache content is periodically refreshed. CachePortal [4] has a unique form of weak, time-lagged consistency. It relies on timestamps and HTTP logs to conservatively determine which pages to invalidate.…”

“…Of course, an ideal solution is one that can be added transparently by the developers, possibly even as an after-thought. Some examples of transparently adding caching to an application are given in [17,6,4], but these ignore consistency of the cached entries. Other solutions provide consistency, but ignore transparency, requiring manual insertion [10].…”

Surviving a search engine overload

“…For instance, a dynamic website may include a half dozen cache mechanisms: at the database layer [11,25], data interface layer [11], scripting layer, virtual file system, and the network proxy layer [14]. Several cache systems for dynamic websites attempt to map underlying queries to cache objects for intelligent invalidation [13,20,25]. The web application as a whole may also include several programmatic caches to cache repeated function results, web objects, and templates [3].…”

Web-Based Energy-Efficient Cache Invalidation in Wireless Mobile Environment

“…Although cache manager can read database's update log, it is about which entry in the database is inserted, updated or deleted. The major challenge is for creating a mapping between the cached web pages and the changes of underlying data in the database [3]. We separate mapping into two parts: (1) Request-to-Query mapping: the mapping between web pages and queries that are used for generating these pages.…”