home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13g.zip / caching.doc < prev    next >
Text File  |  1999-06-27  |  8KB  |  176 lines
  1. 27 June 1999: SRE-http and caching.
  2.  
  3.  
  4. SRE-http ver 1.3g supports several forms of caching.  This document outlines
  5. what levels of caching may apply to  a request, and what you can do
  6. to increase (or decrease) the extent to which caches answer requests.
  7.  
  8. There are several different sorts of caches that may apply. In decreasing 
  9. universality these include:
  10.  
  11. 1) Proxy server caches.
  12.    For purposes of this discussion, a "proxy server" is any intermediate
  13.    site, somewhere on the web, that may handle a request issued by a client.  
  14.    These sites may store responses, and use these cached responses the next
  15.    time the same request is recieved. When such a stored response is used,
  16.    the origin server is typically not contacted (the origin server does not
  17.    know that the proxy delivered content to a client).
  18.  
  19.       ** Perhaps the principal advantage of http/1.1 (over http/1.0) is the 
  20.       ** attention given to making the web proxy-cache friendly.
  21.  
  22.  
  23. 2) The GoServe cache.
  24.    The GoServe cache consists of a list that matches selectors (the local
  25.    portion of a URI) to filenames. When a request for the same selector
  26.    arrives, GoServe can resolve the request by sending the matched file
  27.    (and a few http/1.0 response headers).  As an option, the GoServe cache
  28.    can "run the filter anyways", which allows the filter to perform post-filter
  29.    actions (such as auditing).
  30.  
  31. 3) The SREPROXY cache.
  32.    SREPROXY is a front-end to SRE-http.  SREPROXY maintains a cache that matches
  33.    selectors to files. These files may be temporary files (say, as generated
  34.    by adding SSI's to an HTML document). In addition, SREPROXY can resolve a 
  35.    few "dynamic" SSIs (such as the current time), and can do a limited amount
  36.    of access control.
  37.  
  38.  
  39. 4) The SSI and !DIR caches.
  40.    SREFILTR (the main filter) maintains a cache for SSI documents (that contains
  41.    "partially compiled" server side includes) and a cache for !DIR requests 
  42.    (that contains directory listing).  These are used when a matching selector 
  43.    is recieved. Note that the SSI cache is often times used as a base to which 
  44.    dynamic SSIs are added; where "dynamic SSIs" refers to information that 
  45.    changes on a request specific basis (i.e; the current time, the client's 
  46.    IP address, and output from INTERPRET SSIs).
  47.  
  48.  
  49. The basic notion behind the use of a cache is to reduce  processing
  50. requirements and bandwidth demands.  Proxy caches are highly effective at
  51. both -- when successful, no communication with the origin server is 
  52. necessary. The GoServe cache does not save bandwidth, but can reduce
  53. server load considerably (by skipping the "call the filter to resolve this
  54. request" step).  SREPROXY is similar -- although it is a filter that has
  55. to be called, it's much smaller and faster then the regular (SREFILTR) 
  56. filter.  Lastly, the SSI and !DIR caches can save a lot of processing for
  57. SSI-including and directory-listing "processor intensive" resources.
  58.  
  59.    
  60. Each of these caches has advantages and disadvantages. 
  61.  
  62.  Proxy Caches:
  63.     Advantages
  64.       * Very fast response times
  65.       * Can completely eliminate load on your server 
  66.       * Helps reduce internet traffic
  67.     Disadvantages
  68.       * Should not be used with actively changing, or access controlled,
  69.         resources
  70.       * Should not be used when accurate auditing is important
  71.  
  72.   GoServe Cache
  73.     Advantages:
  74.       * Response times are very fast (compared with SREFILTR)
  75.       * Minimizes load on your server 
  76.     Disadvantages:
  77.       * Should not be used with actively changing, or access controlled,
  78.         resources
  79.       * Currently, the GoServe cache is http/1.0, but not http/1.1,
  80.         compliant.
  81.  
  82.    SREPROXY cache:
  83.     Advantages:
  84.       * Response times are fast
  85.       * Can reduce load (since SREPROXY is smaller then SREFILTR)
  86.       * Can be used with changing and access controlled resources
  87.       * No loss of functionality -- when in doubt, SREFILTR is used
  88.     Disadvantages:
  89.       * Introduces another round of processing -- if a request does not
  90.         match a cached entry, the net result is to diminish response time.
  91.       * On occasion, a stale response may be returned 
  92.  
  93.     SSI and !DIR caches:
  94.       Advantages:
  95.         * Fully functional -- changes are immediately detected
  96.         * Greatly reduces processing for a subset of otherwise processing
  97.           intensive requests.
  98.       Disadvantages:
  99.         * On rare occassions, stale requests may be returned
  100.  
  101.  
  102. It should be stressed that these caches are not mutually exclusive.  In fact, 
  103. a typical scenario would have the three higher caches (proxy servers, GoServe, 
  104. and SREPROXY) examining a request, which may then be resolved via the use of   
  105. the SSI (or !DIR) cache.  Thus, optimal performance is acheived by using each   
  106. cache in a complementary fashion.
  107.  
  108. The following discusses some tricks and techniques you can use.
  109.  
  110. Proxy Servers:
  111.  
  112.   * If you have a very dynamic site of non-access controlled resources, 
  113.     transparency concerns may override the desire for faster throughput.
  114.     That is, you might want to suppress all proxy caching.
  115.     This can be accomplished by setting proxy_cache=0 (in INIT_STA.80)
  116.     Alternatively, you can use proxy_cache to "force revalidation"
  117.     (see the description of the PROXY_CACHE variable in INITFILT.DOC for
  118.     more details).
  119.  
  120.   * SRE-http will automatically supress proxy caching whenever access controls
  121.     (such as CHECKLOG and ALLOW_ACCESS), or dynamic SSIs, apply to the resource.  
  122.     If  desired, you can explicitily allow these resources to be cached -- just
  123.     include a CACHE (or CACHE*) "permission" in a selector-specific entry
  124.     in ACCESS.IN (or in ATTRIBS.CFG). Alternatively, resources listed 
  125.     as PUBLIC URLS (using PUBURLS.IN or ATTRIBS.CFG) are assumed to 
  126.     be cachable by proxy caches.
  127.  
  128.   * See HITMETER.DOC for hints on how to resolve problems associated
  129.     with accurate metering of hits when proxy servers may be active.
  130.  
  131. GoServe cache:
  132.    
  133.   * If you do enable the GoServe cache, be aware that it uses an http/1.0
  134.     response algorithim.  Thus, your site will sometimes return http/1.1
  135.     responses, and sometimes http/1.0 responses.  Although this is not
  136.     fatal, it may have strange impacts (and it's somewhat asthetically 
  137.     displeasing). 
  138.  
  139.     Therefore, SRE-http will only use the GoServe cache (that is, allow a
  140.     request to be cached by GoServe) when a CACHE* permission exists.
  141.  
  142.     Alternatively, resources listed as LITERAL_NORECORD PUBLIC URLS 
  143.     (in PUBLURL.IN) are assumed to be cachable by the GoServe cache.
  144.  
  145.    * In general, we recommend using the GoServe cache only for resources that
  146.      you do not care to audit (such as backgrounds and icons).  In this vein,
  147.      we recommend checking the "do not call filter" GoServe caching option.
  148.  
  149.    * Future releases of GoServe may upgrade the GoServe cache, so that it 
  150.      returns  appropriate http/1.1 response headers.
  151.  
  152.    * The GoServe cache ignores TE: request headers.
  153.  
  154. SREPROXY:
  155.  
  156.    * If your site is highly access controlled, or consists primarily of dynamic
  157.      HTML documents (with lots of SSIs') or addons/cgi-bin scripts, then use 
  158.      of SREPROXY may hurt (increase) response times.
  159.    * NUSTATUS contains an option that will display simple statistics on
  160.      the proportion of requests satisfied by SREPROXY.
  161.    * SREPROXY.DOC contains a detailed discussion on how to use SREPROXY.
  162.    * If SREPROXY detects a TE: GZIP request header, it will NOT resolve
  163.      the request.
  164.  
  165.  
  166. SSI and !DIR caches:
  167.  
  168.    * There is almost no reason not to use these caches....
  169.      the exceptions being:
  170.         i) You have lots of HTML documents, and not much extra disk space
  171.        ii) Your documents change rapidly (have lots of dynamic SSIs).
  172.       iii) HTML files are contantly being edited, added, and removed.
  173.  
  174.  
  175.  
  176.