[
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)