Может ли серверная опция "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Это ошибка переноса, а не ваша, поэтому вы не сможете контролировать сообщение об ошибке и код.