Блог

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

Это мой случай: у меня есть проект AMP (https://amp.dev /) веб-сайта электронной коммерции. Поэтому у меня нет никакого статического URL-адреса, по которому я мог бы настроить запрос на прогрев, который рекомендует Google App Engine. URL-адрес такой: amp.store/product/{productname} , поэтому {productname} он динамический, у меня более 1000 продуктов, и я не могу отправить запрос на этот URL-адрес, чтобы мой экземпляр всегда был в рабочем состоянии.

app.yaml:

 runtime: php55
api_version: 1
service: amp-page

handlers:
- url: .*
  script: main.php

skip_files:....
 

Когда я пытаюсь PageSpeed Insights из Google, я получаю эту ошибку с первой попытки:

Маяк вернул ошибку: ERRORED_DOCUMENT_REQUEST. Lighthouse не удалось надежно загрузить запрошенную страницу. Убедитесь, что вы тестируете правильный URL-адрес и что сервер правильно отвечает на все запросы. (Код состояния: 500)

Теперь, когда я пытаюсь снова сразу после того, как я часто получаю 84/100 (мобильный) 99/100 (рабочий стол).

Это огромная разница, вот почему я спрашиваю. Решит ли это проблему с ручным масштабированием или есть какой-либо другой способ ускорить мой экземпляр или запрос, например, со второй попытки?

Спасибо!

Чтобы поддерживать хотя бы один запущенный экземпляр (даже при отсутствии трафика), вы хотите установить для элемента app.yaml масштабирования min_instances значение 1 :

min_instances

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

Укажите значение от 0 до 1000. Вы можете установить для параметра значение 0, чтобы разрешить масштабирование до 0 экземпляров для снижения затрат, когда запросы не обслуживаются. Обратите внимание, что с вас взимается плата за указанное количество экземпляров, независимо от того, получают они трафик или нет.

Важно: если вы используете appcfg из App Engine SDK для развертывания PHP, вы не сможете использовать этот параметр в своем app.yaml. Вместо этого установите параметр, как описано в разделе Настройка параметров автоматического масштабирования в обозревателе API или с помощью API администратора App Engine.

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

Примечание: вы также можете настроить запросы на прогрев (создание их URL-адреса является частью этого, это не произвольный статический URL-адрес), чтобы еще больше снизить вероятность того, что запросы пользователей станут запросами на загрузку. Вы не можете полностью их устранить — экземпляры не живут вечно, а запросы на прогрев не эффективны на 100%, это просто лучшее решение.

Одним из вариантов было бы создать задание cron через ваш cron.файл yaml, который будет запрашивать известную страницу каждые X минут, чтобы гарантировать, что у вас всегда работает один экземпляр.

Создайте в своем приложении единый обработчик, который выполняет php-скрипт и возвращает какой-то результат. Что-то, что не является тяжелым для базы данных. Может быть таким же простым, как эхо «ок»;