[DATAREDIS-399] Unconditional locking via waitForLock greatly degrades performance - Spring JIRA
I am using Redis for temporary storage (24h) of data and my application does not share data between different threads. In other words, each thread writes it's own data to Redis via RedisCache.
In our load testing, the waitForLock method essentially doubles the time it takes to perform Redis operations. Just to check if the lock object exists requires a round trip to Redis. Storing the data, is another round trip (we are processing about 2500 events/second), so Redis access it the long pole in our application.
I looked but could not find a flag to conditionally turn off requirement to invoke waitForLock(). At the end, I extended RedisCache/RedisCacheManager to provide my own implementation of put/get, however, it was not as clean as I wanted it to be. I could not simply extends from appropriate AbstractRedisCacheCallback and overwrite waitForLock with empty implementation as those classes are not made public. Instead, I had to extract the code from those classes to use in my own implementation.
As a user of RedisCache, I would like the capability of extending from derivations of AbstractRedisCacheCallback (make them public or protected) so that I can provide my own custom implementations. Alternatively, it would be nice to disable constant checking for lock.
Read full article from [DATAREDIS-399] Unconditional locking via waitForLock greatly degrades performance - Spring JIRA
No comments:
Post a Comment