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] > >
