Comparing SPS SP1 Caching with Accelerator Caching
Here is a brief overview of some of the differences/additions between
Accelerator Caching and SPS SP1 Caching:
- Accelerator’s architecture enables very low latency hit
processing
The interception mechanism implemented as a filter allows us to respond to
cache hits in a small number of milliseconds, which is very small compared to
any form of round trip to ASP, for example. This reduces the latency of
everything we do considerably and has other benefits outlined below.
- Accelerator caches Webstore items (in addition to Dashboard
renditions)
When accessed, we place a copy of a Webstore item (document)
in a carefully controlled file-system directory, applying the same ACLs as in
Webstore to that document. On subsequent hits (after authenticated access
checks) this allows the document to be served up by the highly optimized IIS
static file delivery mechanism. This allows us to avoid the overhead of
entering the SPS .dll or ASP at all to fetch the document, which can take
time, even if simply delivering a 304 (not modified) response. Webstore cache entries are always removed when WebDAV
requests are encountered that may change their validity (more below).
- Different Dashboard Renditions for Different Sets of Users
Caching in SP1 for Dashboards
can have the cascading limitation that the first user to access a Dashboard
defines the renditions for subsequent users accessing the Dashboard - which is
often not what is desired. Accelerator provides the ability to match a
Dashboard rendition to the appropriate user based on security equivalence
groups. So, for example, you don't need to move the management Dashboard from
the home page since only users with appropriate permissions will get the
renditions with those links on it. Similarly for any sub-Dashboards with
differing security settings or other equivalent situations. We also honor
"PerUser" renditions of Dashboards enabling the result of almost any
configuration of Parts to be cached.
We do all this by computing a "signature" for a
cached Dashboard rendition comprised of a number of discriminants, which
include security, browser type, accept-language, querystrings, and so on. All
elements of a signature must match before we consider it a "cache hit". There
is also a demo of this on the site called: "Can
different users share a cached Dashboard rendition?"
- Event driven cache invalidation (in addition to timeouts)
For all cached Webstore items and for certain cached WebPart
renditions, Accelerator has the ability to invalidate cache entries based on
WebDAV activity it encounters that would change the existence, content, or
security of that cached item. For Webstore items, this is relatively
straight-forward and we adopted a pessimistic algorithm: any access that could
result in a change prompts a cache removal.
For Dashboards and their constituent WebPart renditions, the
problem is a bit more complex. First, whenever the composition or security of
a Dashboard (or any of its constituent Parts) changes, all Dashboard
renditions for that Dashboard are invalidated (removed from the cache). But,
the more interesting case is for the output (renditions) from the WebParts.
What Accelerator provides is a mechanism by which a WebPart can define a
"dependency" for a particular Webstore folder. Once a dependency is defined,
whenever the contents or security of the folder or its contents changes, all
Dashboard renditions for Dashboards containing that Part are invalidated.
Examples of standard SPS Parts for which we provide
dependency definitions include: Folder Items.vbs, where the dependent folder
is defined by %DataURL%; and News.vbs, where the dependent folder is defined
by the folder pointed to by the Workspace property "urn:schemas-microsoft-com:workspace#NewsFolder".
In addition to all this, you can specify timeout values
beyond which cache entries will never exist (the cache entry is invalidated
either because something changed [the event] or the timeout period passed).
There are some WebParts where the invalidation events cannot be defined (e.g.
querying some non-webstore database, etc.). In these cases, we simply follow
the timeout mechanism if caching is enabled for those parts.
The benefit of this event-based invalidation is a much more
coherent cache (less stale entries) and the ability to consider fairly large
timeout values since they will be invalidated when activity dictates they
should. You can see some of this work in the video on the site called “More
details about Dashboard cache invalidation”.
- Lower Server CPU utilization
As you can probably deduce from how it works, the CPU demand
on the server when simply handing out static files can be substantially
reduced vs. running almost any code, such as a round trip to an ASP
application. We have found this to be true (of course) on sites that were not
running SP1 caching - and on sites where SP1 caching was on, everything was
public, and, in fact, supporting image files (gif, jpgs, etc.) for the custom
Parts were located in a separate non-SPS virtual directory. This can become
particularly important when the number of concurrent users starts to get
interestingly high. You can see some of this on the demo video on the site
called "Does caching help the server load?" - although the site shown does not
have Full-Page caching turned on.
There are undoubtedly some SPS sites that use SP1 caching that
will not need these additional benefits - but it is likely that many would
benefit from them. Also, Accelerator caching can be used complementary to SP1
caching. In many cases, using both facilities is a good answer. For example, if
the restrictions required by SP1 caching have been accommodated and result in a
site that matches the users’ needs. In other cases, where the benefits of
security mapping and event driven invalidation are critical, using Accelerator
alone can be a good answer.
|