Часы работы моего внешнего интерфейса GAE продолжают увеличиваться, даже если приложение не используется и нет запущенных экземпляров (потому что я вручную закрыл их !!). В моем вопросе есть несколько подвопросов, вот они:
Что является основным компонентом, влияющим на часы работы внешнего экземпляра? В моей текущей реализации системы я широко использую следующие ресурсы Google: Memcache, очередь задач и хранилище данных NDB. Я точно знаю, что хранилище данных не имеет большого отношения к интерфейсным экземплярам (или, может быть, я ошибаюсь), но затрачивает ли Memcache часы работы внешних экземпляров? Вплоть до вчерашнего дня мое приложение работало отлично, и часы экземпляра использовались (как и следовало ожидать), поскольку использовалась очередь задач. Это заставило меня поверить, что основным фактором было использование очереди задач и отправка нескольких запросов за короткий период времени. Но сегодня утром я добавил дополнительное использование кэша памяти, и он начал действовать. Кроме того, влияют ли статические ресурсы на часы работы экземпляра?
Как оптимизировать приложение, что нужно учитывать в первую очередь? Вызовы Google API, URL-вызовы в целом, снова memcache?
Информация о приложении:
В моем файле app.yaml есть некоторая информация о конфигурации:
Мне нужно иметь четкое представление о часах работы экземпляра, сообщения, которые я прочитал здесь, недостаточно ясны! Если у вас есть глубокое понимание того, как Google вычисляет часы работы внешнего экземпляра, дайте мне знать! что заставляет его расти, как управлять этим и все такое.
Некоторый дополнительный визуальный контекст:
Как вы видите на этой картинке, нет развернутых экземпляров (иначе говоря, нет запущенных экземпляров), но биллинг только растет, и их сводная диаграмма просто сходит с ума !, посмотрите на все эти всплески!
Все будет очень признательно!
Как написано в Биллинг экземпляра, любой экземпляр будет работать не менее 15 минут, даже если он получит один запрос. Частично это сделано для того, чтобы у многих конечных пользователей не возникало задержки при запуске инстанса. Вместо этого экземпляр будет бездействовать и готов немедленно получить запросы.
Что касается того, как рассчитываются часы экземпляра, это основано на фактическом времени работы. Если инстанс F1 работает 2,5 часа, он потребляет около 2,5 часов инстанса. Количество часов экземпляра умножается на номер класса, как указано в Важный отметить в Цены на App Engine. Следовательно, для экземпляра F2, работающего в течение 2 часов, потребуется 4 часа экземпляра.
Когда дело доходит до оптимизации, лучше всего делегировать полномочия там, где это необходимо, и не тратить время зря. Например, предположим, что вашему обработчику необходимо получить 3 объекта, содержащие URL-адреса, из хранилища данных, а затем получить эти URL-адреса для некоторых данных JSON. Получение сущностей из хранилища данных занимает некоторое время. При использовании синхронной версии get вызовы, ваш обработчик по существу блокируется при получении сущностей. Использование асинхронного get_async версия того же вызова API позволит обработчику продолжить выполнение других задач, пока объекты извлекаются.
Точно так же получение URL-адресов может занять много времени. Выполнение этого синхронно может привести к зависанию обработчика, пока он ожидает их возврата. Задержка будет еще хуже, если эти запросы никогда не возвращаются или возвращаются только с таймаутом по умолчанию. Хотя urlfetch библиотека не имеет встроенной асинхронной выборки, многие сторонние библиотеки хорошо подходят для потоковой передачи в python. В go, вы можете получить эти URL-адреса в горутиках, которые выполняются одновременно. Это позволит обработчику не только продолжить выполнение других задач, но и, возможно, получить эти URL-адреса параллельно.
В зависимости от потребностей вашего приложения может быть много возможностей для параллельного проектирования. Это может значительно сократить время отклика для ваших экземпляров, позволяя им обрабатывать больше запросов или быстрее останавливаться, и то и другое потребует меньше часов работы экземпляра. Я бы предложил использовать Stackdriver Trace для изучения продолжительности жизни запроса. Это может быть полезно при выявлении узких мест. Обладая этой информацией, вы должны иметь представление о приоритетах оптимизации.
