\chapter{Conclusion and Future Work}
\label{cha:conclusion}

Application-level caching is a powerful technique for improving the
performance of web applications. These caches store higher-level
objects produced using a combination of database queries and
application-level computation. Accordingly, these caches have the
flexibility to be used in many different applications, from caching
the results of individual database queries to entire generated web
pages -- and, importantly, various stages of processing in between.
Application-level caches can therefore address two types of
performance bottlenecks in web applications. They can reduce the load
on the database layer -- often dramatically, as caching complex
objects can eliminate the need for multiple database queries. They can
also reduce the load on application servers, which database-level
caching and replication systems cannot address.

\section{Contributions}

In this thesis, we have introduced a new application-level cache,
\txcache. \txcache is able to cache the results of arbitrary application
computations, retaining the flexibility described above. \txcache
improves on existing application-level caches in three ways.

First, \txcache provides a simple programming model: cacheable
functions. Rather than requiring application developers to explicitly
identify and access data in the cache -- the standard interface for
most application-level caches -- \txcache simply asks application
developers to identify functions whose results should be cached. The
\txcache system then automatically caches the results of that
function. The application developer is no longer responsible for
naming or invalidating cached data, both of which we have seen to be a
source of application bugs. \txcache implements its programming model
using a new cache library. It avoids the need for explicit
invalidations by using invalidation tags and invalidation locks, new
mechanisms for detecting and tracking data dependencies.

Second, \txcache provides support for transactions. It guarantees that
all data seen by the application within a transaction reflects a
consistent view of the database state, whether it is accessed directly
from the database or through cached objects. This guarantee can
prevent exposing anomalous data to the user, allowing
application-level caching to be used by applications that require
strict isolation between transactions -- a class of applications that
were previously unable to use application-level caches. Even for other
applications, transaction isolation can simplify development. \txcache
ensures transactional consistency by tracking the validity interval of
every object in the cache and database.

Finally, \txcache provides a consistency model where transactions can
see slightly stale data, subject to application-specified freshness
requirements. However, it still guarantees that each transaction sees
a consistent view of the data. As we have seen, when applications can
tolerate even a few seconds of stale data, it improves the
effectiveness of the cache significantly by allowing objects that are
frequently modified to remain useful. \txcache chooses which snapshot
to use for a given transaction using a lazy timestamp selection
protocol that takes into account which data versions are available in
the cache.

To our knowledge, \txcache is the first system to provide either
automatic cache management or whole-system transaction support in a
cache capable of storing arbitrary application-computed values.

\section{Future Work}

Scalability is a major challenge for developers building web sites
that handle requests from millions of users. Application-level caches
are one of many techniques that are used to address this
challenge. Deploying a system like \txcache at large scale -- say, one
comparable to Facebook's \memcached deployment with thousands of cache
servers and a database partitioned over thousands of cache nodes --
presents new challenges.

The most likely barrier to scalability in our design is the
invalidation system. Our invalidation mechanism requires the storage
layer to broadcast the invalidation stream to all cache nodes. Each
cache node, therefore, receives a list of invalidation tags for every
update processed by the storage layer. In a large deployment, the cost
of distributing and processing this stream might prove to be
excessive: each cache server must process every invalidation message
even if only to determine that it has no objects affected by the
invalidation.

One possible approach to improving the scalability of the invalidation
mechanism is to use a publish/subscribe multicast system. Such a
system could allow invalidation messages to be sent only to relevant
cache nodes. This approach has previously been used to efficiently
distribute invalidations in a scalable query cache
system~\cite{garrod08:_scalab_query_resul_cachin_for_web_applic}. A
challenge to this approach is that cached objects are distributed
among cache nodes without any locality. That is, the cache objects
that depend on a particular database object are not likely to be
stored on the same cache server. Indeed, if many cached objects depend
on a particular database object, they might be distributed across most
of the cache servers; any invalidations for the associated
invalidation tag would need to be distributed to all of them.

Thinking more generally about scalability, developments in scalable
storage systems could have an impact on application-level
caching. Classically, the backing store for web applications has been
a relational database. In database-backed applications, one common use
for application-level caches like \memcached is to store database
tuples, as the lightweight in-memory cache can provide faster
responses and greater scalability than the database. A recent trend
is that developers are increasingly
turning to storage systems
%designed to provide
%similar scalability and response times,
such as partitioned in-memory
databases~\cite{stonebraker07:_archit_era} or key-value
stores~\cite{decandia07:_dynam,redis,memcachedb,escriva11:_hyper,chang06:_bigtab}. Given
that these storage systems are designed to provide similar scalability
and latency advantages, will application-level caching continue to be
useful? We believe that it will, as the ability to cache intermediate
results of application-level computations can substantially reduce the
load on application servers. Indeed, application-level caching might
prove even more useful in applications that use a key-value store as
their persistent storage, as they will need to do more of their
processing in the application layer.


\section{Conclusion}

\txcache is an application-level cache designed to be easy to
integrate into new or existing applications. Towards this end, it
provides higher-level abstractions designed to simplify application
development: the cacheable-function programming model simplifies cache
management, and the cache's transaction support simplifies reasoning
about concurrency. In this respect, \txcache differs from typical
application-level caches that optimize for a simple cache
implementation but require increased complexity in the applications
that use the cache. Our experiments with the \rubis benchmark show
that \txcache is effective at improving the performance of a web
application, and that transactional consistency and invalidation
support impose only a minor performance penalty -- suggesting that
providing higher-level cache abstractions does not have to come with a
performance cost.


%%% Local Variables: 
%%% mode: latex
%%% TeX-command-default: "Make"
%%% TeX-PDF-mode: t
%%% TeX-master: "main.tex"
%%% End: 

%  LocalWords:  transactional scalability timestamp cacheable
%  LocalWords:  invalidations multicast scalable