Sync Kit: A persistent client-side database caching toolkit

for data intensive websites

The MIT Faculty has made this article openly available. Please share
how this access benefits you. Your story matters.

Citation Benson, Edward et al. “Sync Kit: A Persistent Client-side

Database Caching Toolkit for Data Intensive Websites.”
Proceedings of the 19th International Conference on World Wide
Web. Raleigh, North Carolina, USA: ACM, 2010. 121-130.
As Published http://dx.doi.org/10.1145/1772690.1772704
Publisher Association for Computing Machinery

Version Author's final manuscript

Accessed Thu Jun 21 03:59:51 EDT 2018
Citable Link http://hdl.handle.net/1721.1/63112
Terms of Use Creative Commons Attribution-Noncommercial-Share Alike 3.0
Detailed Terms http://creativecommons.org/licenses/by-nc-sa/3.0/
 Sync Kit: A Persistent Client-Side Database Caching
Toolkit for Data Intensive Websites

Edward Benson, Adam Marcus, David Karger, Samuel Madden

{eob,marcua,karger,madden}@csail.mit.edu
MIT CSAIL

ABSTRACT When many data items are retrieved, latencies can grow to
We introduce a client-server toolkit called Sync Kit that be seconds long. Asynchronous technologies such as AJAX
demonstrates how client-side database storage can improve allow web applications to remain responsive during these re-
the performance of data intensive websites. Sync Kit is quests, but designing highly responsive web applications in
designed to make use of the embedded relational database the face of these latencies, especially on bandwidth-impaired
defined in the upcoming HTML5 standard to offload some devices such as phones, remains a challenge.
data storage and processing from a web server onto the web One way to address the database load problem and la-
browsers to which it serves content. Our toolkit provides tency problem would be to offload data processing to web
various strategies for synchronizing relational database ta- browsers. If browsers could access some or all of the data
bles between the browser and the web server, along with needed to satisfy a request from a local cache, then pages
a client-side template library so that portions web appli- would load faster and server-side databases would do less
cations may be executed client-side. Unlike prior work in work. This is especially true in applications such as Face-
this area, Sync Kit persists both templates and data in the book or Twitter where the same data items (e.g., posts on
browser across web sessions, increasing the number of con- a user’s news feed) are sent again and again as users reload
current connections a server can handle by up to a factor of pages in search of new messages. In such scenarios, tradi-
four versus that of a traditional server-only web stack and a tional web caching methodologies are too coarse-grained—
factor of three versus a recent template caching approach. web pages may share a significant amount of data across
repeated accesses, but page content is still dynamic.
Categories and Subject Descriptors: H.2 [Informa- Fortunately, the upcoming HTML5 standard includes a
tion Systems]: Database Management client-side persistent database API that makes it possible to
General Terms: Design, Measurement, Performance. instantiate and store databases inside the web-browser. The
Keywords: Cache, Client-side, Web, Browser. standard specifies that this store is to be a SQL-compliant
database accessible through a JavaScript API. Though it
was initially designed to support offline access to web appli-
1. INTRODUCTION cations via cached data, the same technology can be used
To support the increasingly sophisticated and feature-rich to offload data processing and reduce server-communication
applications “hosted” on the web today, programmers who latency even when the client is online. To exploit this tech-
deploy them must run complex and sophisticated server in- nology, however, application developers have to manually
frastructures. Unlike desktop applications, where all of the manage the cache, modifying their queries to take explicit
processing and computation is done locally, most web ap- advantage of the client-side data, and writing code to deter-
plications rely on the server to fetch and process data and, mine if cached results are still valid, and to merge cached
often, to render that data into HTML for presentation on results with updates from the server.
the client. Building servers that can scale is a tremen- To address this complexity, we built a toolkit, Sync Kit,
dous challenge, of which a significant component is manag- that allows application developers to easily and efficiently
ing load against back-end database systems. Indeed, many take advantage of client-databases. Sync Kit provides a li-
companies (most famously Twitter) have experienced widely brary of data structures for commonly used synchronization
publicized database-system failures due to their tremendous patterns (e.g., a queue of objects, each of which corresponds
growth, and have invested great effort into sophisticated to one result in a database query) that programmers use to
database partitioning and caching infrastructures to reduce express their application. When these structures are used,
and spread database load. Sync Kit generates code for the client that populates a client-
The tight coupling of applications to a web server can also side cache of recently accessed items and reuses the contents
generate significant latency in user interactions. Web appli- of the cache to produce web pages, fetching new or uncache-
cations are located “far” from the data they present to users, able results from the backend server automatically. Because
and each data item may take many milliseconds to retrieve database results are cached client-side, Sync Kit provides a
as requests are sent to servers in different parts of the world. templating library that allows programmers to describe how
Copyright is held by the International World Wide Web Conference Com- to generate a web page from the cached query results.
mittee (IW3C2). Distribution of these papers is limited to classroom use, Furthermore, Sync Kit’s caches can be shared across a
and personal use by others. user’s sessions; for example, if a user quits her browser and
WWW 2010, April 26–30, 2010, Raleigh, North Carolina, USA.
ACM 978-1-60558-799-8/10/04.
 def blogDataEndpoint(clientRequestData):
