Производительность и тюнинг

У производительности gRPC три метрики, и тюнят их по-разному. Первая — latency: время одного вызова, причём важны не средние, а хвосты — p95 и p99, потому что именно хвосты формируют пользовательский опыт. Вторая — пропускная способность: сколько RPC в секунду выдерживает сервис при заданном latency. Третья — память: gRPC-транспорт буферизует сообщения и фреймы, и каждый поднятый лимит — это возможные мегабайты в куче под пиком нагрузки. Прежде чем крутить любую ручку из этого урока, зафиксируйте все три цифры: микробенчмарки testing.B и профили pprof вы строили в уроке про бенчмарки, нагрузку гоняют хотя бы grpcurl или скриптом из прошлого урока на bufconn — зелёный тест не отвечает на вопрос «быстро ли», но отвечает на вопрос «чёй-то сломалось после тюнинга». Правило одной ручки — то же, что в бенчмаркинге: за итерацию меняем ровно одну настройку и пересчитываем цифры, иначе не узнаете, что именно помогло. И запомните, где живут все ручки курса: DialOption у grpc.NewClient, ServerOption у grpc.NewServer и CallOption на отдельный вызов — ни одна из них не в proto-схеме и не в коде хендлеров.

Все настройки транспорта grpc-go собираются в одном месте — в опциях конструктора. Сервер: grpc.NewServer(grpc.MaxRecvMsgSize(...), grpc.KeepaliveParams(...), ...) — каждая функция возвращает ServerOption. Клиент: grpc.NewClient(grpc.WithKeepaliveParams(...), grpc.WithDefaultCallOptions(...)) — DialOption. На один вызов: CallOption вроде grpc.MaxCallRecvMsgSize, который можно передать и точечно, и через WithDefaultCallOptions как дефолт канала. Сами параметры keepalive вынесены в отдельный пакет google.golang.org/grpc/keepalive — его документация лаконична: «Package keepalive defines configurable parameters for point-to-point healthcheck» — настраиваемые параметры точка-точка-проверки живости. Пять семейств ручек этого урока: размеры сообщений (MaxRecvMsgSize, MaxSendMsgSize и клиентские CallOption-близнецы), keepalive-пинги (ClientParameters, ServerParameters, EnforcementPolicy), окна HTTP/2 (InitialWindowSize и BDP-оценщик), MaxConcurrentStreams и idle-таймауты (MaxConnectionIdle, MaxConnectionAge, WithIdleTimeout). Важное следствие из прошлых уроков: все эти настройки — deploy-конфигурация, а не бизнес-логика, поэтому интеграционные тесты на bufconn из двадцать первого урока их не проверяют по умолчанию — тестовый сервер собирается с дефолтными опциями, и это честно: проверять надо контракт, а не конфиг. Конфиг проверяется экспериментом и замером.

TCP-соединение может тихо умереть: NAT-таблица маршрутизатора выкинула запись, балансировщик закрыл простой, пир упал вместе с сетевым кабелем — FIN не придёт, и соединение будет выглядеть живым, пока вы не попробуете в него написать. Дедлайны из четырнадцатого урока ловят это на уровне одного RPC, а keepalive — на уровне соединения: клиент сам, без вашего кода, отправляет PING-фрейм HTTP/2 — восьмибайтовый payload без данных, — и если ответа нет, закрывает соединение. Плюс пинги не дают инфраструктуре выкинуть «простаивающий» коннект: NAT и балансировщики смотрят на трафик, а пинг — это трафик. Всю механику задаёт пакет keepalive; документация ClientParameters предупреждает заранее: «Make sure these parameters are set in coordination with the keepalive policy on the server, as incompatible settings can result in closing of connection» — несовместимые настройки по обе стороны соединения приводят к разрывам. Дефолты асимметричны: сервер пингует сам (ServerParameters.Time по умолчанию 2 * time.Hour), а клиент выключен — включать его нужно осознанно, и делать это нужно парой с серверной политикой, иначе получите самую знаменитую ловушку курса — GOAWAY too_many_pings, до которой дойдём через два блока.

