Cloud Endpoints Framework версии 2 несогласованна и имеет высокую необъяснимую задержку

Недавно я перенес свое приложение с версии 1 Cloud Endpoints Frameworks на версию 2 (стандарт Python для App Engine). Предположительно, одним из преимуществ является уменьшение задержки запросов. Игнорируя прогрев и/или запуск экземпляра бэкенда, кажется, что я получал необъяснимую задержку вне наблюдаемых журналов/статистики приложений, где-то от 300 мс до 2 секунд. Наблюдая за этим около недели, я, наконец, просто вернулся к примеру с эхом и развернул его в тестовом приложении и заметил точно такое же поведение.

Пример эха: https://cloud.google.com/endpoints/docs/frameworks/python/get-started-frameworks-python

Вот соответствующие настройки экземпляра в моем app.yaml:

runtime: python27
env: standard
threadsafe: true
instance_class: B2
basic_scaling:
    idle_timeout: 900s
    max_instances: 2

Вот 3 запроса к API через curl с интервалом в несколько секунд. Тестовое приложение не должно делать ничего другого:

MacBook-Pro$ curl -H "Content-Type: application/json" -X POST -d '{"content":"hello world"}' https://testtictactoe-164905.appspot.com/_ah/api/echo/v1/echo -w "@curl-format.txt"
{
 "content": "hello world"
}
time_namelookup: 0.005
time_connect: 0.019
time_appconnect: 0.152
time_pretransfer: 0.152
time_redirect: 0.000
time_starttransfer: 0.263
--------
time_total: 0.263

MacBook-Pro$ curl -H "Content-Type: application/json" -X POST -d '{"content":"hello world"}' https://testtictactoe-164905.appspot.com/_ah/api/echo/v1/echo -w "@curl-format.txt"
{
 "content": "hello world"
}
time_namelookup: 0.005
time_connect: 0.020
time_appconnect: 0.144
time_pretransfer: 0.144
time_redirect: 0.000
time_starttransfer: 0.613
--------
time_total: 0.613

MacBook-Pro$ curl -H "Content-Type: application/json" -X POST -d '{"content":"hello world"}' https://testtictactoe-164905.appspot.com/_ah/api/echo/v1/echo -w "@curl-format.txt"
{
 "content": "hello world"
}
time_namelookup: 0.005
time_connect: 0.021
time_appconnect: 0.145
time_pretransfer: 0.145
time_redirect: 0.000
time_starttransfer: 1.028
--------
time_total: 1.028

Вот статистика приложения для первого 0,263-секундного запроса (всего 48 мс): введите здесь описание изображения Вот часть записи журнала для 0,263-секундного запроса: введите здесь описание изображения< /а>

Вот статистика приложения для 1,028-секундного запроса (всего 504 мс):

Статистика приложения для 1,028-секундного запроса Вот часть записи журнала для 1,028-секундного запроса введите здесь описание изображения

Вот задержка экземпляра за последний час:

введите здесь описание изображения

  1. Почему фактическая задержка моего запроса намного выше, чем показано в журналах и статистике приложения?
  2. Является ли эта дополнительная служебная задержка до 600 мс, которая кажется полностью неподконтрольной мне, просто ожидаемой частью выполнения запросов к конечным точкам облака Google?
  3. Почему эта задержка так сильно колеблется при работе с одним экземпляром и очень небольшим количеством входящих запросов?

person sbham    schedule 27.11.2017    source источник
comment
Я не уверен, к чему вы клоните. Предположительно, одним из преимуществ является уменьшение задержки запросов. Endpoints v2 на самом деле делает больше вещей (функции управления API), поэтому я не ожидаю уменьшения задержки.   -  person Rose Davidson    schedule 30.11.2017
comment
Получил это, прочитав эту ссылку: cloud.google.com/endpoints /docs/frameworks/legacy/v1/python/ Первый пункт списка преимуществ гласит: «Уменьшение задержки запросов».   -  person sbham    schedule 30.11.2017
comment
Спасибо; Я дважды проверю это внутренне.   -  person Rose Davidson    schedule 30.11.2017
comment
Не могли бы вы проверить, видите ли вы подобное предупреждение в своих журналах? нет потока планировщика, scheduler.run() будет вызываться отчетом   -  person Rose Davidson    schedule 19.12.2017
comment
Я только что запустил 10 команд curl для этого интерфейса, который давно не использовался, первая команда действительно содержала предупреждение: нет потока планировщика, scheduler.run() будет вызываться отчетом (...). В последующих 9 командах этого предупреждения не было. Задержка, по данным curl, варьировалась от 2,148 до 0,687 секунды. Если вам нужна полная копия моих журналов, дайте мне знать.   -  person sbham    schedule 21.12.2017
comment
Ответ @Codiak на этот вопрос: stackoverflow.com/questions/45585413/… очень помог с задержкой. Я полностью отказался от управления API, и большая часть моей изменчивой загадочной задержки исчезла.   -  person sbham    schedule 07.06.2018


Ответы (2)


Избавление от управления API помогло. Я попробовал это на основе ответа @Codiak на этот вопрос: stackoverflow.com/questions/45585413/

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

Для этого я в основном удалил эти две строки из app.yaml:

ENDPOINTS_SERVICE_NAME:

ENDPOINTS_SERVICE_VERSION: 2018-05-05r0

Я также удалил [apiname]openapi.json из своего проекта. Это также означает, что мне больше не нужно выполнять многие шаги, описанные здесь:

  1. https://cloud.google.com/endpoints/docs/frameworks/python/get-started-frameworks-python#deploy_configuration
  2. https://cloud.google.com/endpoints/docs/frameworks/python/get-started-frameworks-python#deploy_backend
person sbham    schedule 11.04.2020

Проблема с производительностью вашего приложения, вероятно, связана с тем, что функция управления API работает в потоке запросов, а не в фоновом потоке. Попробуйте установить «threadsafe: true» в вашем app.yaml.

person Rose Davidson    schedule 28.12.2017
comment
Я переключил флаг threadsafe, чтобы увидеть, имеет ли это значение, когда я впервые столкнулся с задержкой. Я просто вернул его в threadsafe: true. Еще 10 команд для эха API показывают около 200 мс журналов/трассировки, но фактический путь туда и обратно, как сообщает curl, по-прежнему находится в диапазоне от 600 мс до 1 секунды. Я все еще не понимаю, откуда берутся 800 мс необъяснимой задержки? - person sbham; 30.12.2017
comment
Возможно, мне просто нужно установить мои ожидания следующим образом при использовании конечных точек Google Cloud: 0-200 мс (время для подключения), ~ 250 мс (объясненный код обработки API, предполагающий отсутствие хранилища данных, наблюдаемый в трассировке / журналах), 0-500 мс (необъяснимое время + время для отправки ответа через http-запрос) По мере того, как API становится более сложным и фактически начинает делать запросы к хранилищу данных, пользователь должен ожидать 1-2-секундную задержку для каждого запроса API конечных точек. - person sbham; 30.12.2017