Push / Sub push return 503 для базового масштабирования

Question

Я использую принудительную подписку Pub / Sub, крайний срок подтверждения установлен на 10 минут, конечная точка push размещается в AppEngine с использованием масштабирования basic.В моих журналах я вижу, что некоторые из push-запросов Pub / Sub (предположительно доставленных в стартовые экземпляры) не выполняются с 503 состоянием ошибки и Request was aborted after waiting too long to attempt to service your request. сообщением журнала.Время выполнения этого запроса варьируется от 10 секунд (для большинства запросов) до 30 секунд для некоторых из них.Согласно этой статье https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed#instance_scaling Deadlines для HTTP-запроса составляет 24 часа, и запрос не должен прерываться в течение 10 секунд.Есть ли способ избежать таких исключений?

Answer 1

Эти неудавшиеся запросы, скорее всего, имеют тайм-аут в очереди ожидающих запросов , что означает, что для их обслуживания нет доступных экземпляров.Это обычно происходит во время всплесков сообщений PubSub, которые доставляются в пакетном режиме, и App Engine не может масштабироваться достаточно быстро, чтобы справиться с ними.

Один из способов уменьшить это - переключить параметр масштабирования на автоматическое масштабирование в вашем файле app.yaml.Вы можете настроить min_pending_latency и max_pending_latency, чтобы лучше соответствовать вашему сценарию.Вы также можете указать min_idle_instances для получения неактивных экземпляров, которые были бы готовы обрабатывать дополнительную нагрузку (обязательно включите и обработайте запросы прогрева )

Примите во внимание, что PubSub будет автоматическиПовторите попытку доставить ошибочные сообщения.Он будет регулировать скорость доставки в соответствии с поведением вашей системы, как описано здесь .Таким образом, вы можете столкнуться с некоторыми ошибками во время всплесков сообщений, когда создаются новые экземпляры, но ваши сообщения будут в конечном итоге обрабатываться (если вы настроили max_instances достаточно высоко, чтобы справиться с нагрузкой).