Hi Robert, The caches are not static; if you create new CachingHttpClients with distinct HttpCacheStorages, they will operate independently. The built-in memory cache is likewise a per-CachingHttpClient cache.
Jon On Tue, Mar 20, 2012 at 4:02 AM, Robert Naczinski < [email protected]> wrote: > Hi Jon, > > thank you very much for your detailed response. I will FIRST make the > default implementation and use in-memory cache. > > One question I would have to have: is the cache static or not? I mean: > have each instance of HttpClient own cache or not? > > Regards, > > Roberet > > 2012/3/17 Jon Moore <[email protected]>: > > 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
