Hello everyone,
This message is both a review request and my attempt to share with you some of the benchmark results related to replacing the CRC32 algorithm for the internode messaging protocol. When a new connection is initiated between nodes, the corresponding connection channel is configured with one of the frame encoder/decoder pairs based on how a user has set a cluster YAML configuration. The frame encoder is configured on the sender side, and the frame decoder is configured on the receiver side. They use the CRC24 for frame header protection and the CRC32 for frame payload protection. Since we've dropped support for the jdk8 [1] in the upcoming release, it's now possible to use the more efficient CRC32C algorithm, which ships with jdk11 by default, without any additional overhead for us. I have prepared a patch [4] to replace the CRC32 algorithm with the more efficient CRC32C for frames payload. I've prototyped a new solution and done some research into the reasons for dropping both the CRC24 and the CRC32, but replacing only the CRC32 for payload and keeping the CRC24 as it is seems to be more efficient for us, and simplifies the whole solution (see [2] for details). Benchmarks seem to point us in the right direction (see [3]). Decode CRC avgt 4 382.764 ± 75.327 ns/op CRC32C avgt 4 272.388 ± 63.618 ns/op Encode CRC avgt 4 382.130 ± 12.318 ns/op CRC32C avgt 4 311.646 ± 17.114 ns/op So, if anyone is interested in these changes and can verify them, I would be happy to help and answer any questions. [1] https://issues.apache.org/jira/browse/CASSANDRA-18255 [2] https://issues.apache.org/jira/browse/CASSANDRA-16360?focusedCommentId=17771183&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17771183 [3] https://gist.github.com/Mmuzaf/a7ac6f5759c16ee24683856704e7c941 [4] https://github.com/apache/cassandra/pull/2647
