[ https://issues.apache.org/jira/browse/CASSANDRA-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485712#comment-15485712 ]
Edward Capriolo commented on CASSANDRA-12017: --------------------------------------------- Looking at trunk I think this is the spot in the code. OutboundTcpConnection.java {noformat} private static void writeHeader(DataOutput out, int version, boolean compressionEnabled) throws IOException { // 2 bits: unused. used to be "serializer type," which was always Binary // 1 bit: compression // 1 bit: streaming mode // 3 bits: unused // 8 bits: version // 15 bits: unused int header = 0; if (compressionEnabled) header |= 4; header |= (version << 8); out.writeInt(header); } {noformat} Should we use 3 bits? Create an enum that maps 3 bit numbers to available compression options? > Allow configuration of inter DC compression > -------------------------------------------- > > Key: CASSANDRA-12017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12017 > Project: Cassandra > Issue Type: Improvement > Reporter: Thom Valley > Fix For: 3.x > > > With larger and more extensively geographically distributed clusters, users > are beginning to need the ability to reduce bandwidth consumption as much as > possible. > With larger workloads, the limits of even large intercontinental data links > (55MBps is pretty typical) are beginning to be stretched. > InterDC SSL is currently hard coded to use the fastest (not highest) > compression settings. LZ4 is a great option, but being able to raise the > compression at the cost of some additional CPU may save as much as 10% > (perhaps slightly more depending on the data). 10% of a 55MBps link, if > running at or near capacity is substantial. > This also has a large impact on the overhead and rate possible for > instantiating new DCs as well as rebuilding a DC after a failure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)