|1Cache Configuration|

|^ WASD HTTPd provides an optional, configurable, monitorable file data and
revision time cache. File data, so that requests for documents can be fulfilled
without reference to the underlying file system, potentially reducing request
latency and more importantly improving overall server performance and system
impact, and file revision time, so that requests specifying an
"If-Modified-Since:" header can also benefit from the above.  Files are cached
using a hash derived from the VMS file-system path equivalent generated during
the mapping process (i.e. represents the file name) but before any actual RMS
activity.  WASD can also cache the content of responses from non-file sources. 
This can be useful for reducing the system impact of frequently accessed,
dynamically generated, but otherwise relatively static pages.  These sources
are cached using a hash derived from virtual service connected to and the
request URI.

|0Why Implement Caching?|

|^ Caching, in concept, attempts to improve performance by keeping data in
storage that is faster to access than the usual location. The performance
improvement can be assessed in three basic ways; reduction of

|bullet#|
|item| response when accessing the data (latency and transfer time)
|item| processing involved (CPU cycles)
|item| impact on the usual storage location (file system I/O)
|!bullet|

|^ This cache is provided to address all three. Where networks are
particularly responsive a reduction in request latency can often be noticeable.
It is also suggested a cache "hit" may consume less CPU cycles than the
equivalent access to the (notoriously expensive) VMS file system. Where
servers are particularly busy or where disk subsystems particularly loaded a
reduction in the need to access the file system can significantly improve
performance while simultaneously reducing the impact of the server on other
system activities.

|^ A comparison between cached and non-cached performance is provided in
in the "Server Performance" section.

|0Terminology|

|table|
|~_ |: Term|: Description
|~
|~#* |. hit |. Refers to a request path being found in cache. If the data
is still valid the request can be supplied from cache.
|~ |. flushing |. Occurs when the cache becomes full, with older, less
frequently used cache entries being removed from the cache and replaced by
other files.
|~ |. loading |. Refers to reading the contents of a file into cache memory.
|~ |. permanent |. These entries are loaded once and remain in the cache
until it is explicitly purged by the administrator or the the server is
restarted. They are not flushed or revalidated.
|~ |. revalidate |. Compare the cache entrys size and modification
date-time to the file it represents in the file-system.  Obviously a difference
indicates the content has changed.
|~ |. valid |. The file from which the cached data was
originally read has not had its revision date changed (the implication being
the file contents have not changed).
|~ |. volatile |. Entries have the original file periodically checked for
modification  and are reloaded if necessary.  They can also be flushed if
demand for space requires it.
|!table|

|2Non-File Content Caching|

|^ The WASD cache was originally provided to reduce file-system access (a
somewhat expensive activity under VMS).  With the expansion in the use of
dynamically generated page content (e.g. PHP, Perl, Python) there is an obvious
need to reduce the  system impact of some of these activities.  While many such
responses have content specific to the individual request a large number are
also generated as general site pages, perhaps with simple time or date
components, or other periodic information.  Non-file caching is intended for
this type of dynamic content.

|^ Revalidation of non-file content is fraught with a number of issues and so
is not provided.  Instead the cache entry is flushed on expiry of the
[CacheValidateSeconds], or as otherwise specified by path mapping, and the
request is serviced by the content source (script, PHP, Perl, etc.) with the
generated response being freshly cached. All of the considerations described in
|link|Cache Content Validation| apply equally to file and non-file content.

|0Controlling Non-File Content Caching|
|^ Determining which non-file content is cached and which not, and how long
before flushing, is done using mapping rules (|link|SET Rule||).  The source of
non-file cache content is specified using one or a combination of the following
SET rules against general or specific paths.

|simple#|

|item| |*cache=[no]cgi | from Common Gateway Interface (CGI) script response
|item| |*cache=[no]file | from the file system (default and pre-8.4 cache behaviour)
|item| |*cache=[no]net | caches the full data stream irrespective of the source
|item| |*cache=[no]nph | full stream from Non-Parse Header (NPH) script response
|item| |*cache=[no]query | cache requests with query strings (|*use with care||)
|item| |*cache=[no]script | both CGI and NPH script responses
|item| |*cache=[no]ssi | from Server-Side Includes (SSI) documents
|!simple|

