home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13g.zip / hitmeter.doc < prev    next >
Text File  |  1999-06-27  |  7KB  |  153 lines
  1. 27 June 1999.   
  2.  
  3.                 Hit-Metering and Proxy Caches under SRE-http
  4.  
  5.  
  6. I) Introduction
  7.  
  8. One of the more significant improvements offered by the http/1.1 protocol
  9. is enhanced support for caching by proxy servers.  Caching is defined
  10. as the resolution of requests by "caches" on "proxy servers"
  11. lying between the requesting client and your site. By reducing
  12. network traffic, and by reducing the load on your server,
  13. caching can provide significant improvements in throughput.
  14. This  benefit extends beyond one's own site, since a reduction
  15. in network traffic improves throughput for everyone else using
  16. the internet.
  17.  
  18. Caching is not without drawbacks. First and foremost, some
  19. resources should not be cached. These include highly dynamic 
  20. pages, and requests for access-controlled resources.  SRE-http
  21. recognizes these cases, and will by default suppress caching in
  22. such cases.
  23.  
  24. Another drawback, which is not as serious but is more difficult to solve,
  25. is the conflict between caching and accurate auditing.  Simply put,
  26. a request that a cache handles is a request that your site never
  27. finds out about.  If it's important to have an accurate count
  28. of how many times a resource has been distributed, caching is a problem.
  29. Recognizing this, SRE-http allows you to disable proxy caching, 
  30. either by default, or on a selector specific basis.
  31.  
  32. But what about when you don't want to loose the benefits of caching,
  33. but do want some measure, even if it is not perfect, of how many hits 
  34. are being handled by caches?  This document describes one such
  35. method, based on the use of an http extension proposed in
  36. RFC 2227 -- the use of hit-meter trees.   
  37.  
  38. This solution requires that proxy servers be willing to report hit
  39. information back to your site. Thus, the success of this solution (hence
  40. the accuracy of your hits) depends on it's extent of implementation.
  41. At this writing, most proxy servers do not support hit meter trees.
  42. However, as http/1.1 becomes more widely adopted, this should improve.
  43.  
  44. Therefore:
  45.  
  46.   SRE-http's support of hit-meter trees is partially experimental, and 
  47.   partially as a way to encourage it's broader adoption.
  48.  
  49. The rest of this document describes how SRE-http implements hit-meter trees.
  50.  
  51. Notes:
  52.  
  53.   * For further description of SRE-http and caching, see CACHING.DOC
  54.   * For details on how to control the default level of caching, see 
  55.     the description of the PROXY_CACHE variable in INITFILT.DOC.
  56.   * For details on how to control caching on a selector-specific basis,
  57.     see the IN_FILES.DOC for a description of the CACHE and  NOCACHE 
  58.     selector-specific permissions (that can be set in  ACCESS.IN or in
  59.     ATTRIBS.CFG); and see the description of PUBLIC_URLS in PUBURLS.DOC.
  60.  
  61.    
  62. II) Enabling the hit-meter tree
  63.  
  64.  
  65. Due to it's experimental nature, use of a hit-meter tree is on a 
  66. selector-specific basis. To do this, you must specify a Meter=
  67. "selector-specific advanced option" -- you can use the intermediate
  68. configurator to do this.
  69.  
  70. Meter= can take a list of arguments.  The simplest case, which
  71. is basically all that SRE-http supports, is to use no arguments.  
  72. Otherwise, the arguments can be used for a variety of purposes, 
  73. such as instructing proxies to limit the duration of cache entries.   
  74. If you are interested in such fine control, please see RFC 2227.
  75.  
  76. For example, assuming you use ATTRIBS.CFG to set selector-specific attributes:
  77.  
  78.   Realm: distrib
  79.   rule: distrib/myfile1.zip
  80.   permissions: cache
  81.   Option: meter=
  82.  
  83. instructs SRE-http to (whenever possible) enable a hit-meter tree for
  84. requests for /distrib/myfile1.zip. Note that the Permissions: line
  85. may not be necessary, it's inclusion guarantees that SRE-http will
  86. allow proxy caching -- say, even when access-controls are required of
  87. other resources (SRE-http is conservative, and by default will suppress
  88. caching when access controls are enabled).
  89.  
  90. Notes:
  91.   * ADV_OPTS.DOC describes the various ways of specifying the Meter: 
  92.     selector-specific advanced option.
  93.   * You can use a wildcarded rule to assign a Meter= advanced options to 
  94.     a set of requests.
  95.   * If you specified with optional arguments in the Meter= advanced option,
  96.     they will be included verbatim in the Meter: response header.
  97.  
  98.   * Technical note:
  99.      SRE-http will include a Meter: and a Connection: Meter 
  100.      response header whenever
  101.        a) a Meter= selector specific option has been specified
  102.        b) the client (typically, a proxy server) includes a Meter:
  103.           request header.
  104.      Given the above, the proxy server will retain a count of
  105.      how many requests for this resource have been recieved.
  106.      From time to time, the proxy will send a special HEAD (or
  107.      GET) request containing a Meter: header that includes
  108.      a count of hits it resolved from it's cached version of
  109.      the resource.  Actually, two counts are returned -- 
  110.          the number of times the resource was sent (200 responses), and 
  111.          the number of resource-did-not-change reports (304 responses).
  112.  
  113.  
  114. III) Output nformation
  115.  
  116. Due to the experimental, etc. nature of hit-meter trees, SRE-http does not
  117. incorporate hit-meter tree information at a low level -- the various
  118. auditing databases will not be influenced by this information. 
  119.  
  120. Instead, SRE-http maintains a seperate count file, HITMETER.CNT 
  121. (in the DATA/ subdirectory of the GoServe working directory).  
  122.  
  123. This file contains,  on a selector specific basis:
  124.   * the number of "200" responses from this site
  125.   * the number of "304" response form this site
  126.   * the number of "200" responses by  proxy servers
  127.   * the number of "304" responses by proxy servers
  128.   * the name of the selector
  129. For example:
  130.     121     44     42     12 /distrib/archive/ver13.zip
  131.  
  132. Thus, the total number of requests is the sum of these three numbers.
  133. Furthermore, the first two number should match values recorded in
  134. RECRDALL.CNT and COUNTER.CNT (possibly with small discrepancies, due to 
  135. incomplete requests).
  136.  
  137.  
  138. Notes:
  139.  
  140. * Each selector will have it's own entry; wildcarded entries 
  141.   are not used.
  142. * Only selectors that have a Meter= advanced option appear in HITMETER.CNT.
  143.  
  144. * Technical Note:
  145.     HITMETER.CNT is modified by SRE-http's post-filter daemon (the same
  146.     daemon that maintains the other LOG files). Thus, if you suppress 
  147.     "post-filtering", hit-metering will not be supported.  A simple
  148.     caching scheme is used to minimize disk writes, at any given
  149.     instant,the values in HITMETER.CNT. This is a trivial concern, given
  150.     the transient reporting (perhaps once a day) of proxy servers along
  151.     a hit meter tree.
  152.  
  153.