You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Robert Naczinski <ro...@googlemail.com> on 2012/03/17 15:21:11 UTC
Best practice for caching configuration
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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
Hi,
By default, the cache is configured as a "public" (shared) cache, meaning
it will not cache responses that are marked as "Cache-Control: private" or
ones without explicit cacheability headers that came from requests with
Authorization headers, per RFC2616. It doesn't treat Set-Cookie or Cookie
headers any differently from other headers, so if your server sets
"Cache-Control: private" or "Cache-Control: public; Vary: Cookie" then you
won't have different users seeing cached responses from other users.
If your application only has one logical user, though, then you can
configure the cache to be a "private" (non-shared) cache by updating its
CacheConfig.
Jon
On Thu, Mar 22, 2012 at 10:05 AM, kim young ill <kh...@googlemail.com>wrote:
> hi there, thax alot for the explaination
> how the cache module handes setCookie headers ? in case httpclient (with
> cache-module enabled) is working as proxy & shared between different
> browser-instances ?
>
>
> On Tue, Mar 20, 2012 at 9:59 PM, Jon Moore <jo...@apache.org> wrote:
>
> > Actually, those recommendations are already in there too, they are just
> > perhaps worded differently. But if you think my recent explanation was
> > clearer, perhaps I can rewrite them. :)
> >
> > Jon
> >
> > On Tue, Mar 20, 2012 at 3:23 PM, Vasile Alin <alinachegalati@gmail.com
> > >wrote:
> >
> > > Thanks Jon for considering my proposal.
> > >
> > > Just checked the links (again) and yes, most of your recommendations
> are
> > > already available; however the rest of your hints, such as the
> > > "stale-while-revalidate" section or ehcache vs memcache would fit in
> > > nicely.
> > >
> > > Alin
> > >
> > > On 20 March 2012 16:44, Jon Moore <jo...@apache.org> wrote:
> > >
> > > > Hi Alin,
> > > >
> > > > Actually, as it turns out, much of this information is already in the
> > > > online docs:
> > > >
> > > >
> > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html
> > > >
> > > >
> > >
> >
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html#storage
> > > >
> > > > Jon
> > > >
> > > > On Tue, Mar 20, 2012 at 8:19 AM, Jon Moore <jo...@apache.org> wrote:
> > > >
> > > > > Hi Alin,
> > > > >
> > > > > Great suggestion - I'll look into updating the documents for the
> 4.2
> > > > > release.
> > > > >
> > > > > Jon
> > > > >
> > > > >
> > > > > On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <
> > alinachegalati@gmail.com
> > > > >wrote:
> > > > >
> > > > >> would be great if http-cache will have these hints in its overview
> > > > >> documents.
> > > > >>
> > > > >> Alin
> > > > >>
> > > > >> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> > > > >> > robert.naczinski@googlemail.com> 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:
> > > httpclient-users-unsubscribe@hc.apache.org
> > > > >> > > For additional commands, e-mail:
> > > > httpclient-users-help@hc.apache.org
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Best practice for caching configuration
Posted by kim young ill <kh...@googlemail.com>.
hi there, thax alot for the explaination
how the cache module handes setCookie headers ? in case httpclient (with
cache-module enabled) is working as proxy & shared between different
browser-instances ?
On Tue, Mar 20, 2012 at 9:59 PM, Jon Moore <jo...@apache.org> wrote:
> Actually, those recommendations are already in there too, they are just
> perhaps worded differently. But if you think my recent explanation was
> clearer, perhaps I can rewrite them. :)
>
> Jon
>
> On Tue, Mar 20, 2012 at 3:23 PM, Vasile Alin <alinachegalati@gmail.com
> >wrote:
>
> > Thanks Jon for considering my proposal.
> >
> > Just checked the links (again) and yes, most of your recommendations are
> > already available; however the rest of your hints, such as the
> > "stale-while-revalidate" section or ehcache vs memcache would fit in
> > nicely.
> >
> > Alin
> >
> > On 20 March 2012 16:44, Jon Moore <jo...@apache.org> wrote:
> >
> > > Hi Alin,
> > >
> > > Actually, as it turns out, much of this information is already in the
> > > online docs:
> > >
> > >
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html
> > >
> > >
> >
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html#storage
> > >
> > > Jon
> > >
> > > On Tue, Mar 20, 2012 at 8:19 AM, Jon Moore <jo...@apache.org> wrote:
> > >
> > > > Hi Alin,
> > > >
> > > > Great suggestion - I'll look into updating the documents for the 4.2
> > > > release.
> > > >
> > > > Jon
> > > >
> > > >
> > > > On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <
> alinachegalati@gmail.com
> > > >wrote:
> > > >
> > > >> would be great if http-cache will have these hints in its overview
> > > >> documents.
> > > >>
> > > >> Alin
> > > >>
> > > >> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> > > >> > robert.naczinski@googlemail.com> 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:
> > httpclient-users-unsubscribe@hc.apache.org
> > > >> > > For additional commands, e-mail:
> > > httpclient-users-help@hc.apache.org
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
Actually, those recommendations are already in there too, they are just
perhaps worded differently. But if you think my recent explanation was
clearer, perhaps I can rewrite them. :)
Jon
On Tue, Mar 20, 2012 at 3:23 PM, Vasile Alin <al...@gmail.com>wrote:
> Thanks Jon for considering my proposal.
>
> Just checked the links (again) and yes, most of your recommendations are
> already available; however the rest of your hints, such as the
> "stale-while-revalidate" section or ehcache vs memcache would fit in
> nicely.
>
> Alin
>
> On 20 March 2012 16:44, Jon Moore <jo...@apache.org> wrote:
>
> > Hi Alin,
> >
> > Actually, as it turns out, much of this information is already in the
> > online docs:
> >
> > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html
> >
> >
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html#storage
> >
> > Jon
> >
> > On Tue, Mar 20, 2012 at 8:19 AM, Jon Moore <jo...@apache.org> wrote:
> >
> > > Hi Alin,
> > >
> > > Great suggestion - I'll look into updating the documents for the 4.2
> > > release.
> > >
> > > Jon
> > >
> > >
> > > On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <alinachegalati@gmail.com
> > >wrote:
> > >
> > >> would be great if http-cache will have these hints in its overview
> > >> documents.
> > >>
> > >> Alin
> > >>
> > >> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> > >> > robert.naczinski@googlemail.com> 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:
> httpclient-users-unsubscribe@hc.apache.org
> > >> > > For additional commands, e-mail:
> > httpclient-users-help@hc.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Best practice for caching configuration
Posted by Vasile Alin <al...@gmail.com>.
Thanks Jon for considering my proposal.
Just checked the links (again) and yes, most of your recommendations are
already available; however the rest of your hints, such as the
"stale-while-revalidate" section or ehcache vs memcache would fit in nicely.
Alin
On 20 March 2012 16:44, Jon Moore <jo...@apache.org> wrote:
> Hi Alin,
>
> Actually, as it turns out, much of this information is already in the
> online docs:
>
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html
>
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html#storage
>
> Jon
>
> On Tue, Mar 20, 2012 at 8:19 AM, Jon Moore <jo...@apache.org> wrote:
>
> > Hi Alin,
> >
> > Great suggestion - I'll look into updating the documents for the 4.2
> > release.
> >
> > Jon
> >
> >
> > On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <alinachegalati@gmail.com
> >wrote:
> >
> >> would be great if http-cache will have these hints in its overview
> >> documents.
> >>
> >> Alin
> >>
> >> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> >> > robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> >> > > For additional commands, e-mail:
> httpclient-users-help@hc.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
Hi Alin,
Actually, as it turns out, much of this information is already in the
online docs:
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.html#storage
Jon
On Tue, Mar 20, 2012 at 8:19 AM, Jon Moore <jo...@apache.org> wrote:
> Hi Alin,
>
> Great suggestion - I'll look into updating the documents for the 4.2
> release.
>
> Jon
>
>
> On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <al...@gmail.com>wrote:
>
>> would be great if http-cache will have these hints in its overview
>> documents.
>>
>> Alin
>>
>> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
>> > robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
>> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>> > >
>> > >
>> >
>>
>
>
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
Hi Alin,
Great suggestion - I'll look into updating the documents for the 4.2
release.
Jon
On Sat, Mar 17, 2012 at 6:51 PM, Vasile Alin <al...@gmail.com>wrote:
> would be great if http-cache will have these hints in its overview
> documents.
>
> Alin
>
> On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> > robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
> >
>
Re: Best practice for caching configuration
Posted by Vasile Alin <al...@gmail.com>.
would be great if http-cache will have these hints in its overview
documents.
Alin
On 17 March 2012 17:50, Jon Moore <jo...@apache.org> 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 <
> robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
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 <
robert.naczinski@googlemail.com> 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 <jo...@apache.org>:
> > 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 <
> > robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Best practice for caching configuration
Posted by Robert Naczinski <ro...@googlemail.com>.
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 <jo...@apache.org>:
> 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 <
> robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
Hi Alan,
It is entirely application dependent, as you noted, but I would suggest
starting with the in-memory cache or EhCache for the webservice calls and
an on-disk EhCache for the pictures/articles. There is also a
filesystem-based cache you might try for the pictures and articles that I
forgot to mention earlier (ManagedHttpCacheStorage):
http://hc.apache.org/httpcomponents-client-ga/httpclient-cache/apidocs/org/apache/http/impl/client/cache/ManagedHttpCacheStorage.html
The streaming video is going to be highly dependent on the particular
protocol you're using, but if it's streaming, I'm not sure what you'd get
from a cache.
Hope that helps,
Jon
On Sat, Mar 17, 2012 at 12:26 PM, Alan Ho <id...@gmail.com> wrote:
> Hi Jon,
>
> I'm using caching on an android client, and I have 3 major scenarios:
>
> Making small restful webservice calls (maximum 64 KB in Size), and second
> making much larger calls for pictures and articles, and lastly streaming
> video.
>
> Can you make a suggestion on cache configurations that would work for each
> scenario ? I know that it's subject to implementation / how much ram or
> storage I have / etc - but I'm hoping you can give me a starting point.
>
> Thanks,
> Alan Ho
>
> On Mar 17, 2012, at 10:50 AM, Jon Moore <jo...@apache.org> 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 <
> > robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Re: Best practice for caching configuration
Posted by Alan Ho <id...@gmail.com>.
Hi Jon,
I'm using caching on an android client, and I have 3 major scenarios:
Making small restful webservice calls (maximum 64 KB in Size), and second making much larger calls for pictures and articles, and lastly streaming video.
Can you make a suggestion on cache configurations that would work for each scenario ? I know that it's subject to implementation / how much ram or storage I have / etc - but I'm hoping you can give me a starting point.
Thanks,
Alan Ho
On Mar 17, 2012, at 10:50 AM, Jon Moore <jo...@apache.org> 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 <
> robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Best practice for caching configuration
Posted by Jon Moore <jo...@apache.org>.
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 <
robert.naczinski@googlemail.com> 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: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>