Почему потребительский клиент kafka не сжимает использование процессора больше, чем сжимает мгновенно в содержимом msgpack?

Question

Я тестирую различные методы сжатия потребителей kafka с содержимым msgpack.

Я получаю следующие результаты:

Compress type   Consumer Qps      CPU     Ten thousand message CPU costs
msgpack+none    15000             13.4%   8.9% (13.4 / 15000 * 10000)
msgpack+snappy  29700             21.5%   7.2% (21.5 / 29700 * 10000)

Я хочу знать, почему десять тысяч ЦП сообщений стоят msgpack + не более чем msgpack + snappy.

Я получил график пламени и обнаружил, что GCTaskThread::run() и CompileBroker::compiler_thread_loop() стоят больше в none типе сжатия.

msgpack + none:

msgpack + snappy:

Я получаю g c журнал для другого типа сжатия в клиенте:

Compress type    GC times every minutes    Stop time every minutes
none             128                       0.55s
snappy           43                        0.2s

Конфигурация клиентского клиента (часть кода scala):

  def getConsumerProperties(servers: String, groupId: String): Properties = {
    val props = new Properties()
    props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, servers)
    props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId)
    props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false")
    props.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, Integer.valueOf(30000))
    props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, Integer.valueOf(3000))
    props
  }

Конфигурация сервера:

compression.type=producer

Вопрос:

Интересно знаю, почему потребительский клиент kafka не сжимает использование процессора больше, чем сжатие мгновенно.

Интересно, почему GCTaskThread::run() и CompileBroker::compiler_thread_loop() стоят дороже none сжатие.

CompileBroker::compiler_thread_loop().