Отладка использования App Engine Требования к процессору и суммы

Question

Я был нагрузочным тестировщиком приложения, поэтому я настроил его на использование одного экземпляра типа по умолчанию (B1). Он имеет 256 МБ или ОЗУ и 600 МГц на 1 процессор (https://cloud.google.com/appengine/docs/standard).

У меня есть скрипт nodejs, который запускает скрипт php, который выполняет 1 MYSQL запрос поиска по таймеру. В настоящее время этот таймер проверяет четыре раза в секунду. Я хотел проверить, сколько пользователей это может поддерживать, поэтому я разделил таймер на разные величины, чтобы смоделировать, сколько операций будет использовать разное количество пользователей.

К моему ужасу, я обнаружил, что с 5 симулированными пользователями экземпляр работает примерно на 80% CPU. Это означает, что приложение выполняет l oop 40 раз в секунду, что похоже на 40 запросов HTTP в секунду. Я читал, что можно поддерживать 7200 запросов в секунду на сервере F1, который имеет те же характеристики, что и сервер B1. Ожидается ли такая высокая загрузка ЦП и / или есть ли что-то, что я могу сделать, чтобы отладить это и, возможно, сделать его более эффективным?

Вот дополнительная информация о ходе выполнения программы:

1. Пользователь подключается к socket.io и входит в комнату.

2. Сервер запускает скрипт по таймеру, который запускается 4 раза в секунду.

3. Сценарий использует child_process для запуска сценария php, который выполняет запрос MySQL к облачному SQL серверу, чтобы определить, были ли какие-либо обновления, которые стоит собрать из базы данных MySQL. (Сейчас я только проверяю, что обновлений не было, поэтому в этих тестах пропускаются дополнительные запросы.)

4. Сценарий php возвращает JSON данные на сервер, и сервер видит, что больше ничего не нужно делать.

   Обычно сценарий запускается только один раз для каждого типа комнаты (независимо от количества пользователей), но для проверки того, сколько может обработать сервер Я поделил длительность таймера на разные величины и обнаружил, что при 5-кратной частоте сервер работает на 80% ЦП. Технически это говорит о том, что, если постоянно появляется 4 новых сообщения, прогнозируется, что загрузка процессора составит около 80%. Мне это кажется высоким.

Итак, мне интересно, если child_process, выполняющий скрипт php, использует очень большие объемы ЦП, как это кажется единственное, что могло бы использовать так много. Инсайт или предложения приветствуются.

Answer 1

Я читал, что можно поддерживать 7200 запросов в секунду с сервером F1, который имеет те же характеристики, что и сервер B1. Ожидается ли такая высокая загрузка ЦП и / или есть ли что-то, что я могу сделать, чтобы отладить это и, возможно, сделать его более эффективным?

B1 - это не то же самое, что экземпляры F1. Хотя верно, что B1 и F1 имеют одинаковые спецификации, как вы указали здесь для экземпляров B1, единственными поддерживаемыми типами масштабирования являются ручное и базовое c.

Другими словами, экземпляры B1 масштабируются с использованием ручного и базового c масштабирования, что может вызвать проблемы, если вы не укажете ожидания своих приложений прямо в своем app.yaml.

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

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

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

Также, здесь вы найдете документацию о том, как обрабатывается запрос в стандарте Google App Engine, а также некоторые советы и рекомендации, которые можно использовать для повышения производительности и стабильности.

Наконец, если вы решите выполнить go с помощью класса экземпляра, который поддерживает автоматическое масштабирование c, включение запроса на разогрев может помочь не только уменьшить задержку, но и общую производительность вашего кода, загрузив копию fre sh вашего приложения до создания нового класса экземпляра. Здесь вы найдете больше информации о запросах на прогрев.

Надеюсь, это поможет.