Я хочу использовать gRPC, чтобы предоставить интерфейс для двунаправленной передачи больших наборов данных (~ 100 МБ) между двумя службами. Поскольку gRPC по умолчанию устанавливает ограничение на размер сообщения в 4 МБ, похоже, что предпочтительный способ сделать это - вручную закодировать потоковую передачу фрагментов и повторно собрать их на принимающей стороне [1] [2].

Однако gRPC также позволяет увеличить предельный размер сообщения с помощью grpc.max_receive_message_length и grpc.max_send_message_length, что позволяет напрямую передавать сообщение размером до ~ 2 ГБ без ручного разделения на части или потоковой передачи. Быстрое тестирование показывает, что этот более простой подход одинаково хорошо работает с точки зрения производительности и пропускной способности, что делает его более желательным для этого варианта использования. Предположим, что весь набор данных необходим в памяти.

Один из этих подходов лучше другого? Есть ли какие-либо потенциальные побочные эффекты более простого подхода без фрагментов? Могу ли я рассчитывать на то, что фрагментация, зависящая от MTU, на нижних уровнях будет достаточной, чтобы избежать задержки в сети и других препятствий?


Ссылки:

  1. Разделение больших сообщений на части с помощью gRPC
  2. Отправка файлов через gRPC
2
w128 17 Окт 2019 в 12:31

1 ответ

Лучший ответ

Предел 4 МБ предназначен для защиты клиентов / серверов, которые не думали об ограничениях на размер сообщений. Сам gRPC нормально работает с гораздо большим объемом (100 МБ), но большинство приложений могут быть легко атакованы или случайно выходят за пределы памяти, что позволяет сообщениям такого размера.

Если вы хотите получать сообщение размером 100 МБ одновременно, то можно увеличить лимит.

3
Eric Anderson 17 Окт 2019 в 15:10