You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Benjamin Manes <be...@gmail.com> on 2015/05/26 01:11:42 UTC
Re: [Mavibot] Need for a cache to replace the WeakReferences...
I stumbled upon an old thread [1] regarding Mavibot's cache experiments. In
that thread the project was moving away from weak reference based caching
and had poor performance with Ehcache. A follow up discussion [2] mentioned
experimenting with ConcurrentLinkedHashMap (my old project), but drops off
before describing the results. As it appears Ehcache is used, it is not
clear whether the performance problems were resolved or deemed not fixable.
In case there is still a bottleneck in the caching layer you may be
interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
it to be 7x faster on a 4-core machine and should scale better as the CPU
count increases.
Hope that helps,
Ben
[1] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html
[2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html
[3] https://github.com/ben-manes/caffeine
Re: [Mavibot] Need for a cache to replace the WeakReferences...
Posted by Kiran Ayyagari <ka...@apache.org>.
Hi Ben,
On Tue, May 26, 2015 at 7:11 AM, Benjamin Manes <be...@gmail.com> wrote:
> I stumbled upon an old thread [1] regarding Mavibot's cache experiments.
> In that thread the project was moving away from weak reference based
> caching and had poor performance with Ehcache. A follow up discussion [2]
> mentioned experimenting with ConcurrentLinkedHashMap (my old project), but
> drops off before describing the results. As it appears Ehcache is used, it
> is not clear whether the performance problems were resolved or deemed not
> fixable.
>
> would love to move away from Ehcache, cause Mavibot is a very low level
library
> In case there is still a bottleneck in the caching layer you may be
> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
> it to be 7x faster on a 4-core machine and should scale better as the CPU
> count increases.
>
> 7x over Ehcache? that would be cool.
A question, does Caffeine depend on any other libraries, if yes, can you
provide the list (I can't yet read
build.gradle like pom.xml ;)
thank you
> Hope that helps,
> Ben
>
> [1] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html
> [2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html
> [3] https://github.com/ben-manes/caffeine
>
--
Kiran Ayyagari
http://keydap.com
Re: [Mavibot] Need for a cache to replace the WeakReferences...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 26/05/15 01:11, Benjamin Manes a écrit :
> I stumbled upon an old thread [1] regarding Mavibot's cache experiments. In
> that thread the project was moving away from weak reference based caching
> and had poor performance with Ehcache. A follow up discussion [2] mentioned
> experimenting with ConcurrentLinkedHashMap (my old project), but drops off
> before describing the results. As it appears Ehcache is used, it is not
> clear whether the performance problems were resolved or deemed not fixable.
FTR, we used ehcahce because it was way faster than the system we
implemented, which was based on weak-references. The reason was that we
were already using ehcache in ApacheDS, so it was easy for us to switch
to this system..
>
> In case there is still a bottleneck in the caching layer you may be
> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
> it to be 7x faster
7x faster than?
> on a 4-core machine and should scale better as the CPU
> count increases.
My question :
- it seems like cafeine is using weak-references ( keys automatically
wrapped in weak references
<https://github.com/ben-manes/caffeine/wiki/Eviction#reference-based>).
The issue we had when we were using weak-references is that it was
painfully slow when we were exhausting the memory, because the GC
behaviour was really, really bad.
- do you have comparison between caffeine and ehcache ?
In any case, be sure we want to replace ehcache -which is a bit heavy)
by something lighter in the near future, we will certainly experiment
caffeine !
Thanks !
Re: [Mavibot] Need for a cache to replace the WeakReferences...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Thanks Benjamin !
Definitively worth a try...
Le 26/05/15 08:05, Benjamin Manes a écrit :
> I am not subscribed to the list and it seems that responses do not
> reply-all, so I'll watch the list and respond indirectly. Please reply-all
> if you want my immediate feedback.
>
> ---
> Emmanuel Lécharny wrote:
>> 7x faster than? do you have comparison between caffeine and ehcache ?
> 6-7.5x faster than Ehcache v2.10 with a 100% hit rate using a Zipf
> distribution, where the multiplier depends on the read/write ratio. This is
> on a 4-core laptop and while I have every reason to believe that Caffeine
> should scale even better on a server-class machine, I have not yet
> validated that claim.
>
> You are welcome to check the benchmarks for any mistakes. It can be run
> with the command ./gradles jmh -PincludePattern=GetPutBenchmark and the
> report is under caffeine/build/reports/jmh/human.txt. All caches use LRU
> eviction with no other features enabled (no weak references, listeners,
> expiration, etc).
>
> https://github.com/ben-manes/caffeine/wiki/Benchmarks
>
>> it seems like cafeine is using weak-references (keys automatically
> wrapped in weak references)
>
> That is a configuration option, not a requirement, and I agree that GC
> based caching is not ideal. It would in fact invalidate a micobenchmark and
> is not enabled in the one listed above. However there is no one size fits
> all scenario in caching so many options are available for developers to
> choose from. Caffeine uses code generation so that cache entries contain
> only the fields required for that cache configuration.
>
> ---
> Kiran Ayyagari wrote:
>> does Caffeine depend on any other libraries
> It uses JSR-305 annotations (e.g. @Nonnull) for documentation / static
> analysis. That is currently used in compile scope, but could be moved to
> provided scope as it is not required at runtime (the byte code is ignored).
> I left it as compile scope for Scala users, as I haven't checked whether an
> old compiler bug was fixed that caused scalac fail unless users explicitly
> added it back in.
>
> The cache has a dependency on Caffiene's tracing api, which will no-op
> unless an implementation is discovered (via a ServiceLocator). The tracing
> api has no dependencies.
>
> The other modules are optional (guava, jsr107 jcache, async-tracer,
> simulator). These modules do have external dependencies, but most
> application's shouldn't include them.
>
> Cheers,
> Ben
>
> On Mon, May 25, 2015 at 4:11 PM, Benjamin Manes <be...@gmail.com> wrote:
>
>> I stumbled upon an old thread [1] regarding Mavibot's cache experiments.
>> In that thread the project was moving away from weak reference based
>> caching and had poor performance with Ehcache. A follow up discussion [2]
>> mentioned experimenting with ConcurrentLinkedHashMap (my old project), but
>> drops off before describing the results. As it appears Ehcache is used, it
>> is not clear whether the performance problems were resolved or deemed not
>> fixable.
>>
>> In case there is still a bottleneck in the caching layer you may be
>> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
>> it to be 7x faster on a 4-core machine and should scale better as the CPU
>> count increases.
>>
>> Hope that helps,
>> Ben
>>
>> [1] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html
>> [2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html
>> [3] https://github.com/ben-manes/caffeine
>>
Re: [Mavibot] Need for a cache to replace the WeakReferences...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, May 26, 2015 at 2:05 PM, Benjamin Manes <be...@gmail.com> wrote:
> I am not subscribed to the list and it seems that responses do not
> reply-all, so I'll watch the list and respond indirectly. Please reply-all
> if you want my immediate feedback.
>
> ---
> Emmanuel Lécharny wrote:
> > 7x faster than? do you have comparison between caffeine and ehcache ?
>
> 6-7.5x faster than Ehcache v2.10 with a 100% hit rate using a Zipf
> distribution, where the multiplier depends on the read/write ratio. This
> is on a 4-core laptop and while I have every reason to believe that
> Caffeine should scale even better on a server-class machine, I have not yet
> validated that claim.
>
> cool
> You are welcome to check the benchmarks for any mistakes. It can be run
> with the command ./gradles jmh -PincludePattern=GetPutBenchmark and the
> report is under caffeine/build/reports/jmh/human.txt. All caches use LRU
> eviction with no other features enabled (no weak references, listeners,
> expiration, etc).
>
> https://github.com/ben-manes/caffeine/wiki/Benchmarks
>
> > it seems like cafeine is using weak-references (keys automatically
> wrapped in weak references)
>
> That is a configuration option, not a requirement, and I agree that GC
> based caching is not ideal. It would in fact invalidate a micobenchmark and
> is not enabled in the one listed above. However there is no one size fits
> all scenario in caching so many options are available for developers to
> choose from. Caffeine uses code generation so that cache entries contain
> only the fields required for that cache configuration.
>
> ---
> Kiran Ayyagari wrote:
> > does Caffeine depend on any other libraries
>
> It uses JSR-305 annotations (e.g. @Nonnull) for documentation / static
> analysis. That is currently used in compile scope, but could be moved to
> provided scope as it is not required at runtime (the byte code is ignored).
> I left it as compile scope for Scala users, as I haven't checked whether an
> old compiler bug was fixed that caused scalac fail unless users explicitly
> added it back in.
>
> ok, this is not a heavy one
> The cache has a dependency on Caffiene's tracing api, which will no-op
> unless an implementation is discovered (via a ServiceLocator). The tracing
> api has no dependencies.
>
> The other modules are optional (guava, jsr107 jcache, async-tracer,
> simulator). These modules do have external dependencies, but most
> application's shouldn't include them.
>
perfect, the reason I asked in the first place was to ensure that guava is
not included.
thanks for the details.
>
> Cheers,
> Ben
>
> On Mon, May 25, 2015 at 4:11 PM, Benjamin Manes <be...@gmail.com>
> wrote:
>
>> I stumbled upon an old thread [1] regarding Mavibot's cache experiments.
>> In that thread the project was moving away from weak reference based
>> caching and had poor performance with Ehcache. A follow up discussion [2]
>> mentioned experimenting with ConcurrentLinkedHashMap (my old project), but
>> drops off before describing the results. As it appears Ehcache is used, it
>> is not clear whether the performance problems were resolved or deemed not
>> fixable.
>>
>> In case there is still a bottleneck in the caching layer you may be
>> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
>> it to be 7x faster on a 4-core machine and should scale better as the CPU
>> count increases.
>>
>> Hope that helps,
>> Ben
>>
>> [1] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html
>> [2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html
>> [3] https://github.com/ben-manes/caffeine
>>
>
>
--
Kiran Ayyagari
http://keydap.com
Re: [Mavibot] Need for a cache to replace the WeakReferences...
Posted by Benjamin Manes <be...@gmail.com>.
I am not subscribed to the list and it seems that responses do not
reply-all, so I'll watch the list and respond indirectly. Please reply-all
if you want my immediate feedback.
---
Emmanuel Lécharny wrote:
> 7x faster than? do you have comparison between caffeine and ehcache ?
6-7.5x faster than Ehcache v2.10 with a 100% hit rate using a Zipf
distribution, where the multiplier depends on the read/write ratio. This is
on a 4-core laptop and while I have every reason to believe that Caffeine
should scale even better on a server-class machine, I have not yet
validated that claim.
You are welcome to check the benchmarks for any mistakes. It can be run
with the command ./gradles jmh -PincludePattern=GetPutBenchmark and the
report is under caffeine/build/reports/jmh/human.txt. All caches use LRU
eviction with no other features enabled (no weak references, listeners,
expiration, etc).
https://github.com/ben-manes/caffeine/wiki/Benchmarks
> it seems like cafeine is using weak-references (keys automatically
wrapped in weak references)
That is a configuration option, not a requirement, and I agree that GC
based caching is not ideal. It would in fact invalidate a micobenchmark and
is not enabled in the one listed above. However there is no one size fits
all scenario in caching so many options are available for developers to
choose from. Caffeine uses code generation so that cache entries contain
only the fields required for that cache configuration.
---
Kiran Ayyagari wrote:
> does Caffeine depend on any other libraries
It uses JSR-305 annotations (e.g. @Nonnull) for documentation / static
analysis. That is currently used in compile scope, but could be moved to
provided scope as it is not required at runtime (the byte code is ignored).
I left it as compile scope for Scala users, as I haven't checked whether an
old compiler bug was fixed that caused scalac fail unless users explicitly
added it back in.
The cache has a dependency on Caffiene's tracing api, which will no-op
unless an implementation is discovered (via a ServiceLocator). The tracing
api has no dependencies.
The other modules are optional (guava, jsr107 jcache, async-tracer,
simulator). These modules do have external dependencies, but most
application's shouldn't include them.
Cheers,
Ben
On Mon, May 25, 2015 at 4:11 PM, Benjamin Manes <be...@gmail.com> wrote:
> I stumbled upon an old thread [1] regarding Mavibot's cache experiments.
> In that thread the project was moving away from weak reference based
> caching and had poor performance with Ehcache. A follow up discussion [2]
> mentioned experimenting with ConcurrentLinkedHashMap (my old project), but
> drops off before describing the results. As it appears Ehcache is used, it
> is not clear whether the performance problems were resolved or deemed not
> fixable.
>
> In case there is still a bottleneck in the caching layer you may be
> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
> it to be 7x faster on a 4-core machine and should scale better as the CPU
> count increases.
>
> Hope that helps,
> Ben
>
> [1] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html
> [2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html
> [3] https://github.com/ben-manes/caffeine
>