then restarts it hours later, the cache from the previous ses-
entry_data = QUERY("SELECT id, author,
sion can still be used. title, body, lastModified
In summary, the contributions of this work are to: FROM entries
WHERE published = True
• Identify data access patterns that are widely used on ORDER BY lastModified DESC LIMIT 10")
the web, and build corresponding data structures that tag_data = QUERY("SELECT entryid, tagid, tagstring
programmers can use to build their applications while FROM tags
benefiting from client-side database caching that can WHERE entryid IN (
achieve the same level of data consistency as their orig- SELECT id
FROM %entry_data%)")
inal applications. return HTTPResponse(to_json([entry_data, tag_data]))
• Demonstrate that these data structures, when used Figure 1: An example data endpoint containing two
properly, can reduce server load. On two realistic data sets, entry_data and tag_data. The endpoint
benchmarks based on a blog and a wiki, Sync Kit re- returns JSON data to the client to fill in a template.
duces server load by a factor of three versus our im-
plementation of a recently published template-caching
approach and a factor of four versus the traditional 2.1.2 Templates
web hosting stack. The data structures also signifi-
Data endpoints are made visible to the web user by com-
cantly reduce data transfer to the client to up to 5%
bining them with templates. These templates work much
of its amount in the traditional stack.
like the templates used in any popular server-side web pro-
• Show that these ideas can be integrated into Sync Kit, gramming environment, except they are executed on the
a practical and easy to use web-programming toolkit client-side, using a JavaScript template parser, instead of
that requires no browser modifications and can be im- being executed on the server.
plemented via a simple app-server framework that runs Though not as popular as server-side solutions, a num-
on the server. ber of client-side template libraries are currently in use on
the web [14, 5, 3], all of which operate around the similar
principle that some data object, expressed in JSON, is to be
2. ARCHITECTURE AND OVERVIEW combined with a declarative template to produce the final
In this section, we describe the basic operation of Sync HTML for a page. XSLT [11] also provides a standard way
Kit, including the programming model it presents to devel- to transform structured data results into web pages.
opers and the flow of data as it presents a page to users. Any of these existing client-side template languages could
be adapted to work with Sync Kit’s manner of operation.
2.1 Programming Model Sync Kit simply needs some way to combine data results
Programmers using Sync Kit are required to design two and template code once the client is in possession of both.
types of structures: data endpoints, which describe the data Our current template library is based off of the HTML5
that will be used to render a web page, and templates that Microdata specification. This specification provides a way
describe how to generate HTML from data endpoints. In to use HTML attributes to relate data entities and their
our examples, we use the SQL language to describe data properties to regions of the web document, much like RDFa.
served by data endpoints, but in practice different web pro- Other HTML5 additions allow for the creation of custom tag
grammings frameworks (e.g., Django, Ruby) may provide attributes that we use to supplement this semantic markup
their own query language. The queries and data structures with the types of simple control structures that all template
are written in terms of database tables to which the server languages must provide. Figure 2 provides an example of
has access. what a Sync Kit template looks like for a table of blog en-
In the remainder of this section, we introduce our pro- tries. We make use of both upcoming HTML5 tags and
gramming model through a series of examples. attributes in this example.
2.1.1 Data Endpoints <section id="blog_posts"
An example data endpoint for a simple blogging applica- data-query="SELECT title, author, body FROM entry_data
tion is shown in Figure 1; it defines two queries, entry_data ORDER BY lastModified DESC LIMIT 10"
data-as="Entry">
and tag_data. entry_data defines a list of the ten most
<article itemscope itemtype="Entry">
recent blog entries that will be presented to the user, and <h2 itemprop="title"></h2>
tag_data defines a set of tags describing those entries. Note By <span class="author" itemprop="author"></span>
the use of the %entry_data% syntax that makes it possi- <div class="contents" itemprop="body"></div>
ble for one data endpoint to reference another as a nested </article>
query. In this example, we say that entry_data, whose con- </section>
tents decide the results of the tag_data query, is the parent
of tag_data. Figure 2: A Sync Kit template for a list of blog en-
The resulting relations from these endpoint queries can tries. The template uses data endpoints from Fig-
then be used in templates. For example, the template shown ure 1 as tables referenced from SQL queries.
in Figure 2 constructs an HTML page that contains one
block on the page for each blog entry and its tags. Note In Figure 2, we see an ordinary HTML fragment decorated
that templates also include SQL, where the tables that are with tag attributes that define the way in which data from
accessible to these queries correspond to the endpoints de- the client-side database (having been synchronized using the
fined in the endpoint definition. data endpoints previously specified) should fill the template.
On the section element, the data-query attribute specifies So far, we have described a mode of operation that is
the SQL query to perform and the data-as property pro- essentially the way most AJAX applications work. From
vides a name with which to reference a row from the result a bandwidth and server load perspective, this approach is
(Entry). Later, an item is defined (using the itemscope at- only marginally more efficient than a “traditional” archi-
tribute) that has the same class type as the query result tecture where the server is responsible for populating the
rows – this lets the template library know that this portion template. The AJAX approach reduces bandwidth com-
of HTML is to be repeated for each row of the result. The sumption slightly if the size of a repeated template is large
template library then iterates over the rows of the Entry compared to the size of the data being used to populate each
result, filling in the template for each row, resulting in the instance of the template, for example.
output shown in Figure 3, shown truncated to only one blog There are two opportunities for performance gains through
post. This output is both a properly rendered HTML frag- caching, however, which can dramatically improve the situa-
ment and a machine-readable HTML5 Microdata document. tion. First, if a template has been fetched before, it does not
need to be fetched again for some time. In some cases, this
<section id="blog_posts">
can result in significant bandwidth savings, as was noted by
<article itemscope itemtype="Entry">
<h2 itemprop="title">My Thoughts on HTML5</h2> Tatsubori and Suzumura [28].
By <span class="author" itemprop="author"> The second and more interesting opportunity for caching
Tim Berners-Lee arises with data endpoints. HTML5 provides facilities for
</span> the browser to store relational data in a persistent client-
<div class="contents" itemprop="body"> side database, which can be used to store the data endpoint
The HTML5 working group has been...
results it fetches. Rather than re-fetching the entire data
</div>
</article> endpoint, it can request from the Sync Kit server only the
</section> contents of the endpoint that have changed (for example, the
new blog posts that have been written since it last contacted
Figure 3: The output of the template in Figure 2. the server.) It can then combine these new results with
the records cached in the client-side database and use these
2.1.3 Putting the Pieces Together combined results to populate the template. We describe how
Using the Sync Kit framework, web developers do not this caching works in more detail in Section 3.
have to veer far from their current mental model of op- Figure 4 compares the traditional server-side form of web
eration. Web developers are used to thinking about their hosting (Figure 4a) with a template-caching approach due
programs as being run on the server and delivered to the to Tatsubori and Suzumura [28] (Figure 4b) and with Sync
client. Under this new model, the same remains true, but Kit (Figure 4c), which caches both data and templates.
instead of delivering a rendered page, the server delivers a
tuple that specifies both the template to be rendered and 3. SYNCHRONIZATION STRUCTURES
the data endpoints that provide the data to fill the tem- The previous section described our approach to caching.
plate. Using the blog example, this tuple is ["blog.html", The browser caches results and endpoints issue queries to
[entry_data, tag_data]]. fetch results since the last cache update. Realizing this ap-
The Sync Kit framework handles the rest, ensuring data proach is difficult for two reasons. First, identifying the
synchronization between client and server databases, tem- cached portion of a query requires semantic analysis of schemas
plate operations on the client, and caching using both HTTP and queries to determine the portion of a new query that
and HTML5 Manifest caching schemes. We now describe intersects with previously cached results. Second, rewriting
how this synchronization is actually performed, resulting in queries to use caches in way that actually reduces load on
a substantial reduction in load and bandwidth on the server. the server is a known hard problem in the database commu-
nity. The main challenge is that the simplest way to reuse
2.2 Execution Model a cached result is to rewrite the query to include a complex
At a high level, Sync Kit execution is handled by the Sync set of WHERE predicates that exclude all of the tuples in
Kit server, which runs inside the web server (as a collec- the cache; such predicates slow query execution as they have
tion of scripts for the Django [1] web framework, in our to be evaluated on each tuple, and often don’t reduce the
implementation), and the Sync Kit client library (written in data the database has to read from disk unless appropriate
JavaScript), which is run by the client browser. indices happen to be available.
We now describe Sync Kit’s operation with no template The problem is usually called semantic caching and has
or data caching. When the browser requests a Sync Kit- been well-studied (e.g., [27, 18, 26, 16, 19], and many oth-
enabled page, the Sync Kit server sends it the template, ers.) Jónsson [26] shows that existing database systems do
as in Figure 2. Complex pages are stored across multiple not perform well when presented with arbitrary, complex
templates, which are stitched together. This template also queries to retrieve cached results. As a result, most high
references Sync Kit’s client library, synckit.js, and con- performance semantic caching systems require modifications
tains all data endpoint definitions used by the template. The to the backend database to keep track of changes since the
Sync Kit client library registers a callback into the browser’s last access, something we wanted to avoid in Sync Kit.
onLoad event, and takes control once the page template has In Sync Kit, we take a simpler approach that requires no
loaded in the browser. The Sync Kit client library then sends modifications to the database: programmers write their data
an asynchronous HTTP request to the server and requests endpoints in terms of data structures that make it easy to de-
the current data for all endpoints in the page template. The termine what has changed since they were last loaded. Sync
server sends back a JSON object containing this data, which Kit currently provides two such synchronization structures:
the client library uses to populate the template it received. queues and sets. We discuss other possible synchronization
 Browser
App
Application
Template Server news website (e.g., nytimes.com or slashdot.org), email
Server Engine Database
sites (e.g., gmail.com), and social networking sites that list
updates to friends’ statuses (e.g., facebook.com or twitter.
com).
Query Database To see how queues are programmed in our model, consider
the blog endpoint from Figure 1. Suppose the programmer
knows that blog entries are always accessed in time order by
Render
Template
the template in Figure 2. She can then declare that the blog
entry endpoint is a queue, as follows:
HTML entry_data = QUEUE(on = "lastModified"
table = "entries"
order = "DESC"
include = "id, author, title, body, lastModified"
(a) Traditional Control Flow: Template Rendering and
filter = "published = True"
Database Access are on Server limit = 10)
Here we see a queue synchronization object built around
Browser
Browser
Cache
App
Server
Application
Server
Database
the entries table in reverse order by the date field. The
queue is limited to 10 items and contains further informa-
tion, such as which projected fields to include and how to fil-
Fetch
Template
ter the queue inputs (in this case, only messages that have a
published variable set to True). The synchronization spec-
Request Data
ification is similar to the SQL APIs offered by web toolkits
such as Ruby on Rails [6] and Django [1], but rather than
Query Database creating a query result set, it defines data endpoint capable
of synchronizing the result set over multiple web sessions
Send Data
with a minimal amount of information exchange.
Process The first time the client library loads this endpoint, a SQL
Template
query identical to the one shown in Figure 1 will be run. The
Sync Kit server will also send the timestamp when these re-
sults were fetched from the database, the table schema that
the client-side database should maintain, and the parame-
(b) Template Caching: Template Rendering is on Client ters which define the queue synchronization structure.
Subsequently, whenever the client reloads this endpoint,
Browser
Database
Browser
Browser
Cache
App
Server
Application
Server
Database
it provides the maximum lastModified value in its version
of the synchronized entry_data endpoint. The server will
Fetch
add a predicate to the WHERE clause of the query to only
Get Client
Template
retrieve data that is more recent than the client’s lastModi-
DB State
fied value. If few entries have been added to the blog since
Request State Update
the last client visit, the server will fetch fewer results, re-
Query Database
quiring less work if the entries table is properly indexed.
Send Data Diff
The server will also send less data to the client.
Upon receipt of new data, the client-side library merges
Load Data
the new results with those already in the browser-side database.
Query Data
Process
Template
Now that the client-side database state has been refreshed
with the current data, the template library will run. It will
fetch the top 10 blog entries from the client-side database
(c) Sync Kit: Template Rendering is on Client, and and fill out the cached template with them. Finally, the
Database Accesses are Cached on Client client can discard entries outside the new top 10 from the
browser’s database, as will be discussed in Section 3.5.
Figure 4: Web page rendering architectures. White
boxes are client-side and gray boxes are server-side. 3.2 Sets
structures and improvements on the ones described in this We now turn to Sets, which are another abstraction pro-
section in Section 6. vided by Sync Kit to perform client-server data synchroniza-
tion. Sets capture a basket of data that is unordered from
3.1 Queues the perspective of the client. Each data item in the basket
Queues capture the idea that results are ordered on some is identified by some key, a role usually served by a primary
attribute (say, time) and that this ordering reflects the way key in a relational database. Examples of such sets of items
the client will access the data. This makes it easy for the are products in a web-based store, movies and actors on the
client library to fetch new data items that have been created website IMDB, pages on wikis, and the tags used to describe
or changed since the last page load by simply sending the blog posts in the previous example.
maximum (or minimum) value currently in the client-side Sync Kit maintains a notion of two different types of sets.
cache of the queue. This abstraction is particularly use- Complete Sets are sets that are actively transferred in their
ful for synchronizing information that fits the ‘feed’ format, entirety to the client. After synchronizing with a complete
which characterizes a number of websites, including any set endpoint, the client is guaranteed to have the entirety
of the set described. Attributes of members of the set may Whenever client-side logic requires a given wiki page, the
change, and items can leave or enter a complete set over wiki_data synchronization set will first look for the page id
time. One example of a complete set is the tags in the in the client’s local database. If the id is found, it can be
previous example—the number of tags on a blog is small returned to the user. If it is not found, the client can issue
enough that it can be sent to the client in its entirety. On an AJAX request for the page to be delivered to the client.
the other hand, one would not want to transfer the entire set
of pages in a large site such as Wikipedia to the client the 3.5 Eviction and Consistency
first time a user requests a single page on the site. Partial There are three remaining concerns to make synchroniza-
Sets contain members that are lazily transferred to the client tion structures realistic in paralleling the current web ex-
on a primary key lookup. perience: keeping the client-side database small, ensuring
that the client data mirrors the most up-to-date data on the
3.3 Complete Sets server, and enforcing endpoint constraints on templates.
Because the client can not support a database of the mag-
Complete sets are a useful abstraction for relatively small
nitude that the server can, we define an eviction policy for
collections of data that see frequent client use but do not fit
data in the client-side database. A simple LRU eviction pol-
the access pattern defined by the queue structure. Because
icy works reasonably well, with some caveats. For queues,
access is random and frequent, and the cost of transferring
evicted entries can only be those outside of a distance of
the entire set is low, the client and server coordinate to en-
limit from the maximum lastModified date of items in
sure that the client has a fresh copy of all set items.
those queues. For complete sets, any evictions must mark
For example, suppose our programmer from the Queue
the entire set stale, to ensure that future queries are directed
example would like to add tags to the blog entries view, as
to the server to re-synchronize the data structure. Finally,
in Figure 1. Remember that the tag_data endpoint requires
for partial sets, no special precautions are required—evicted
a nested query to its parent endpoint, entry_data. Our
elements will be re-requested from the server.
complete set of tags is defined by the tags table as well as
To ensure that the client remains up-to-date with the
the entries that the user will see which will require tags:
tag_data = SET(type = "complete" server, any modifiable entries in the synchronization struc-
table = "tags" tures must be noted as such, and a last-modified time or
parent = [entry_data, version must be attached to each entry in the underlying
"entryid = entry_data.id"] server-side table. All requests to an endpoint which con-
key = "tagid" tains modifiable items must send a last-access time, which
include = "entryid, tagid, tagstring") denotes when a client last accessed this endpoint. For results
This definition follows the one of tag_data in the blog returned by an endpoint during synchronization, only those
data endpoint of Figure 1. We define the set to be a complete with modification time or version larger than the client’s
replica of the table tags for any tag involved in an equality last-access time will be returned to the client.
join on the entry_data result set. We will request tags by Sync Kit currently provides no guarantee that the query
the key tagid, and include the fields entryid, tagid, and executed in a template will be consistent with the endpoint
tagstring from the table. defition. For example, in Figure 2, if the programmer mod-
When a client first queries the data without having syn- ifies the query to “LIMIT 100,” the client-side cache of the
chronized entry_data and tag_data before, the server will entry_data table is only defined and guaranteed to contain
construct the query in Figure 1. For subsequent visits, the the 10 latest records. The programmer must take care to de-
client will send the entry_data and tag_data requests with fine the view using the same SQL expression on the server
a list named tag data.tagids, containing the tagid values al- and client. As we discuss in Section 6, we are investigating
ready on the client. The server will construct the query in techniques to automatically generate client-side code from a
Figure 1, with an additional WHERE clause predicate indi- server-side SQL query, partly to eliminate the possibility of
cating that only tags not on the client should be sent: mismatch in these view definitions.
AND tagid NOT IN (tagid1, tagid2, ...)
4. PERFORMANCE EVALUATION
3.4 Partial Sets In this section we compare the performance Sync Kit to
Partial sets represent a set of items for which the server our implementation of the Flying Templates [28] approach
does not attempt to maintain a fully synchronized copy on and to traditional server-side web hosting. In our consider-
the client. This type of data structure may be used in cases ation of the benefits of various approaches, we look at con-
where the set of items is too large to reasonably store on nection throughput, data transferred per request, and the
the client-side. Wiki articles are a good example—we would client-side latency of each approach. Our experiments con-
model the corpus articles on Wikipedia as a partial set. A sider two websites we built with Sync Kit: a blog site, in
table of pages could be synchronized in the following way: which users revisit the page throughout the day looking for
wiki_data = SET(type = "partial" news updates, and a Wiki, where users browse a connected
table = "wiki_pages" graph of web pages, potentially revisiting some pages over
key = "id" time. We built these websites using content update and hy-
include = "id, title, contents") perlink models from real websites.
This definition indicates that the endpoint wiki_data can
be maintained by performing id lookups on the server as 4.1 Experimental Environment
the client needs them, and that whenever a desired id is The server-side programming environment is the Python-
requested, the id, title, and contents of the wiki page based Django [1] 1.1 web framework. We use nginx as the
should be delivered. webserver to serve both static content directly and dynamic
content over FastCGI to running Django instances. The recent stories on the blog are displayed to the user. A user
webserver runs Ubuntu 9.10 (kernel 2.6.31), and has an In- who visits frequently will see some new stories and some
tel Core 2 processor with four 2.4GHz cores, 8 MB of L2 older repeated ones. Such experiences occur on sites other
cache, and 4 GB RAM. The database, which is on the same than blogs—web search, web-based email, and social net-
machine, is Postgres 8.4.2. For the throughput and data working sites such as Facebook or Twitter are all similar.
transfer tests, our client machine has a 3.2 Ghz Intel Pen- In order to generate a representative workload, we mod-
tium 4 and 2 GB RAM. Both machines are connected to eled our benchmark on popular blogs in the wild. We re-
each other over a local network with link bandwidth 112 quested the latest RSS feed from several popular blogs, and
MB/s reported by netperf and round trip time 1.516ms to report their time between posts and post sizes in Table 1.
transfer 1 byte of data over HTTP. We also ran in-browser From these, we selected TechCrunch to parameterize a script
timing tests on a netbook running Microsoft Windows XP which loaded a server-side database with three years of ran-
and Mozilla Firefox 3.5 over a local network with a round domly generated content, based on a normal distribution
trip time of 3ms to transfer 1 byte of data. For through- of post length (µ = 5487, σ = 4349) and an exponential
put tests, the client gradually increased its request rate us- distribution of time between posts (λ = .53posts/hour).
ing httperf until it identified the point at which the server We re-use the same template of size 100KB for all three
stopped responding to all requests with HTTP 200/OK. serving strategies. This template consists of basic HTML,
CSS, and stanard JavaScript libraries, of which SyncKit is
4.2 Benchmarked Systems a small fraction. All CSS and JavaScript is inlined.
In assessing Sync Kit, we compare three systems: We constructed several client workloads for this site to
Traditional. All template and data processing is performed examine its performance for clients who re-visit the site at
on the server. Controller logic on the server performs queries varying frequencies with respect to the update frequency.
against a server-side database, and the results are filled in on For each ith client workload generated, we modeled users
a server-side template, which delivers HTML to the client. visiting the site over seven days at a rate of λi relative to the
The process is implemented with standard components in mean time between posts for the blog. We vary λi between
the Django web development framework. .008 visits per new post (infrequent visits) and 3.8 visits per
Flying Templates. When a user first visits a site, they new post (frequent visits). For each visit-per-post frequency,
retrieve a template which is subsequently cached. The tem- we added users until we had generated 10,000 requests. In
plate issues AJAX requests to the server, which queries all cases this resulted in more than 100 users per workload.
the server-side database and returns results to the client as Testing with a variety of user visit frequencies is useful
JSON. The client-side JavaScript then fills in the template because it frees our analysis from dependence on the content
with the returned data. Django is used to generate the result update frequency that parameterized our blog test data. It
set as JSON, and we wrote a custom JavaScript library for is also useful because user visit patterns to a blog tend to
filling in the static template. This system is similar to the be independent of the blog’s popularity [20], so a variety of
one described in the work of Tatsubori and Suzumura [28], visit frequencies better reflects real-world workloads.
although the implementation is our own. The first time a user visits the site, both Sync Kit and
Flying Templates request and cache the template for the
Sync Kit. When a user first visits a site, they retrieve site. To model this, we made half of the users new users to
a template which is subsequently cached. Like Flying Tem- the site, causing their first request to include both data and
plates, HTML generation from the template is performed on template requests. Varying the fraction of new users to the
the client-side and data is retrieved from the server. Unlike site did not significantly affect the performance differences
Flying Templates, the JavaScript library initializes a client- between systems.
side database using Google Gears [2] in which all data is On each visit, the client requests the latest 10 articles. To
stored and which is synchronized with the server using the simulate time, each client sends a currenttime to the server,
managed data structures described in Section 3. We selected indicating the time at which the page is requested.
Gears because the HTML5 standard is still in flux, and as of For the traditional and Flying Templates approaches, a
this writing no browser implements both the HTML5 data SQL query of this form is issued on the server-side:
and caching proposals completely. SELECT id, author, title, contents, lastModified
FROM articles
4.3 Benchmarks WHERE lastModified < CLIENT_PARAMS["currenttime"]
We implemented our blog and wiki websites for the three ORDER BY lastModified DESC
systems listed above. For both sites, we built a benchmark LIMIT 10;
based on a sample dataset and sample workload using data The following Sync Kit queue manages the client cache:
from real websites. httperf was used to determine the per- QUEUE(on = "lastModified"
formance of each workload on each of the three systems. table = "articles"
order = "DESC"
Overall, the total number of lines of code written to imple-
include = "id, author, title, contents, lastModified"
ment the blog and wiki sites was the same across all three limit = 10)
approaches (typically within a few lines of code) outside of In addition to the currenttime argument, the Sync Kit
the included Sync Kit libraries. This is significant because it client also sends a maxclienttime parameter to the server, to
suggests that the Sync Kit approach can be made practical indicate the results up to the point which they have synchro-
from a programming standpoint. nized the dataset. The SQL query issued on the server-side
is the same as the one above with the following predicate to
4.3.1 Blog Benchmark fetch only results newer than the currently cached ones:
Blogs are representative of a queue-heavy workload—when AND lastModified > CLIENT_PARAMS["maxclienttime"]
a user visits a blog’s front page, around ten of the most
 Site Articles Examined Article Length (kB) Template Size (kB) Time Between Articles (min)
Tech Crunch 25 µ = 5.5, σ = 4.3 23.1 µ = 114, σ = 117
ReadWriteWeb 15 µ = 7.5, σ = 6.9 50.1 µ = 263, σ = 343
Slashdot 15 µ = 3.4, σ = 0.6 64.1 µ = 116, σ = 54
Consumerist 40 µ = 3, σ = 1.6 22.6 µ = 111, σ = 226
Gizmodo 39 µ = 2.8, σ = 2.5 49.7 µ = 73, σ = 114
Engadget 40 µ = 7.2, σ = 5 46.0 µ = 85, σ = 64

Table 1: A sample of several popular blogs. Article length is generally an order of magnitude smaller than
template size. New articles come out every one to two hours. If a user visits the front page, which displays
multiple articles, several times per day, they may see the same article more than once.

4.3.2 Wiki Benchmark 4.4.1 Blog Benchmark

If blogs are a prototypical representatives of the queue We tested the traditional, Flying Templates, and Sync Kit
synchronization structure, wikis are good representatives of approaches on the blog dataset described in Section 4.3.1.
a set. A wiki (e.g. Wikipedia) can be thought of as a con- We now present the performance of each system under vary-
nected graph of primary-keyed data that is too large to send ing user visit frequencies, which are controlled by the λi
in its entirety to the client. Because of its size, a wiki is syn- parameter described in the benchmark.
chronized lazily, and thus represents an partial set synchro- The charts in Figures 5 and 6 display measurements of
nization pattern. Note that we do not evaluate complete-set the maximum throughput and average data transferred per
synchronization in this paper—these sets are usually small request as λi increases, causing the user visit-per-post fre-
enough to by synchronized in their entirely, or at least as a quency to increase.
nested subquery on queues, and we find their performance
characteristics less interesting than larger partial sets. ● ● ●
Server Throughput (Pages/s) Traditional
To generate the wiki data set, we combined previous stud- ●

400
● Flying Templates
ies of content length and link structure, and suplemented ● Sync Kit
these numbers with a random sample of the pages accessed ●
●
on Wikipedia from publicly available web proxy logs [10].
300

●
We then generated 10,000 articles of random content length
(µ = 3276B, σ = 100B) [9] and title length (µ = 22B, σ =
●
●●
12B) [10] with an average of 23 [8] links per page. To model
200

1
article popularity, we assigned a probability of ●●
●●
article no.+10 ●● ● ● ● ●
to every article, normalized to generate a proper distribution ●●● ●● ● ●
●● ● ●
100

after assignment, which creates a Zipfian distribution to rep-

resent hotspots on Wikipedia. Here, lower article numbers 0 1 2 3
are are more popular than higher ones. The +10 prevents
the first few articles from dominating all others. This distri- Visit−per−post Frequency
bution is a good approximation of the actual usage patterns
for web resources [15]. Article links were generated such that Figure 5: User visit frequency vs throughput.
the source page was selected uniformly and randomly from
the page set, and the target page was selected proportional
to its assigned popularity probability. ● ●
●● ● ●
Finally, to generate a workload over the wiki, we modeled
Data Transferred (KB/Request)

●●● ●● Traditional
150

40 users visiting the site over the course of 15 days, once per Flying Templates
Sync Kit
day. Within a visit, each user picks an initial page i accord-
ing to the pages’ access probabilities, and navigates to linked
100

pages by choosing randomly from the normalized probabil-

ity distribution of the pages linked from i. We assigned the
● ●
●● ●
user an exit probability of .5 after each view, which would ●●● ●
●
●
●
50

end that day’s visit for the user. Because users visit the site
●
15 times, we can see how repeated accesses to the same page ●
●●
affect the performance of Sync Kit. The resulting repeated ●● ● ● ● ●
access rate in three generated workloads was 13.7%–14.9%.
0 1 2 3

Visit−per−post Frequency

4.4 Results Figure 6: User visit frequency vs KB per request.

In this section, we describe the performance results on our
two benchmarks. In both benchmarks, we generated three In all experiments, the Flying Templates approach pro-
random workloads with the parameters in Section 4.3 and vides slightly less than twice the request throughput of the
report the average performance of these three. Traditional approach while transferring 100KB less data per
request as it avoids transferring the template. This result is 4.4.2 Wiki Benchmark
similar to that shown in [28] on a different query workload. We ran the same experiments from the blog benchmark
Flying Templates sees a drop in throughput between λi = 0 with our set-based wiki benchmark. Figure 8 shows the
and λi = .5. This is an artifact of our experiment design, as throughput (top) and mean kilobytes per request (bottom)
less frequent visitors see a larger share of their traffic come for the wiki experiment. Since there is no varying visitation
from static templates which are faster for the web server rate, we didn’t vary the time parameter in this experiment,
to serve. For infrequently visiting clients, Flying Templates and so these are bar charts rather than line charts. From
and Sync Kit perform about the same, as Sync Kit is able to these results, it is evident that Sync Kit still has a large ben-
cache the template from one visit to the next, but there is a efit over the Traditional approach both in terms of a severe
very low probability of any article still being in Sync Kit’s data transfer reduction and in terms of increased through-
data cache on the next page load. For clients who revisit put. Sync Kit offers slightly better throughput and slightly
more frequently, however, Sync Kit’s cache helps dramati- decreased bandwidth relative to Flying Templates due to the
cally. At the extreme, Sync Kit is able to serve a factor of 14% cache hit rate for revisited wiki pages per user. This sig-
four (464 vs. 116) more requests per second than the tradi- nals that improved performance through prefetching might
tional approach, and nearly a factor of three more than the result in better performance, but the ultimate performance
Flying Templates approach. It also requires around 13.2% benefit will depend on the predictability of client browsing.
the data transfer of Flying Templates, and around 5.4% the
data transfer of Traditional.

500
We now look at the latency from the standpoint of a client

Server Throughput (Pages/s)

of the system. We ran client-side requests from a netbook

400
on the same network as the server with connection proper-
ties described above and λi = .31. The results are shown in

300
Figure 7; on the X axis are the three systems with the total
height of each bar representing the average latency to load

200
a page in each system. All three approaches have approx-

100
imately the same client latency (around 400 ms/request).
Note that Sync Kit improves server-side performance with-

0
out hurting the client’s experience.
Flying Templates Sync Kit Traditional
100
400
Data Transferred (KB/Request)

80

300
60
Total Time (ms)

40

200
Template
20

Client DB
Net RTT
100
Server
DOM Load
0

Flying Templates Sync Kit Traditional

Flying Templates Sync Kit Traditional Figure 8: Server throughput (top) and data transfer
per request (bottom) for the wiki benchmark.
Figure 7: Client latency for blog workload (λi = .31).
Figure 9 shows the latency results from a client perspec-
tive (again measured from a home computer) for the three
To understand how this latency breaks down, we now look systems. The results are similar to those shown in Figure 7:
at the components of the bars in a bit more detail. Looking overall, the differences in latencies between the three systems
at the “server” component, it is clear that Sync Kit does are small; Sync Kit spends a little more time than Flying
substantially reduce the total time spent waiting for data Templates on the more complex queries it runs to send its
from the server—from 93 ms in the traditional case to 45 ms state to the server, but the difference is is negligible. Again,
in Sync Kit. However, Sync Kit spends an additional 38 ms the total time is dominated by DOM Load.
loading data into the client database, and 61 ms populating
the template. Note that in all three scenarios, “DOM Load,”
which represents the time to load the DOM of a page into the 5. RELATED WORK
browser, dominates the client’s latency. To measure DOM In the FlyingTemplates [28] system, HTML templates are
Load time, we loaded the page into the browser cache and cached on and populated locally by the client. Templates are
measured the time until the “onLoad” JavaScript event. All sent to the client, where they are cached using the browser’s
three systems also incur a negligible 3 ms network round native mechanisms. On page load, a JavaScript library at-
trip overhead. Flying Templates also performs similarly; it tached to each web page queries the server for the appro-
sends more time waiting for data from the server than Sync priate data and combines the data with the page template.
Kit, but does not have to populate the client-side database. The authors show that this techniques yields up to a 2x
 350
Conventional web caching systems (e.g., proxy caches [7])
are similar: they offer the advantage that they work for
300 many clients, but they still require the server to expend
bandwidth to transfer data to clients. They are also tricky to
Total Time (ms)

250
get to work for dynamic content. Similarly, browsers locally
200
cache static content, but such caches are not effective for
Template highly dynamic web pages of the sort we consider.
Client DB
150
Net RTT
As discussed in Section 3, the technique we employ for
Server determining if a result is in the client-side cache is loosely
100 DOM Load
inspired by work in the database community on semantic
50
caching (e.g., [27, 18, 26, 16, 19]). The primary differ-
ence is that we constrain the programmer to access data
0 through a set of synchronization data structures that we
Flying Templates Sync Kit Traditional
have devised, allowing us to efficiently determine if a re-
sult from the database is available in the cache. Most rel-
evantly, Chidlovskii and Borghoff [16] observe that web ap-
Figure 9: Client latency for wiki workload.
plications are characterized by simple queries and as such
are amenable to semantic caching, similar to our observa-
throughput improvement in applications where the HTML
tion that a few simple data structures are sufficient to allow
is substantially larger than the raw data used to populate a
caching for many web-backed data intensive applications.
web page. Sync Kit offers the same benefits as FlyingTem-
plates, but also is able to cache the data behind a template,
in addition to just caching the template. We compared ex- 6. CONCLUSIONS AND FUTURE WORK
plicitly to this approach in Section 4. In this paper, we introduced Sync Kit, a toolkit for mak-
The Hilda [32, 31, 24] system executes both data opera- ing it easy for developers to take advantage of client-side
tions and template operations on the client site within the relational databases that will be introduced with HTML5-
context of a single web browsing session. It samples server compliant browsers. Sync Kit uses a simple programming
log files to determine which templates and data elements are model where users define data endpoints that cache database
most likely to be accessed within a user’s session, and then objects on the server and templates that describe how to ren-
preemptively sends those portions of the web application to der web pages in terms of these endpoints. This approach
the client. When browsing the site, pre-fetched portions of requires no browser modifications and is implemented as a
the web application can be accessed without contacting the simple Python- and JavaScript-based library.
server. Unlike Sync Kit, Hilda requires developers to build When an endpoint is accessed, its contents are cached in
their entire web application in an unfamiliar declarative lan- the server-side database and can be reused the next time a
guage; this is what enables the system to move computation template that accesses the endpoint is loaded. Templates
and data from client to server. Hilda does not consider data are also cached on the client. To ensure that endpoints are
persistence on the client. Orchestra [17] performs similar kept consistent with the backend database, endpoints can
partitioning of applications written in Java into a server- be declared to be sets or queues, which enables Sync Kit to
side and a client side component. run efficient SQL queries that identify changes in endpoints
Ganesh [29] is a caching system for dynamic database data since they were added to the cache. Our experiments show
that, rather than exploiting specific properties of application that when cache hit rates are high (as with our blog bench-
data structures, uses cryptographic hashing to identify por- mark), the Sync Kit approach performs well—approximately
tions of query results similar to results that have already a factor of four better than the traditional approach and a
been returned and reuses them. This approach has the ad- factor of three better than the Flying Templates [28] ap-
vantage that it is transparent to the application developer, proach. We also showed that client-side rendering does not
but does not exploit in-client caches as we do. negatively impact client-side performance, despite extensive
There has been considerable work on client-side caching use of JavaScript and the overheads of client-side database
in database systems [30, 22, 21], but this work has typically access. In short, Sync Kit offers significant performance ben-
assumed that there is a stand-alone database application efits for data intensive web sites.
running on the client, rather than pushing caching into the Looking forward, there are several ways to extend our
browser. In this work, it is assumed that these client-side work. One direction is to increase the breadth of the syn-
applications can interface with the backend database below chronization patterns Sync Kit supports. For example, ag-
the SQL layer, specifying exactly the tuples or ranges of gregation is an expensive server-side operation that may in
records that they have in their cache to ensure consistency. some cases be offloaded to the client—one can imagine de-
Other database caching approaches include the Ferdinand livering a compressed data cube [25] to the client in cases
system [23], which uses a proxy to cache database results. A where aggregation is frequent. We are also exploring ways
proxy-based approach has the advantage that it can cache to improve the performance of our current synchronization
data for many users, but introduces privacy concerns and structures. While partial sets can not be completely repli-
still requires users to go to a server on the Internet to re- cated on the client-side, some prefetching techniques can be
trieve cached data. Other database caching techniques – employed to return frequently co-accessed results that may
such as DBCache [12], DBProxy [13], and memcached [4] satisfy future queries and reduce client-side latency. Instead
– typically also focus on server-side caches that reduce load of forcing programmers to define their own synchronization
on the database but do not have substantial effects on band- structures, we are also working on a query workload analyzer
width and do not push rendering to the client. to generate or recommend such structures.
7. ACKNOWLEDGMENTS on Very Large Data Bases, pages 641–655, San
We thank the anonymous reviewers for their improve- Francisco, CA, USA, 1993.
ments. We also thank David Huynh for his thoughts on im- [22] M. J. Franklin, M. J. Carey, and M. Livny.
Transactional client-server cache consistency:
proving the performance of client-side database workloads. alternatives and performance. ACM Trans. Database
Our work was supported by NSF and NDSEG fellowships, Syst., 22(3):315–363, 1997.
and the NSF under grant number IIS-0448124. [23] C. Garrod, A. Manjhi, A. Ailamaki, B. Maggs,
T. Mowry, C. Olston, and A. Tomasic. Scalable query
result caching for web applications. Proc. VLDB
8.[1] Django
REFERENCES
web framework. Endow., 1(1):550–561, 2008.
http://www.djangoproject.com/. [24] N. Gerner, F. Yang, A. Demers, J. Gehrke,
[2] Google gears framework. http://gears.google.com/. M. Riedewald, and J. Shanmugasundaram. Automatic
[3] JSON-Template Template Rendering Engine. client-server partitioning of data-driven web
http://code.google.com/p/json-template/. applications. In SIGMOD ’06: Proceedings of the 2006
[4] Memcached distributed key-value caching system. ACM SIGMOD international conference on
http://www.danga.com/memcached/. Management of data, pages 760–762, New York, NY,
USA, 2006. ACM.
[5] PURE JavaScript Template Engine.
http://beebole.com/pure/. [25] J. Gray, S. Chaudhuri, A. Bosworth, A. Layman,
D. Reichart, M. Venkatrao, F. Pellow, and
[6] Ruby on rails web framework. H. Pirahesh. Data cube: A relational aggregation
http://www.rubyonrails.org/. operator generalizing group-by, cross-tab, and
[7] Squid: Optimising Web Delivery. sub-totals. J. Data Mining and Knowledge Discovery,
http://www.squid-cache.org/. 1(1):29–53, 1997.
[8] Using the wikipedia page-to-page link database. [26] B. T. Jónsson. Application-oriented buffering and
http://users.on.net/~henry/home/wikipedia.htm. caching techniques. PhD thesis, University of
[9] Wikipedia bytes per article, accessed Feb 10, 2010. Maryland, College Park, MD, 1999.
http://stats.wikimedia.org/EN/ [27] B. T. Jónsson, M. Arinbjarnar, B. Thórsson, M. J.
TablesArticlesBytesPerArticle.htm. Franklin, and D. Srivastava. ACM Trans. Internet
[10] Wikipedia page counters. http://mituzas.lt/2007/ Technol., 6(3):302–331, 2006.
12/10/wikipedia-page-counters/. [28] M. Tatsubori and T. Suzumura. Html templates that
[11] Xslt specification. http://www.w3.org/TR/xslt. fly: a template engine approach to automated
[12] M. Altinel, C. Bornh ovd, S. Krishnamurthy, offloading from server to client. In WWW ’09:
C. Mohan, H. Pirahesh, and B. Reinwald. Cache Proceedings of the 18th international conference on
tables: Paving the way for an adaptive database World wide web, pages 951–960, New York, NY, USA,
cache. In VLDB, pages 718–729, 2003. 2009. ACM.
[13] K. Amiri, S. Park, R. Tewari, and S. Padmanabhan. [29] N. Tolia and M. Satyanarayanan.
Dbproxy: A dynamic data cache for web applications. Consistency-preserving caching of dynamic database
In U. Dayal, K. Ramamritham, and T. M. content. In WWW ’07: Proceedings of the 16th
Vijayaraman, editors, ICDE, pages 821–831. IEEE international conference on World Wide Web, pages
Computer Society, 2003. 311–320, New York, NY, USA, 2007. ACM.
[14] E. Benson, J. Meyer, and B. Moschel. Embedded [30] Y. Wang and L. A. Rowe. Cache consistency and
JavaScript. http://embeddedjs.com/. concurrency control in a client/server dbms
[15] L. Breslau, P. Cue, P. Cao, L. Fan, G. Phillips, and architecture. SIGMOD Rec., 20(2):367–376, 1991.
S. Shenker. Web caching and zipf-like distributions: [31] F. Yang, N. Gupta, N. Gerner, X. Qi, A. Demers,
Evidence and implications. In In INFOCOM, pages J. Gehrke, and J. Shanmugasundaram. A unified
126–134, 1999. platform for data driven web applications with
[16] B. Chidlovskii and U. M. Borghoff. Semantic caching automatic client-server partitioning. In WWW ’07:
of web queries. The VLDB Journal, 9(1):2–17, 2000. Proceedings of the 16th international conference on
[17] S. Chong, J. Liu, A. C. Myers, X. Qi, K. Vikram, World Wide Web, pages 341–350, New York, NY,
L. Zheng, and X. Zheng. Secure web applications via USA, 2007. ACM.
automatic partitioning. SIGOPS Oper. Syst. Rev., [32] F. Yang, J. Shanmugasundaram, M. Riedewald, and
41(6):31–44, 2007. J. Gehrke. Hilda: A high-level language for
[18] S. Dar, M. J. Franklin, B. T. Jónsson, D. Srivastava, data-drivenweb applications. In ICDE ’06:
and M. Tan. Semantic data caching and replacement. Proceedings of the 22nd International Conference on
In VLDB ’96: Proceedings of the 22th International Data Engineering, page 32, Washington, DC, USA,
Conference on Very Large Data Bases, pages 330–341, 2006. IEEE Computer Society.
San Francisco, CA, USA, 1996.
[19] P. M. Deshpande, K. Ramasamy, A. Shukla, and J. F.
Naughton. Caching multidimensional queries using
chunks. In SIGMOD ’98: Proceedings of the 1998
ACM SIGMOD international conference on
Management of data, pages 259–270, New York, NY,
USA, 1998. ACM.
[20] F. Duarte, B. Mattos, A. Bestavros, V. Almeida, and
J. Almeida. Traffic characteristics and communication
patterns in blogosphere. In 1st International
Conference on Weblogs and Social Media
(ICWSMâĂŹ06), Boulder, Colorado, USA, March
2007. IEEE Computer Society.
[21] M. J. Franklin, M. J. Carey, and M. Livny. Local disk
caching for client-server database systems. In VLDB
’93: Proceedings of the 19th International Conference