|^ A good understanding of site requirements and dynamic content sources, 
along with considerable care in specifying cache path SETings, is required to
cache dynamic content effectively.  It is especially important to get the
content revalidation period appropriate to the content of the pages.  This is
specified using the following path SETings.

|simple#|
|item| |*cache=expires=0 | cancels any expiry
|item| |*cache=expires=DAY | expires when the day changes
|item| |*cache=expires=HOUR | when the clock hour changes
|item| |*cache=expires=MINUTE | when the clock minute changes
|item| |*cache=expires=<hh:mm:ss> | expires after the specified period in the cache
|!simple|

|^ For example.  To cache the content of PHP-generated home pages that
contain a  time-of-day clock, resolving down to the minute, would require a
mapping rule similar to the following.

|code|
set /**/index.php cache=cgi cache=expires=minute
|!code|

|2Permanent and Volatile|

|^ The WASD file cache provides for some resources to be permanently cached
while others are allowed to be moved into and out of the cache according to
demand.  Most sites have at least some files that are fundamental components of
the site's pages, are rarely modified, commonly accessed, and therefore should
be permanently available from cache.  Other files are modified on a regular or
ad hoc basis and may experience fluctuations in demand.  These more volatile
resources should be cached based on current demand.

|^ Volatile caching is the default with the site administrator using mapping
rules to indicate to the server which resources on which paths should be
permanently cached (|link|Cache Configuration||).

|^ Although permanent and volatile entries share the same cache structure and
are therefore subject to the configuration's maximum number of cache entries,
the memory used store the cached file data is derived from separate pools.  The
total size of all volatile entries data is constrained by configuration.  In
contrast there is no configuration limit placed on the quantity of data that
can be cached by permanent entries.  One of the purposes of the permanent
aspect of the cache is to allow the site administrator considerable discretion
in the configuration of the site's low-latency resources, no matter how large
or small that might be.  Of course there is the ultimate constraint of server
process and system virtual memory limits on this activity.  It should also be
kept in mind that unless sufficient physical memory is available to keep such
cached content in-memory the site may only end up trading file-system I/O for
page file I/O.

|2Cache Suitability Considerations|

|^ A cache is not always of benefit!  the cost may outweigh the return.

|^ Any cache's efficiencies can only occur where subsets of data are
consistently being demanded. Although these subsets may change slowly over time
a consistent and rapidly changing aggregate of requests lose the benefit of
more readily accessible data to the overhead of cache management, due to the
constant and continuous flushing and reloading of cache data. This server's
cache is no different, it will only improve performance if the site experiences
some consistency in the files requested. For sites that have only a small
percentage of files being repeatedly requested it is probably better that the
cache be disabled.  The other major consideration is available system memory.
On a system where memory demand is high there is little value in having cache
memory sitting in page space, trading disk I/O and latency for paging I/O and
latency.  On memory-challenged systems cache is probably best disabled.

|^ To help assessment of the cache's efficiency for any given site monitor the
Server Administration facility's cache report.

|^ Two sets of data provide complementary information, cache activity and
file request profile.

|bullet|

|item| |*Activity Data||

|^ This summarizes the cache search behaviour, in particular that of the hash
table.

|^ The "searched" item, indicates the number of times the cache has
been searched. Most importantly, this may include paths that can never be
cached because they represent non-file requests (e.g. directory listings).
Requests involving scripts, and some others, never attempt a cache search.

|^ The "hit" item, indicates the number of times the hash table
directly provided a cached path.  This is very efficient.

|^ The "miss" item, indicates the number of times the hash table
directly indicated a path was not cached.  This is decisive and is also very
efficient.

