Description

In perf testing, we’ve found some overhead to maintaining the last accessed timestamp when TTI is off. This was a hypothesis based on this being different being h2lc+distributed cache and clustered ehcache.

Maintaining that timestamp requires a write to clustered data. We’re doing some things already to make that as concurrent as possible, but we found a noticeable speed boost if we commented out that code to verify this hypothesis.

If we relaxed the constraints for the accuracy of this field when clustering, we could get a nice speed boost for the non-TTI case. We could make this a flag or just automatically modify what happens.

Comments

Alex Miller 2009-10-08

Patch for testing:

Index: core/src/main/java/net/sf/ehcache/Element.java

— core/src/main/java/net/sf/ehcache/Element.java (revision 1298) +++ core/src/main/java/net/sf/ehcache/Element.java (working copy) @@ -439,7 +439,9 @@ * Resets the hit count to 0 and the last access time to now. Used when an Element is put into a cache. */ public final void resetAccessStatistics() {

elementEvictionData.resetLastAccessTime(this);
if (!isEternal()) {
elementEvictionData.resetLastAccessTime(this);
} hitCount = 0; }

@@ -447,7 +449,9 @@ * Sets the last access time to now and increase the hit count. */ public final void updateAccessStatistics() {

elementEvictionData.updateLastAccessTime(TimeUtil.toSecs(System.currentTimeMillis()), this);
if (!isEternal()) {
elementEvictionData.updateLastAccessTime(TimeUtil.toSecs(System.currentTimeMillis()), this);
} hitCount++; }

Himadri Singh 2009-10-08

Results for 8-node cluster, ehcacheperf tests with standalone terracotta-ehcache and coherentReads=false

Without patch: Cluster TPS: 84057.7 With patch: Cluster TPS: 114949

Alex Miller 2009-10-29

If we didn’t care about giving a valid lastAccessed timestamp for clustered elements, we could get a substantial performance boost. Seems like the potential options are:

1) Simply don’t update this and allow the value to be bogus in this case. All the perf. Easy to code. Possibly confusing from user point of view. 2) Implement something that updates the clustered value less frequently. This would reduce accuracy but still give some of the perf (depending how far you pushed it). Probably fairly difficult to code. Might affect local memory usage to track the updates.
3) Introduce some kind of option to the config that allows you to determine either accuracy or whether timestamps are updated depending how you want to spin it.

gluck 2009-10-29

1) will likely break some usages of Element. I suspect people are interested in this.

I like 3)

Fiona OShea 2010-08-11

Is this still an issue with DCV2

Saravanan Subbiah 2010-08-11

DCV2 doesnt cahnge anything in this regard. Though I am not sure if we still update lastAccess quite that often.

Assigning to Abhishek to do some research.

Fiona OShea 2011-01-21

moving out for implementation consideration in Ulloa

Saravanan Subbiah 2013-02-09

Is this still valid ?

Tim Wu 2013-05-02

We don’t update last accessed times unless TTI is enabled so this shouldn’t be an issue anymore.