Три поля, три дефолта, три решения. Time — документация: «After a duration of this time if the client doesn't see any activity it pings the server to see if the transport is still alive» — столько тишины, после чего клиент шлёт PING. Дефолт — infinity, то есть выключено. С практическим значением помогает простое правило: ставьте Time меньше, чем таймаут простоя у NAT и балансировщика на пути, — обычно это минуты, а не секунды. Timeout: «After having pinged for keepalive check, the client waits for a duration of Timeout and if no activity is seen even after that the connection is closed» — сколько ждать PING ACK; дефолт 20 секунд, разумно 5–10. PermitWithoutStream: «If true, client sends keepalive pings even with no active RPCs. If false, when there are no active RPCs, Time and Timeout will be ignored and no keepalive pings will be sent» — пинговать ли соединение, на котором сейчас нет ни одного RPC. Включайте, только если сервер разрешает (EnforcementPolicy.PermitWithoutStream), — иначе пинги без стримов превращаются в страйки. И ещё одна строка документации, которую стоит выучить наизусть: «Note that gRPC servers have a default EnforcementPolicy.MinTime of 5 minutes (which means the client shouldn't ping more frequently than every 5 minutes)». Хорошая новость сразу за ней: «Time will automatically double if the server disconnects due to its enforcement policy» — клиент grpc-go умеет сам отходить назад, удваивая интервал, когда сервер порвал соединение за нарушение политики; это поведение из пропозала A8 client-side keepalive.

ServerParameters — документация пакета: «ServerParameters is used to set keepalive and max-age parameters on the server-side». Пять полей. MaxConnectionIdle: «a duration for the amount of time after which an idle connection would be closed by sending a GoAway. Idleness duration is defined since the most recent time the number of outstanding RPCs became zero or the connection establishment» — сколько соединение простаивает без единого RPC, прежде чем сервер отправит GoAway. MaxConnectionAge: «a duration for the maximum amount of time a connection may exist before it will be closed by sending a GoAway. A random jitter of +/-10% will be added to MaxConnectionAge to spread out connection storms» — принудительный перекат соединений, причём джиттер ±10% добавлен специально, чтобы все коннекты, поднятые одновременно, не умирали одной волной. MaxConnectionAgeGrace: «an additive period after MaxConnectionAge after which the connection will be forcibly closed» — льгота на дообработку начатых RPC. Time: «After a duration of this time if the server doesn't see any activity it pings the client» — дефолт 2 часа, и минимум с подстраховкой: «If set below 1s, a minimum value of 1s will be used instead» (константа KeepaliveMinServerPingTime = time.Second; меньшее значение grpc-go поправит с предупреждением «Adjusting keepalive ping interval to minimum period of 1s»). Timeout — 20 секунд. EnforcementPolicy (опция grpc.KeepaliveEnforcementPolicy) — «used to set keepalive enforcement policy on the server-side. Server will close connection with a client that violates this policy»: MinTime по умолчанию 5 минут (defaultKeepalivePolicyMinTime = 5 * time.Minute), PermitWithoutStream — «If true, server allows keepalive pings even when there are no active streams(RPCs). If false, and client sends ping when there are no active streams, server will send GOAWAY and close the connection». Отдельная деталь механики: счётчик страйков обнуляется, когда сервер шлёт клиенту данные или заголовки — комментарий поля resetPingStrikes: «This is set whenever data or header frames are sent» — живой трафик реабилитирует даже нарушителя.

