[KAFKA-5150] LZ4 decompression is 4-5x slower than Snappy on small batches / messages

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.8.2.2, 0.9.0.1, 0.10.2.1, 0.11.0.0
• Fix Version/s: 0.10.2.2, 0.11.0.0
• Component/s: consumer
• Assignee: Xavier Léauté
• Reporter: Xavier Léauté
• Created: 01/May/17 23:44
• Updated: 03/Jun/17 01:08
• Resolved: 01/Jun/17 19:05

Description

I benchmarked RecordsIteratorDeepRecordsIterator instantiation on small batch sizes with small messages after observing some performance bottlenecks in the consumer.

For batch sizes of 1 with messages of 100 bytes, LZ4 heavily underperforms compared to Snappy (see benchmark below). Most of our time is currently spent allocating memory blocks in KafkaLZ4BlockInputStream, due to the fact that we default to larger 64kB block sizes. Some quick testing shows we could improve performance by almost an order of magnitude for small batches and messages if we re-used buffers between instantiations of the input stream.

Benchmark Code

Benchmark                                              (compressionType)  (messageSize)   Mode  Cnt       Score       Error  Units
DeepRecordsIteratorBenchmark.measureSingleMessage                    LZ4            100  thrpt   20   84802.279 ±  1983.847  ops/s
DeepRecordsIteratorBenchmark.measureSingleMessage                 SNAPPY            100  thrpt   20  407585.747 ±  9877.073  ops/s
DeepRecordsIteratorBenchmark.measureSingleMessage                   NONE            100  thrpt   20  579141.634 ± 18482.093  ops/s

Issue Links

• relates to: KAFKA-4293 ByteBufferMessageSet.deepIterator burns CPU catching EOFExceptions
• links to: GitHub Pull Request #2967
• links to: GitHub Pull Request #3090
• links to: GitHub Pull Request #3164
• links to: GitHub Pull Request #3180