|^ The "collision" item, indicates the number of times multiple paths
resolved to the same hash table entry. Collisions require further processing
and are far less efficient. The sub-items, "collision hits" and
"collision misses" indicate the number of times that further processing
resulted in a found or not-found cache item.

|^ A large number of cache misses compared to searches may only indicate a
large number of non-cacheable requests and so depending on that further datum
is not of great concern. A large proportion of collisions (say greater than
12.5%) is however, indicating either the hash table size needs increasing
(1024 should be considered a minimum) or the hashing algorithm in the software
need reviewing :-)

|item| |*Files Data||

|^ This summarizes the site's file request profile.

|^ With the "loads not hit" item, the count represents the cumulative
number of files loaded but never subsequently hit. If this percentage is high
it means most files loaded are never hit, indicating the site's request
profile is possibly unsuitable for caching.

|^ The item "hits" respresents the cumulative, total number of hits
against the cumulative, total number of loads. The percentage here can range
from zero to many thousands of percent :-) with less than 100% indicating poor
cache performance and from 200% upwards better and good performance. The items
"1-9", "10-99" and "100+" show the count and percentage
of total hits that occured when a given entry had experienced hits within that
range (e.g. if an entry has had 8 previous hits, the ninth increments the
"1-9" item whereas the tenth and eleventh increments the "10-99"
item, etc.)

|^ Other considerations also apply when assessing the benefit of having a
cache. For example, a high number and percentage of hits can be generated
while the percentage of "loads not hit" could be in the also be very
high. The explanation for this would be one or two frequently requested files
being hit while most others are loaded, never hit, and flushed as other files
request cache space. In situations such as this it is difficult to judge
whether cache processing is improving performance or just adding overhead.

|!bullet|

|2Cache Content Validation|

|^ The cache will automatically revalidate the volatile entry file data after a
specified  number of seconds ([CacheValidateSeconds] configuration parameter),
by comparing the original file revision time to the current revision time.  If
different the file contents have changed and the cache contents declared
invalid.  If found invalid the file transfer then continues outside of the
cache with the new contents being concurrently reloaded into the cache. 
Permanent entries are not subject to revalidation and the associated reloading.

|^ Cache validation is also always performed if the request uses
"Cache-Control:" with |/no-cache||, |/no-store| or |/max-age=0| attributes
(HTTP/1.1 directive), or if a "Pragma: no-cache" field (HTTP/1.0 directive). 
These request directives are often associated with a browser agent |/reload
page| function. Hence there is no need for any explicit flushing of the cache
under normal operation. If a document does not immediately reflect any changes
made to it (i.e. validation time has not been reached) validation (and
consequent reload) can be "forced" with a browser reload.  Permanent entries
are also not subject to this source of revalidation.  The configuration
directive [CacheGuardPeriod] limits this form of revalidation when used within
the specified period since last revalidated.  It has a default value of fifteen
seconds.

|^ If a site's contents are relatively static the validation seconds could be
set to an extended period (say 3600 seconds, one hour) and then rely on an
explicit "reload" to force validation of a changed file.

|^ The entire cache may be purged of cached data, both volatile and permanent
entries, either from the Server Administration facility or using command line
server control.

|code|
$ HTTPD /DO=CACHE=PURGE
|!code|

|2Cache Configuration|

|^ The cache is controlled using WASD_CONFIG_GLOBAL configuration file and WASD_CONFIG_MAP
mapping file directives.  A number of parameters control the basics of cache
behaviour.

|bullet|

|item| |*.[Cache] |-| |
Enables and disables caching.

|item| |*.[CacheEntriesMax]|
and |*.[CacheTotalKBytesMax] |-| |
Provide growth limits to cache expansion.  Maximum entries limits the number of
files loaded into the cache before entries begin to be reused (flushing the
original contents).  Maximum total kilobytes allocated to the cache provides a
ceiling on the memory consumed. These parameters operate to limit each other
(i.e. if one reaches its limit before the other, the other will not grow
further either).