Дефолты и ошибку ResourceExhausted с текстом «grpc: received message larger than max (%d vs. %d)» вы уже видели в уроке про проводной формат — четыре мебибайта на приём, math.MaxInt32 на отправку, декомпрессия режется на границе лимита. Вопрос этого урока — какие значения ставить, когда легальный бизнес-объект не влезает. Первое: лимит приёма — защита памяти от чужих данных. Каждый принимаемый байт попадает в буферы до того, как вы разберёте поля, а буферы транспорта идут из пула (mem.BufferPool) и переиспользуются; потолок в гигабайт «на всякий случай» означает, что один недоброжелатель (или один баг клиента) в сто параллельных вызовах съест память сервера. Ставьте чуть выше самого большого легального сообщения — например, 8 МБ при реальном максимуме в 6. Второе: прежде чем поднимать потолок, спросите, не должен ли это быть стрим. Отчёт на двенадцать мегабайт — это кандидатов в server streaming по образцу WatchOrders из седьмого урока: каждый элемент стрима проходит лимит отдельно, память размазывается по времени, клиент начинает обрабатывать данные до конца передачи. Третье: лимиты ставятся парой на обоих концах — сервер отправил, клиент обязан принять. Четвёртое, одной фразой про компрессию: сжатие gzip из девятнадцатого урока экономит байты провода, но не спасает от лимита — gRPC применяет потолок и к результату декомпрессии. И потолок protobuf в два гибибайта из того же урока напоминает: физический предел вы всё равно не поднимете.

Flow control HTTP/2 защищает от ситуации, когда быстрый отправитель топит медленного получателя: у каждого направления есть окна на двух уровнях — стрима и соединения; получатель продвигает их WINDOW_UPDATE-фреймами по мере чтения. Стартовое окно задаёт спецификация HTTP/2 — в defaults.go это defaultWindowSize = 65535 с комментарием «The default value of flow control window size in HTTP2 spec»: 64 КиБ. Но grpc-go не сидит на этом дефолте: транспорт носит BDP-оценщик — измеритель bandwidth-delay product, произведения пропускной способности канала на время его задержки. Как работает: транспорт отправляет служебный PING с восемью байтами данных {2, 4, 16, 16, 9, 14, 7, 7} — в исходниках это easter-egg, комментарий приглашает: «Easter-egg: what does the ping message say?» (байты читаются как буквы B-D-P-P-I-N-G-G), — и меряет, сколько данных успело приехать за один RTT. Оценка растёт множителем gamma = 2, сглаживается alpha = 0.9, включается при beta = 0.66, и потолок задан константой bdpLimit = (1 << 20) * 16 с комментарием: «bdpLimit is the maximum value the flow control windows will be increased to. TCP typically limits this to 4MB, but some systems go up to 16MB. Since this is only a limit, it is safe to make it optimistic» — то есть окна автоматически растут от 64 КиБ до 16 МиБ. Ручки под это есть: grpc.InitialWindowSize и grpc.InitialConnWindowSize у сервера, grpc.WithInitialWindowSize и grpc.WithInitialConnWindowSize у клиента — «The lower bound for window size is 64K and any value smaller than that will be ignored». Но документация StaticStreamWindowSize честно остужает энтузиазм: «Most users should not configure static flow control windows unless operating in a memory-constrained environment» — статические окна отключают BDP-динамику, и обычному приложению лезть туда не нужно. Правило курса: окна — последняя ручка, которую вы трогаете, и только под замером.

HTTP/2 мультиплексирует все RPC одного соединения в независимые стримы — десятки параллельных вызовов едут по одному TCP-сокету без головной блокировки на установке соединений. Оборотная сторона: без лимита один жадный клиент открывает столько стримов, сколько серверу придётся обслуживать, — соединение становится вектором перегрузки. Лимит и есть SETTINGS MAX_CONCURRENT_STREAMS; серверная ручка — grpc.MaxConcurrentStreams(n), документация: «MaxConcurrentStreams returns a ServerOption that will apply a limit on the number of concurrent streams to each ServerTransport» — на каждый транспорт, то есть на каждое соединение, а не на процесс в целом. Дефолт сервера — math.MaxUint32 из defaultServerOptions: не ограничено; ноль в вызове опции превращается в тот же MaxUint32. У клиента свой внутренний потолок — defaultMaxStreamsClient = 100 из internal/transport/defaults.go с механикой streamQuota: сверх квоты стримы ждут на соединении, а SETTINGS сервера обновляют клиентский лимит на лету (обработчик SETTINGS перечитывает MAX_CONCURRENT_STREAMS и двигает t.maxConcurrentStreams). Практика: ставьте явный MaxConcurrentStreams, когда за соединением стоит неуправляемый клиент или когда за сервером — медленный бэкенд (база, которую затопит тысяча параллельных GetOrder); лимит превращает лавину в аккуратную очередь и даёт клиенту сигнал уходить на другие соединения. Но помните связку с балансировщиком из шестнадцатого урока: лимит стримов — предохранитель, а не замена раскладке нагрузки.

