gRPC — это современный высокопроизводительный протокол удалённого вызова процедур (RPC), широко используемый для обеспечения надёжной и масштабируемой коммуникации между микросервисами и распределёнными системами. Благодаря основанию на HTTP/2 и поддержке мультиплексирования потоков, gRPC позволяет эффективно распределять нагрузку и обеспечивает строгую согласованность данных при работе с распределёнными базами данных, такими как YDB. Однако при работе с сетями с очень низкой задержкой иногда возникает неожиданное узкое место, связанное с клиентской частью gRPC, которое может существенно ограничить производительность системы. Обнаружение и понимание причин этого феномена открывают возможности для повышения эффективности и позволяют улучшить показатели как по пропускной способности, так и по задержке отклика. В инфраструктуре YDB, распределённой SQL базы данных с поддержкой ACID транзакций, gRPC используется как основной протокол взаимодействия клиента и сервера.
Исследования показали, что при уменьшении количества узлов кластера рост загрузки системы становится менее эффективным, а клиентская задержка начинает расти. При этом возникает парадоксальная ситуация: ресурс сервера остаётся незагруженным, а клиент всё чаще простаивает, ожидая завершения запросов. Анализ узких мест позволил выявить, что проблемный сегмент находится именно на стороне клиента gRPC. Ключевой особенностью gRPC является наличие нескольких каналов, каждый из которых поддерживает множество параллельных потоков вызовов (RPC). Все они работают поверх HTTP/2, который отвечает за мультиплексирование данных по одному TCP-соединению.
Теоретически, при правильной настройке, один канал может эффективно обрабатывать большое количество параллельных запросов, что должно обеспечивать линейное масштабирование производительности. Однако на практике оказалось, что при использовании одинаковых параметров для каналов все они начинают делить одно TCP-соединение, создавая узкое место и надолго задерживая обработку запросов. Проблема усугубляется тем, что в gRPC по умолчанию существует ограничение на количество одновременных потоков HTTP/2 — порядка 100. Когда это ограничение достигается, новые вызовы RPC ставятся в очередь и ждут освобождения потоков. В системах с очень низкой сетевой задержкой это приводит к тому, что клиент большую часть времени простаивает, что снижает общий потенциал производительности.
Для проверки и воспроизведения проблемы была создана простая микро-бенчмарковая программа на C++, использующая последнюю версию gRPC. Клиент запускается с определённым числом потоков-воркеров, каждый из которых отправляет запросы синхронно или асинхронно, используя отдельные каналы. При этом общий объём одновременных запросов соответствует количеству активных воркеров. Тесты проводились в условиях реального сетевого окружения с пропускной способностью 50 Гбит/с и минимальной сетевой задержкой — менее 0,05 миллисекунд. Результаты тестирования продемонстрировали, что при увеличении числа параллельных запросов рост пропускной способности резко замедляется, а задержка обработки начинает расти почти линейно.
Анализ сетевого трафика с помощью tcpdump и Wireshark подтвердил, что сеть и сервер не являются узким местом: не наблюдалось конгестии, пакетных потерь или значительных задержек на уровне TCP. Основная задержка формировалась на клиенте, с явными промежутками бездействия между отправкой запросов и получением ответов. Дальнейшее исследование выявило, что каналы с одинаковыми параметрами по умолчанию используют общий пул подканалов, что приводит к совместному использованию одного TCP-соединения. Это объясняет отсутствие пропорционального роста пропускной способности и рост задержек при увеличении числа клиентов или параллельных запросов. Для устранения проблемы была предложена реализация с использованием отдельного канала для каждого воркера, при этом каждому каналу назначались уникальные аргументы, что гарантировало создание отдельных TCP-соединений.
Аналогичный эффект достигается активацией специального параметра конфигурации GRPC_ARG_USE_LOCAL_SUBCHANNEL_POOL. При таком подходе клиентская часть gRPC перестала становиться узким местом, и показатели по пропускной способности выросли почти в шесть раз при сохранении низких задержек. Особенно заметны улучшения были при нагрузках с небольшим временем отклика. В сетях с типичной задержкой в несколько миллисекунд различия между одноканальными и многоканальными подходами менее значительны, поскольку накладные расходы на ожидание ответов сети и так доминируют. Однако в сверхнизкозадерживающих сетях решение с множественными каналами и уникальными параметрами является критически важным для получения максимальной эффективности.
Эти наблюдения показывают, что рекомендации по gRPC, предлагающие либо разделять нагрузку по каналам, либо использовать пул каналов, на самом деле являются частями единого подхода, направленного на устранение узкого места на клиентской стороне. Совмещение этих методов открывает возможности для существенного улучшения производительности без серьёзных изменений архитектуры приложения. Понимание и устранение данного узкого места особенно важно в контексте систем обработки больших объёмов данных в реальном времени, микросервисных архитектур с высокими требованиями к отзывчивости и масштабируемости, а также при использовании распределённых баз данных с жёсткими гарантиями согласованности. Правильное распределение каналов и соединений клиента позволяет не только повысить пропускную способность, но и снизить латентность, что критично для поддержки SLA и обеспечения качественного пользовательского опыта. Дальнейшие исследования могут быть направлены на выявление возможных дополнительных оптимизаций внутри gRPC, улучшение механизмов управления пулом каналов и снижение остатков накладных расходов на уровне сетевого и клиентского стека.
Сообщества разработчиков и пользователей gRPC могут совместно работать над предложением улучшений и дополнений к текущей реализации протокола для поддержки сценариев сверхнизкой задержки и высоконагруженных систем. Таким образом, проблема неожиданного узкого места на клиенте gRPC в низкозадерживающих сетях выявляет важность детального анализа и тонкой настройки коммуникационных протоколов в современных распределённых системах. Применение описанных практик позволяет разработчикам эффективно использовать потенциал gRPC и добиваться высоких результатов в производительности и надёжности приложений, работающих в масштабируемых и динамичных инфраструктурах.
