Как решить проблему Высокая задержка в движке приложения, вызванная этим запросом, вызвала запуск нового процесса для вашего приложения?

Приложение, работающее со стандартной средой app engine, python 3.7 и облачным sql (Mysql)

При проверке журналов есть некоторые с очень высокой задержкой (более 4 секунд), когда ожидаемая величина составляет 800 мс. Все эти журналы сопровождаются этим сообщением:

«Этот запрос вызвал запуск нового процесса для вашего приложения и, таким образом, вызвал загрузку кода вашего приложения в первый раз. Таким образом, этот запрос может занять больше времени и использовать больше ЦП, чем обычный запрос для вашего приложения».

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

У меня вопрос: как можно уменьшить эти задержки?

Конфигурация движка приложения:

runtime: python37
env: standard
instance_class: F1
handlers:
  - url: /static/(.*)
    static_files: static/\1
    require_matching_file: false
    upload: static/.*
  - url: /.*
    script: auto
    secure: always
  - url: .*
    script: auto
automatic_scaling:
  min_idle_instances: automatic
  max_idle_instances: automatic
  min_pending_latency: automatic
  max_pending_latency: automatic
network: {}

person ozo    schedule 22.10.2019    source источник
comment
Не просматривая подробные журналы Stackdriver и файл app.yaml, это сообщение означает «холодный запуск» для вашего приложения. У вас включено автомасштабирование до нуля? Добавьте в свой вопрос больше информации.   -  person John Hanley    schedule 22.10.2019
comment
@JohnHanley Отредактировано. В трассировке я не вижу много полезной информации, поскольку шкала времени показывает на графике только полосу с задержкой ›3 секунды, а в информации говорится, что метод HTTP был POST, а код состояния HTTP был 200   -  person ozo    schedule 22.10.2019
comment
@ozo ты когда-нибудь разбирался в этом?   -  person Alex Fox    schedule 19.04.2020


Ответы (2)


Как вы заметили, эти более медленные запросы происходят всякий раз, когда движку приложения необходимо запустить новый экземпляр для вашего приложения, поскольку начальная загрузка медленная (они называются " запросы на загрузку ").

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

Это может немного увеличить ваши затраты, но должно уменьшить задержку запроса загрузки, поскольку эти фиктивные запросы будут расходовать затраты на запуск нового экземпляра.

В среде выполнения python 3.7 вы можете добавить элемент «разминки» в директиву inbound_services в app.yaml:

inbound_services:
- warmup

Это отправит запрос на /_ah/warmup, где, если хотите, вы можете выполнить любую другую инициализацию, необходимую экземпляру (например, запустить пул соединений с БД).

person robsiemb    schedule 22.10.2019

Есть другие стратегии, которые могут помочь вам уменьшить задержки в вашем приложении.

Вы можете изменить свои параметры автоматического масштабирования < / a>, чтобы использовать что-то, что лучше подходит для вашего приложения.

Вы можете лучше управлять своей пропускной способностью, установив соответствующий кеш -Контролируйте заголовок в своих ответах и ​​установите разумное время истечения срока действия для статических файлов.

Такое использование общедоступных заголовков Cache-Control позволит прокси-серверам и браузеру ваших клиентов кэшировать ответы на указанный период времени.

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

Вы также можете включить одновременные запросы и напишите код как можно асинхронно.

person Andrei Tigau    schedule 23.10.2019