GRPC: зробити клієнт з високою пропускною спроможністю в Java / Scala

У мене є сервіс, який передає повідомлення з досить високою швидкістю.

Наразі його обслуговує akka-tcp, і він повідомляє 3,5 млн повідомлень в хвилину. Я вирішив спробувати grpc. На жаль, це призвело до набагато меншої пропускної здатності: ~ 500k повідомлень в хвилину ще менше.

Чи можете ви порадити, як оптимізувати це?

Моя установка

Обладнання : 32 ядра, купа 24 Гбіт.

версія GRPC: 1.25.0

Формат повідомлення та кінцева точка

Повідомлення в основному є двійковим крапом. Клієнт передає 100K - 1М і більше повідомлень в один запит (асинхронно), сервер нічим не відповідає, клієнт використовує спостережника

service MyService {
    rpc send (stream MyMessage) returns (stream DummyResponse);
}

message MyMessage {
    int64 someField = 1;
    bytes payload = 2;  //not huge
}

message DummyResponse {
}

Проблеми: Частота повідомлень низька порівняно з реалізацією akka. Я спостерігаю низьке використання процесора, тому я підозрюю, що виклик grpc насправді блокується внутрішньо, незважаючи на те, що йдеться про інше. Виклик onNext()дійсно не повертається одразу, але на столі також є GC.

Я спробував породити більше відправників, щоб пом’якшити цю проблему, але не покращився.

Мої висновки Grpc фактично виділяє 8 Кбайт байтовий буфер на кожне повідомлення при його серіалізації. Дивіться стек-трек:

java.lang.Thread.State: BLOCKED (на моніторі об’єктів) на com.google.common.io.ByteStreams.createBuffer (ByteStreams.java:58) на com.google.common.io.ByteStreams.copy (ByteStreams.java: 105) на io.grpc.internal.MessageFramer.writeToOutputStream (MessageFramer.java:274) на io.grpc.internal.MessageFramer.writeKknownLengthUncompression (MessageFramer.java:230) at io.grpc.internal.MessageFramer.writeUncompression (Message : 168) на io.grpc.internal.MessageFramer.writePayload (MessageFramer.java:141) на io.grpc.internal.Ab абстрактStream.writeMessage (AbstractStream.java:53) на io.grpc.internal.ForwardingClientStream.writeMessage (ForwardingClientStream. java: 37) на io.grpc.internal.DelayedStream.writeMessage (DelayedStream.java:252) на io.grpc.internal.ClientCallImpl. (ForwardingClientCall.java:37) на io.grpc.stub.ClientCalls $ CallToStreamObserverAdapter.onNext (ClientCalls.java:346)

Була вдячна будь-яка допомога щодо передового досвіду створення клієнтів високої пропускної здатності.

Я вирішив цю проблему, створивши кілька ManagedChannelпримірників на місце призначення. Незважаючи на статті, що на базі ManagedChannelможна породжувати достатньо з'єднань, тому одного екземпляра достатньо, в моєму випадку це не було правдою.

Продуктивність відповідає рівню реалізації akka-tcp.

Цікаве запитання. Пакети комп'ютерної мережі кодуються за допомогою стека протоколів , і такі протоколи будуються на версії специфікацій попереднього. Отже, продуктивність (пропускна здатність) протоколу обмежена продуктивністю того, який використовується для його побудови, оскільки ви додаєте додаткові кроки кодування / декодування поверх нижнього.

Наприклад gRPC, побудовано поверх HTTP 1.1/2, що є протоколом на рівні додатка , або L7, і як його виконання пов'язана продуктивність HTTP. Тепер HTTPсама побудована поверх TCP, що знаходиться на транспортному шарі , або L4, тому ми можемо зробити висновок, що gRPCпропускна здатність не може бути більшою, ніж еквівалентний код, що подається в TCPшарі.

Іншими словами: якщо ваш сервер здатний обробляти необроблені TCPпакети, як додавання нових шарів складності ( gRPC) покращило б продуктивність?

Я дуже вражений тим, як добре тут виступав Akka TCP: D

Наш досвід був дещо іншим. Ми працювали над значно меншими екземплярами, використовуючи кластер Akka. Для видалення Akka ми перейшли від Akka TCP до UDP за допомогою Artery і домоглися набагато вищої швидкості + нижчого та стабільного часу відгуку. В Artery є навіть конфігурація, яка допомагає збалансувати споживання процесора та час реакції з холодного початку.

Моя пропозиція полягає в тому, щоб використовувати деяку основу на основі UDP, яка також піклується про надійність передачі для вас (наприклад, UDP Artery), а також просто серіалізувати за допомогою Protobuf, а не використовувати gRPC з повною плоттю. Канал передачі HTTP / 2 насправді не має високої пропускної здатності з низьким часом відгуку.