[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13992883#comment-13992883 ] Norman Maurer commented on CASSANDRA-6861: -- We will most likely ship our OpensslEngine in the next release of Netty. That said it only support server-side usage atm. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993380#comment-13993380 ] Norman Maurer commented on CASSANDRA-6861: -- Opened a PR with some improvements: https://github.com/apache/cassandra/pull/35 Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991485#comment-13991485 ] Aleksey Yeschenko commented on CASSANDRA-6861: -- B/c IMO it being too slow is a security issue itself, if it causes people to switch back to unencrypted transport. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991484#comment-13991484 ] Aleksey Yeschenko commented on CASSANDRA-6861: -- I guess it depends on how much JDK's SSLEngine really sucks (and I suspect it does, a lot). Either way, should at least create a ticket so that we don't forget about it, and switch to the built-in Netty's SslEngine once it's available. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990601#comment-13990601 ] Benedict commented on CASSANDRA-6861: - Performance graphs look nice - much tighter variance. Couple of nits with the patch: 1) It would be nice, since we effectively create a static allocator, to reference it from a static context instead of grabbing it from the buffer we've been passed by Netty 2) I'm a little concerned we aren't tidying up in the case of exceptions - this is probably not a major issue since netty uses finalizers and exceptions should be rare, so there'll be little resource leakage, but it would be good to at least tidy up the frame in the case that we have to log an exception. This won't catch all possible paths (e.g. exceptions before we finish setting the frame) but it's probably close enough. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990730#comment-13990730 ] T Jake Luciani commented on CASSANDRA-6861: --- bq. 1) It would be nice, since we effectively create a static allocator, to reference it from a static context instead of grabbing it from the buffer we've been passed by Netty Done on v2 branch bq. 2) I'm a little concerned we aren't tidying up in the case of exceptions. I'm not sure I follow you. The encoder would be the main place an exception would be encountered but the dispatcher has a finally that frees the resources so I don't see how we can leak (unless calling write and flush doesn't do what I think it does). Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990809#comment-13990809 ] Benedict commented on CASSANDRA-6861: - bq. the main place an exception Right, agreed - that's why it's a nit :) - but it would be nice to handle cases where we encounter an exception between further up in the pipeline where we allocate buffers and the dispatcher that executes them. This is probably more important if you address point (2) below Also, just had a closer look at the full patch, and noticed a couple of other things: # CBUtil.readValue is potentially leaking references - since we never return the ByteBuf we allocate we can never release it. # It would be nice if the compressor/decompressor stages could also use an allocator (obviously one that is always byte-array backed) so that they do not create unnecessary garbage. # OptionCode.encode could do the same - since we never use it it's not currently a problem, but perhaps we should wrap() an explicit byte[] in that method just in case Unpooled decides to allocate an off-heap buffer Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991060#comment-13991060 ] Aleksey Yeschenko commented on CASSANDRA-6861: -- What about the SSL - Don’t use JDKs SSLEngine if performance matters part of the slides? Are we going to handle that as part of this ticket? Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991128#comment-13991128 ] T Jake Luciani commented on CASSANDRA-6861: --- Pushed changes for 1 and 2 plus added exception checks to free resources. For 3, calling Unpooled.buffer() is a on heap buffer call. I don't see them changing that. bq. What about the SSL - Don’t use JDKs SSLEngine if performance matters part of the slides? Are we going to handle that as part of this ticket? I don't know about you but I prefer to stick with the JDK here for security reasons. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991387#comment-13991387 ] Benedict commented on CASSANDRA-6861: - Nits: * frame.release() in the compressors should go in a finally block * would prefer to catch (Throwable t) and use Java 7's (re)throw where possible, instead of always wrapping in IOException * in the LZ4 compressor, would prefer to grab the array and arrayOffset once only, and refer to them from local variables, as each is a virtual method invocation so is unlikely to be inlined by the VM. Otherwise LGTM Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989800#comment-13989800 ] T Jake Luciani commented on CASSANDRA-6861: --- Pushed more changes to https://github.com/tjake/cassandra/tree/6861-v2 [~enigmacurry] could you run one of the fancy stress tests on this vs 2.1 head? Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989828#comment-13989828 ] Ryan McGuire commented on CASSANDRA-6861: - can do. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989852#comment-13989852 ] T Jake Luciani commented on CASSANDRA-6861: --- The -mode should be: native cql3 prepared Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990038#comment-13990038 ] Ryan McGuire commented on CASSANDRA-6861: - http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.6861.json I'm running this a second time to see if the downward spike in the read happens again... Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990116#comment-13990116 ] Ryan McGuire commented on CASSANDRA-6861: - The read drop was a fluke, here's trial 2: http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.6861.2.json This was a comparison of f0575f153b8 from 2.1 HEAD and your branch' 784db2fde2. I can re-run this against your rebase 4b6b819a53. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990147#comment-13990147 ] Ryan McGuire commented on CASSANDRA-6861: - compares f0575f153b to 4b6b819a5322 : riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.6861.3.json Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 rc1 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987002#comment-13987002 ] Benedict commented on CASSANDRA-6861: - It looks like we're still allocating a lot of unpooled buffers, even though they are now (mostly) being released. We'd like to allocate them from a pool if possible. It seems CBUtil.readValue() can also still allocate unpooled buffers that won't have release called on them (though likely the code path isn't being exercised right now) - since this one just returns an NIO buffer, it's probably easiest to simply allocate a ByteBuffer and read the bytes into it. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 beta2 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985278#comment-13985278 ] Benedict commented on CASSANDRA-6861: - See CASSANDRA-7045 for one possible explanation. For comparison see performance of async and hsha thrift, which in my experiments perform, either as poorly, or half as poorly. Further evidence for this hypothesis is that the gap narrows for larger messages. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 beta2 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985516#comment-13985516 ] T Jake Luciani commented on CASSANDRA-6861: --- Yeah, looks like thrift hsha is about as poor. Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 beta2 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985659#comment-13985659 ] Benedict commented on CASSANDRA-6861: - It may be worth trying netty's JNI epoll provider whilst we're at this Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 beta2 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-6861) Optimise our Netty 4 integration
[ https://issues.apache.org/jira/browse/CASSANDRA-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13985064#comment-13985064 ] T Jake Luciani commented on CASSANDRA-6861: --- Just a cursory check I see the following read performance: - mode thrift: 23530 - mode thrift cql3 prepared: 21169 - mode native cql3 prepared: *14142* Optimise our Netty 4 integration Key: CASSANDRA-6861 URL: https://issues.apache.org/jira/browse/CASSANDRA-6861 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Benedict Assignee: T Jake Luciani Priority: Minor Labels: performance Fix For: 2.1 beta2 Now we've upgraded to Netty 4, we're generating a lot of garbage that could be avoided, so we should probably stop that. Should be reasonably easy to hook into Netty's pooled buffers, returning them to the pool once a given message is completed. -- This message was sent by Atlassian JIRA (v6.2#6252)
