Может ли серверная опция «MaxConcurrentStreams» считаться эквивалентом «Maximum_concurrent_rpcs» из grpc-python?

Question

Я внедряю сервер grpc (на ходу), где мне нужно ответить каким-либо сообщением о занятости / недоступности сервера, если мой сервер уже обслуживает установленное максимальное количество RPC (в настоящее время).

Я реализовал сервер grpc с grpc-python ранее, где я добился этого с помощью комбинации maximum_concurrent_rpcs и максимального количества потоков в threadpool.Я ищу что-то похожее в grpc-go.Самым близким, что я мог найти, был параметр сервера, который можно установить с помощью ServerOptions, возвращаемых путем вызова MaxConcurrentStreams.Мое приложение поддерживает только unary RPCs, и я не уверен, будет ли этот параметр применяться к этому.

Я просто пытаюсь установить / установить максимальное количество активных одновременных запросов, которые сервер может обработать.Будет ли установка maxConcurrentStreams работать или я должен смотреть на это в самом коде (я сделал для нее некоторую элементарную реализацию, но я бы предпочел использовать что-то, предоставленное grpc-go)?

Answer 1

Я никогда не использовал MaxConcurrentStreams раньше, потому что для высоконагруженных сервисов вы обычно хотите максимально использовать свое оборудование, и это ограничение, похоже, не имеет смысла. Возможно, можно достичь вашей цели с помощью этого параметра, но вам необходимо выяснить, какой тип ошибки возвращается при достижении MaxConcurrentStreams. Я думаю, что это должна быть ошибка транспорта GRPC, а не ваша, поэтому вы не сможете контролировать сообщение об ошибке и код.