Одновременные запросы на публикацию Google PubSub

В Google PubSub вызов публикации от клиента может вызываться асинхронно. Из-за этого я бы подумал, что можно было бы запускать и отправлять на сервер несколько запросов на публикацию одновременно, особенно если пороги пакета слишком низкие.

Если это правда, как клиент pubsub контролирует количество одновременных запросов на публикацию, которые могут быть созданы? Есть ли жесткое ограничение или ошибка, которая может возникнуть, если создается слишком много запросов? Является ли это предполагаемым использованием асинхронного издателя или просто разрешить другие действия, не связанные с публикацией?

Хотя этот вопрос относится к любому из клиентов, у нас конкретно проблема с клиентом C #, и мы периодически получаем следующую ошибку:

 Grpc.Core.RpcException: Status(StatusCode=DeadlineExceeded, Detail="Deadline Exceeded")
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Google.Api.Gax.Grpc.ApiCallRetryExtensions.<>c__DisplayClass0_0`2.<<WithRetry>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---

Я думаю, что мы отправляем слишком много запросов на публикацию ... но я не уверен.


person Paul Mazzuca    schedule 29.05.2018    source источник


Ответы (1)


Я бы посоветовал использовать необработанный код gRPC, но использовать клиентскую библиотеку с очень тонкой оболочкой.

Мне всегда помогает просмотр исходного кода клиента. Код C # можно найти здесь PublisherClient.cs (тонкая оболочка)

Если вы используете PublishAsync, он все равно ставит в очередь / пакетирует сообщения, поведение контролируется настройками, которые вы предоставляете клиенту (см. PublisherServiceApiClient, чтобы узнать, как его настроить). Вы также можете контролировать количество клиентских подключений, которые используются для отправки очередей в клиенте. Я предлагаю сначала поиграть с размером партии, а затем с количеством подключений, пока вы не найдете оптимальное место для вашей пропускной способности.

person alexvanboxel    schedule 01.06.2018