Отправка событий с помощью Reactor Kafka кажется очень медленной

Question

Мой проект использует Reactor Kafka 1.2.2.RELEASE для отправки событий, сериализованных с Avro, моему брокеру Kafka. Это работает хорошо, однако отправка событий кажется довольно медленной.

Мы подключили пользовательский метри c к жизненному циклу Mono, отправляя событие через KafkaSender.send (), и заметили, что это заняло около 100 мс. доставить сообщение.

Мы сделали это следующим образом:

send(event, code, getKafkaHeaders()).transform(withMetric("eventName"));

Метод send просто создает запись и отправляет ее:

 private Mono<Void> send(SpecificRecord value, String code, final List<Header> headers) {

         final var producerRecord = new ProducerRecord<>("myTopic", null, code, value, headers);
         final var record = Mono.just(SenderRecord.create(producerRecord, code));

         return Optional.ofNullable(kafkaSender.send(record)).orElseGet(Flux::empty)
                 .switchMap(this::errorIfAnyException)
                 .doOnNext(res -> log.info("Successfully sent event on topic {}", res.recordMetadata().topic()))
                 .then();
     }

И withMetri c преобразователь связывает метри c с жизненным циклом отправки моно:

private Function<Mono<Void>, Mono<Void>> withMetric(final String methodName) {

        return mono -> Mono.justOrEmpty(this.metricProvider)
                .map(provider -> provider.buildMethodExecutionTimeMetric(methodName, "kafka"))
                .flatMap(metric -> mono.doOnSubscribe(subscription -> metric.start())
                        .doOnTerminate(metric::end));
    }

Это пользовательский метри c, который возвращает в среднем 100 мс.

Мы сравнили его с нашей Kafka метрики производителя, и заметили, что они возвращаются и в среднем 40 мс для доставки сообщения (0 мс очереди и 40 мс задержки запроса).

У нас есть трудности с пониманием дельты, интересно, может ли она прийти метод Reactor Kafka для отправки событий.

Кто-нибудь может помочь, пожалуйста?

ОБНОВЛЕНИЕ

Вот пример конфигурации моего производителя:

acks = all
batch.size = 16384
buffer.memory = 33554432
client.dns.lookup = default
compression.type = none
connections.max.idle.ms = 540000
delivery.timeout.ms = 120000
enable.idempotence = true
key.serializer = class org.apache.kafka.common.serialization.StringSerializer
linger.ms = 0
max.block.ms = 60000
max.in.flight.requests.per.connection = 5
max.request.size = 1048576
metadata.max.age.ms = 300000
metrics.num.samples = 2
metrics.recording.level = INFO
metrics.sample.window.ms = 30000
partitioner.class = class org.apache.kafka.clients.producer.internals.DefaultPartitioner
receive.buffer.bytes = 32768
reconnect.backoff.max.ms = 1000
reconnect.backoff.ms = 50
request.timeout.ms = 30000
retries = 2147483647
retry.backoff.ms = 100
sasl.login.refresh.buffer.seconds = 300
sasl.login.refresh.min.period.seconds = 60
sasl.login.refresh.window.factor = 0.8
sasl.login.refresh.window.jitter = 0.05
sasl.mechanism = GSSAPI
security.protocol = PLAINTEXT
send.buffer.bytes = 131072
ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
ssl.endpoint.identification.algorithm = https
ssl.keystore.type = JKS
ssl.protocol = TLS
ssl.trustmanager.algorithm = PKIX
ssl.truststore.type = JKS
transaction.timeout.ms = 60000
value.serializer = class io.confluent.kafka.serializers.KafkaAvroSerializer

Также maxInFl ight 256, а планировщик один, здесь я ничего особенного не настраивал.