• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • hsingh
  • Reporter: harlin
  • March 31, 2010
  • 0
  • Watchers: 3
  • January 17, 2013
  • June 17, 2010

Description

In 1.6.2, in response to issue 2831182, the statistics counters in net.sf.ehcache.Cache.java were replaced with ones of type AtomicLong for better concurrency. In our application, this change decreased our *overall* application performance by nearly two orders of magnitude because of the contention for the counters.

As far as I can tell from the code these counter types are still managed the same way in the 1.7.x versions. I would think basic benchmarking would have set off lots of alarms about this. Here are some details of our setup: * JBoss 5.1, with EJB persistence using Hibernate 3.3.1.GA (the stock configuration) * Ehcache used as Hibernate second-level cache * Caches are configured so as not to evict unless there is an event

We can reproduce this slow behavior with a mere 5 threads accessing the cached objects.

Comments

Thomas Smith 2010-04-01

Upon further testing the effect may not be as severe as I state above, but at load we definitely see a 20-40% performance degradation.

gluck 2010-04-01

There is a regression in 1.7 due to further statistics which were add in. See EHC-419. As a result of that we now have the ability to turn stats off all together. Add the attribute statistics=”false” to your cache. Perhaps we should have this turned on by default.

The 1.6.2 issue did not really show up. Can you alter one of the CacheTests such as testConcurrentReadWriteRemove to show this issue.

Fiona OShea 2010-04-01

Created EHC-673 to request adding and turning the statistic to false by default.

Thomas Smith 2010-04-01

It will be difficult to reproduce this in 1.6.2 in a unit-test framework. We see this on 16-core machines running 50 simultaneous threads hitting the cache at fairly regular intervals. I suspect that the AtomicLong/Integer/Boolean implementation is at fault. Yes, it’s good that these classes are not implemented using synchronization, but what they actually do is set/test-success/retry to increment values. You can end up trading back-and-forth between threads and spinning periodically if you’re really aggressive.

Turning off statistics would be a workaround, but hey - Statistics are useful. However, they can still be really useful if they aren’t precise. Dropping a few hit counts would still tell you if you were accomplishing your cache strategy. This is after all what 1.6.1 used to do, presumably. In any of my applications I would certainly sacrifice precision for performance in this area.

Fiona OShea 2010-04-28

Is this an issue or not in your opinion?

Chris Dennis 2010-06-17

Cache statistics can now be switched off by setting statistics=”false” in the cache configuration (or by calling the relevant method on the Cache instance). This will eliminate the any contention that may be seen when updating the cache-wide statistics counters.

Himadri Singh 2010-06-25

statistics are disabled by default.