[
https://issues.apache.org/jira/browse/CASSANDRA-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352815#comment-14352815
]
Benedict commented on CASSANDRA-8833:
-------------------------------------
bq. run benchmarks again, this time on ssds (Ryan McGuire could your team help
out with that?)
This is a little tricky, since we've disabled the eviction of page cache
entries for the new files in 2.1, so we'll need to roll a patch to reintroduce
it. It's also worth caveating in advance that, since testing SSDs we likely
care about latency more than throughput, Gil Tene's arguments (my final
thoughts about which can be found
[here|https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAA&url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmechanical-sympathy%2FicNZJejUHfE%2FLMQdQZJwvxEJ&ei=2X39VLi5B4XbUdKUgMAO&usg=AFQjCNF4_q-i6496RrmjZiXHZzAEmOy48A&bvm=bv.87611401,d.d24])
about stress in its current state do hold water, and we we will significantly
underestimate any negative effect on latency, although I may be able to
calculate a rough adjustment after the fact. This isn't a problem for
provisioning tests, since you should never saturate throughput for such a test,
but for testing these kinds of effects we absolutely should. Fixing stress to
properly simulate all of the messages at a target throughput rate is on my hit
list, but won't be done for a few weeks at least.
> Stop opening compaction results early
> -------------------------------------
>
> Key: CASSANDRA-8833
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8833
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Eriksson
> Fix For: 2.1.4
>
>
> We should simplify the code base by not doing early opening of compaction
> results. It makes it very hard to reason about sstable life cycles since they
> can be in many different states, "opened early", "starts moved", "shadowed",
> "final", instead of as before, basically just one (tmp files are not really
> 'live' yet so I don't count those). The ref counting of shared resources
> between sstables in these different states is also hard to reason about. This
> has caused quite a few issues since we released 2.1
> I think it all boils down to a performance vs code complexity issue, is
> opening compaction results early really 'worth it' wrt the performance gain?
> The results in CASSANDRA-6916 sure look like the benefits are big enough, but
> the difference should not be as big for people on SSDs (which most people who
> care about latencies are)
> WDYT [~benedict] [~jbellis] [~iamaleksey] [~JoshuaMcKenzie]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
