[
https://issues.apache.org/jira/browse/CASSANDRA-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083206#comment-13083206
]
Peter Schuller commented on CASSANDRA-1827:
-------------------------------------------
The following is speculation and should not be construed as a strong claim ;)
I don't have proof but I suspect that putting/popping individual entries is
fairly significant, mostly because of the context switching involved and
interaction with the scheduler. Empirically when stress-testing it seems to me
that under CPU bound workloads the stages are often not saturated (and you
certainly don't saturate all cores despite high concurrency). In other words,
even with a consistent backlog of pending tasks the active tasks aren't
consistently at full concurrency. I wonder what kind of effects come form delay
in waking up a thread.
Something similar to consider might be to try to use a non-blocking queue
(you'd still presumably block in low-throughput cases, but have the potential
to proceed lock-lessly under high load).
> Batching across stages
> ----------------------
>
> Key: CASSANDRA-1827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1827
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Chris Goffinet
> Fix For: 1.0
>
>
> We might be able to get some improvement if we start batching tasks for every
> stage.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
