Array based ring, for ketama node locator lookups, for improved performance #9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there
This is pull request for changing the KetamaNodeLocator from using a
TreeMap<Long,MemcachedNode>
to than of an array based ring lookup.I noticed that the TreeMap implementation has a few performance related issues:
To avoid the first, whilst improving on 2, I have changed the TreeMap ring implementation to use that of a sorted long[], and implement a binary search for the closest ceil long in the array, against which to hash entries. This avoids the creation of the Long objects, and also only searches for the closest ceil long in the array the once.
The jmh benchmark is showing this implementation of the ring to be more performant.
Here is the output from Java Flight Recorder and Mission Control that show the before and after. With the after now showing that item that impacts performance/takes up CPU to be that of the HashingAlgorithm and not the node lookup in the ring:
Before:
CPU:
Allocations:
After
CPU (getBytes is from get bytes on the string to byte[] required by the key hashing)
Memory: (no more Longs)
As a side note I have fixed a concurrency issue in the test case:
DummyListenableFuture
. It was notifying listeners before setting the content. Also as the listeners are executed on a separate thread, the content needs to be volatile to ensure publication of the value (set in one thread) to the executor thread that the listener is running on.I also increased the sleep time in
QueueOverflowTest
to allow the client to recover/reconnect as it was always failing, before even these changes were done. With the increased timeout out the test is working.