would be great if http-cache will have these hints in its overview documents.
Alin On 17 March 2012 17:50, Jon Moore <[email protected]> wrote: > Hi Robert, > > Naturally, the ultimate answer is: it depends on your scenario! However, I > can perhaps provide some ways of thinking about your cache configuration. > > First, one of your choices will be which HttpCacheStorage implementation(s) > you want to use; there are 3 supported in the distribution: > 1. an in-memory cache; this is the default implementation if you don't > specify an alternative > 2. an EhCache backend; this can be used to build a tiered in-memory and > on-disk cache, and the on-disk can be configured to persist across > application invocations > 3. a memcached backend; this can be used either to keep your JVM heap size > smaller by keeping the cache memory out-of-process, or as a shared > memcached pool for a cluster of application servers, for example > > Now, because the CachingHttpClient is a decorator, you can actually use > multiple of these at the same time by wrapping them one inside the other. > So, for example, you can have a L1 in-memory cache backed by a L2 EhCache > that spills to disk. > > In all cases, you will want to be concerned with the total storage > resources you want to allocate to the cache; EhCache and memcached have > their own configuration for this, but you may want to tweak this for the > in-memory cache if that's what you use. One thing to look at is the maximum > response body size that you'll cache, which currently defaults to 8KB; if > you plan on caching responses than that, you'll need to increase this > setting via CacheConfig#setMaxObjectSizeBytes(). > > If your server(s) use the 'stale-while-revalidate' Cache-Control directive, > then you may want to play with > CacheConfig#setAsynchronousWorkerIdleLifetimeSecs(), > CacheConfig#setAsynchronousWorkersCore(), > CacheConfig#setAsynchronousWorkersMax(), and > CacheConfig#setRevalidationQueueSize(), all of which basically control an > underlying thread pool configuration to handle the background validation > requests. These have "safe" defaults, so you may not need to tweak these > until you get into performance tuning. > > Finally, if your origin servers don't set proper Cache-Control headers but > you want to cache the responses anyway, you may want to change > CacheConfig#setHeuristicDefaultLifetime(). Another option for this is to > write another decorator to modify Cache-Control headers on specific > responses that come through, wired up between the CachingHttpClient and the > "real" underlying HttpClient. > > That said, if you just drop an unconfigured CachingHttpClient in, for say, > an API client that gets relatively small, but cacheable responses, you > should hopefully see some immediate benefit just from the in-memory cache. > > Hope that helps, > Jon > > On Sat, Mar 17, 2012 at 10:21 AM, Robert Naczinski < > [email protected]> wrote: > > > Hello, > > > > I want my application use cache, as shown below > > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html > . > > > > Does anyone know the best settings or recommendations for the > > configuration of the cache? > > > > Regards, > > > > Robert > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