|item| |*.[CacheFileKBytesMax] |-| |
Provides a limit on file size (in kilobytes).  Files larger than the specified
limit will not be cached.  This may be overridden on a per-path basis using the
|/set cache=max=<integer>| mapping rule (see below).

|item| |*.[CacheFrequentHits]| and
|*.[CacheFrequentSeconds] |-| |
Attempt to reduce unproductive reuse of cache entries by providing the cache
with some indication of what constitutes a frequently hit entry. If it is
frequently hit then it should not be immediately reused when there is a demand
for cache space. The first parameter sets the number of hits an entry must
sustain before being a candidate for |/CacheFrequentSeconds| assessment. If a
file has been hit at least |/CacheFrequentHits| times in total and the last hit
was within the number of seconds set by |/CacheFrequentSeconds| it will not be
flushed and reused. If it has not been hit within the specified period it will
be reused.

|item| |*.[CacheGuardPeriod] |-| |
Prevents browser initiated content revalidation described above
(|link|Cache Content Validation||).  It is provided to help limit unnecessary
file-system activity.  The default is fifteen seconds.

|item| |*.[CacheEntriesMax] |-| | |/.(obsolete)|

|item| |*.[CacheValidateSeconds] |-| |
The interval after which a cache entry's original, content revision time is
revalidated against the file's current revision time.  If not the same the
contents are declared invalid and reloaded.  Setting this to a greater period
reduces disk I/O but revised files may not be obvious within an acceptable
timer unless a revalidation is forced with a |/reload||.  Permanent entries are
not subject to validation.

|!bullet|

|0Mapping Rules||

|^ Mapping rules (|link|SET Rule||) allow further tailoring of cache behaviour
based on request (file) path.  Those files that should be made permanent
entries are indicated using the |/cache=perm| directive.  In the following
example all files in the WASD runtime directories (directory icons, help files,
etc.) are made permanent cache entries at the same time the path is mapped.

|code|
pass /*/-/* /wasd_root/runtime/*/* cache=perm
|!code|

|^ Of course, specified file types as well as specific paths can be mapped in
this way.  Here all files in the site's /help/ path are made permanent
entries except those having a .PS type (PostScript documents).

|code|
set /help/* cache=perm
set /help/*.ps cache=noperm
|!code|

|^ The configuration directive [CacheFileKBytesMax] puts a limit on individual
file size.  Those exceeding that limit are considered too large and not cached. 
It is possible to override this general constraint by specifying a maximum size
(in kilobytes) on a per-path basis.

|code|
set /help/examples*.jpg cache=max=128
set /cai/*.mpg cache=max=2048 cache=perm
|!code|

|^ Caching may be disabled and/or enabled for specified paths and subpaths.

|code|
set /web/* cache=none
set /web/icons/* cache
|!code|

|2Cache Control|

|^ The cache may be enabled, disabled and purged from the Server
Administration facility. In addition the same control may be exercised from the
command-line using 

|code|
$ HTTPD /DO=CACHE=ON
$ HTTPD /DO=CACHE=OFF
$ HTTPD /DO=CACHE=PURGE
|!code|

|^ If cache parameters are altered in the configuration file the server must
be restarted to put these into effect.  Disabling the cache on an ad hoc basis
(from menu or command line) does not alter the contents in any way so it can
merely be reenabled with use of the cache's previous contents resuming.  In
this way comparisions between the two environments may more easily be made.

|2Circumventing The Cache|

|^ There are often good reasons for bypassing or avoiding the cache.  For
instance, where a document is being refreshed within the cache revalidation
period specified by [CacheValidateSeconds] (|link|Cache Content Validation||). 
There are two mechanisms available for  bypassing or invalidating the file
cache.

|number|

|item| This directs the server to always get the file from the file-system.
|code|
SET /path/not/to/cache/* cache=none
|!code|

|item| Specify a version component when requesting the file.  WASD never caches a
file if the request contains a version component.  It does not need to be a
full version number, a semi-colon is sufficient.  For example:
|code|
/wasd_root/robots.txt;
|!code|

|!number|