[
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147705#comment-14147705
]
Jason Brown commented on CASSANDRA-7282:
----------------------------------------
I ran benedict's 7282 patch vs. the commit prior in his branch, for several use
cases. TL;DR the patch was a clear winner for the the specific use case he
called out, and marginally better, if not the same, for a 'typical' use case.
For the first use case, I used Benedict's attached profile.yaml, although i
changed the RF from 1 to 2. I then used this stress command to execute
(basically the same as Benedict's above) {code}./bin/cassandra-stress user
profile=~/jasobrown/b7282.yaml ops\(insert=5,read=5\) n=20000000 -pop
seq=1..10M read-lookback=extreme\(1..1M,2\) -rate threads=200 -mode cql3 native
prepared -node <node_addresses>{code}
I've attached the results of running the above command three times successively
on both patch and unpatched code, and the results can be summarized:
- 15% improvement in throughput
- 10% improvement at 95%/99%-iles
- 50% improvement at 99.9%-ile
~ 40% less garbage created / 40% less time in GC
Note that over the life of stress run, memtables were flushing and sstables
compacting, so not all reads were coming directly from the memtable.
One thing I perhaps could have tried (and would have liked to) was switching
the CL from ONE to LOCAL_QUORUM, although I think stress would have applied
that to both reads and writes for the above command, whereas I would have
wanted to affect either read or write.
I also ran the stress a more 'standard' use case of mine (I'm still developing
it alongside the new stress), and results were about even between patch and
unpatched, although there may have been very slight advantage toward the
patched version.
So, I think in the case where you are reading your most recent writes, and the
data in the memtable is small (not wide), there is a performance gain in this
patch. In a more typical case, it wasn't necessarily proven that the patch
boosts performance (but then the patch wasn't attempting to help the general
case, anyway).
> Faster Memtable map
> -------------------
>
> Key: CASSANDRA-7282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Labels: performance
> Fix For: 3.0
>
> Attachments: profile.yaml, reads.svg, run1.svg, writes.svg
>
>
> Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in
> our memtables. Maintaining this is an O(lg(n)) operation; since the vast
> majority of users use a hash partitioner, it occurs to me we could maintain a
> hybrid ordered list / hash map. The list would impose the normal order on the
> collection, but a hash index would live alongside as part of the same data
> structure, simply mapping into the list and permitting O(1) lookups and
> inserts.
> I've chosen to implement this initial version as a linked-list node per item,
> but we can optimise this in future by storing fatter nodes that permit a
> cache-line's worth of hashes to be checked at once, further reducing the
> constant factor costs for lookups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