Продакшен любит соединения с истекающим сроком годности — они сами раскладывают нагрузку и вымывают утечки. Серверные ручки вы уже видели в ServerParameters. MaxConnectionIdle закрывает GoAway-ом простаивающее соединение — «idleness duration is defined since the most recent time the number of outstanding RPCs became zero»; MaxConnectionAge ограничивает максимальный возраст: «a duration for the maximum amount of time a connection may exist before it will be closed by sending a GoAway. A random jitter of +/-10% will be added to MaxConnectionAge to spread out connection storms»; MaxConnectionAgeGrace — «an additive period after MaxConnectionAge after which the connection will be forcibly closed». Все три дефолтно равны infinity. Клиентская сторона — DialOption grpc.WithIdleTimeout, и документация описывает два уровня: «If the channel is idle for the configured timeout, i.e there are no ongoing RPCs and no new RPCs are initiated, the channel will enter idle mode and as a result the name resolver and load balancer will be shut down. The channel will exit idle mode when the Connect() method is called or when an RPC is initiated» — канал уходит в idle и глушит резолвер с балансировщиком; «A default timeout of 30 minutes will be used if this dial option is not set at dial time and idleness can be disabled by passing a timeout of zero». Разница уровней важна: MaxConnectionAge — принудительный перекат транспорта (GoAway, клиент молча переоткроет соединение), idle-канал — экономия ресурсов клиента, когда RPC нет вовсе; дедлайны же из четырнадцатого урока — про тайм-аут отдельного вызова, это третья, независимая ось времени.

Честная оговорка про формат, одна на урок: в самоучителе есть песочница с интерпретатором Go, но сеть в браузере недоступна — gRPC-сервер и клиент в браузере не запустить, поэтому runner-ов в этом уроке, как и во всём gRPC-курсе, нет; каждое упражнение делается локально за несколько минут, а проверяют вас quiz, predict, fill, order и карточки. Эксперимент первый, самый зрелищный: поднимите дефолтный сервер из четвёртого урока, а клиент соберите с Time: 30 time.Second и PermitWithoutStream: true — и молчите; в логах клиента появится «Client received GoAway with error code ENHANCE_YOUR_CALM and debug data equal to ASCII "too_many_pings"», а сервер зафиксирует разрыв. Затем добавьте серверу EnforcementPolicy{MinTime: 30 time.Second, PermitWithoutStream: true} и убедитесь, что соединение стало вечным. Эксперимент второй: поднимите MaxRecvMsgSize на сервере до 8 МБ, но забудьте про клиентский MaxCallRecvMsgSize, отправьте 6-мегабайтный ответ и разберите ResourceExhausted по цифрам в тексте ошибки — какая сторона отстала видно мгновенно. Эксперимент третий: задайте MaxConnectionAge: 5 * time.Second на сервере и понаблюдайте в подробных логах, как соединения перекатываются GoAway-ами — и как джиттер разбрасывает моменты разрыва.

Курс подходит к развязке: у вас есть транспорт, безопасность, наблюдаемость, тесты и теперь — карта ручек производительности. Двадцать третий урок — gRPC в микросервисной архитектуре — поднимает масштаб: gateway-паттерны, облако и обзор service mesh, где половину ручек этого урока перекладывают на прокси вроде Envoy, а keepalive-политика из хитрого эксперимента превращается в контракт между командами, записанный в манифестах деплоя. Имеет смысл перечитать этот урок как справочник, а не как рассказ: таблица-шпаргалка выше — то, что вы будете открывать при каждом «прод тормозит». Напоследок три связки. Полный маршрут курса — в оглавлении gRPC-курса; форматы и gzip вы разбирали в уроке про проводной формат; и перед любым тюнингом прогоняйте bufconn-набор из урока про тестирование — зелёный тест после изменения настроек транспорта значит, что контракт цел, а выиграли вы или проиграли покажет только замер.