[
https://issues.apache.org/jira/browse/CASSANDRA-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661453#comment-13661453
]
Daniel Norberg commented on CASSANDRA-5422:
-------------------------------------------
The patches were mostly to show the optimisations I applied to arrive at my
benchmark results.
I've fixed the license headers, although I must admit that I'm unsure of what
to do about the copyright notice, if something needs to be done.
The ExecuteMessage serialisation optimisation gives me a ~20% throughput boost
on top of all other optimisations, which is not bad. I attached two screenshots
of the VisualVM profiler highlighting the CompositeChannelBuffer.decompose()
method, which gets called to flatten the serialised ExecuteMessage.
The write batcher will only batch writes if they arrive within less than a
configurable time interval, default 100 microseconds, after another write.
I.e., in low throughput scenarios no batching will be done, keeping latencies
low. In high throughput scenarios the buffer is likely to be flushed quickly,
providing a negligible latency impact. That said, more testing in order to
better understand the behaviour and performance characteristics sounds like a
good idea.
Anyway, 100k+ rps is a great improvement over the thrift interface. Great job
on the new driver! I'm looking forward to using it =)
> Binary protocol sanity check
> ----------------------------
>
> Key: CASSANDRA-5422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5422
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Jonathan Ellis
> Assignee: Daniel Norberg
> Attachments: 5422-test.txt, ExecuteMessage Profiling - Call Tree.png,
> ExecuteMessage Profiling - Hot Spots.png
>
>
> With MutationStatement.execute turned into a no-op, I only get about 33k
> insert_prepared ops/s on my laptop. That is: this is an upper bound for our
> performance if Cassandra were infinitely fast, limited by netty handling the
> protocol + connections.
> This is up from about 13k/s with MS.execute running normally.
> ~40% overhead from netty seems awfully high to me, especially for
> insert_prepared where the return value is tiny. (I also used 4-byte column
> values to minimize that part as well.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
