Простое приложение HelloWorld в облачной среде (или Knative) кажется слишком медленным

Я развернул образец приложения HelloWorld на Google Cloud Run, который в основном равен k-native, и каждый вызов API непрерывно занимает в лучшем случае 1,4 секунды. Так должно быть?

Образец приложения находится по адресу https://cloud.google.com/run/docs/quickstarts/build-and-deploy

Я развернул то же самое приложение на своем локальном хосте в качестве контейнера докеров, и это занимает около 22 мс, сквозное выполнение.

То же приложение в моем GKE кластере занимает около 150 мс, сквозное выполнение.

import os

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    target = os.environ.get('TARGET', 'World')
    return 'Hello {}!\n'.format(target)

if __name__ == "__main__":
    app.run(debug=True,host='0.0.0.0',port=int(os.environ.get('PORT', 8080)))

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

Но сколько бы раз я ни выполнял команду, она не опускается ниже 1,4 секунды.

Я думаю, что расстояние в сети не является здесь доминирующим фактором. Время приема-передачи через ping до конечной точки API составляет всего 50 мс, более или менее.

Итак, мои вопросы следующие:

  1. Это потенциально непреднамеренная ошибка? Это техническая трудность, которая со временем будет решена? Или, может, все в порядке, это просто SLA k-native?

  2. Если с Google Cloud Run и / или k-native все в порядке, каков основной фактор затрат времени на мой вызов API? Очень хотелось бы изучить механизм.


Дополнительные детали:

  • Где я нахожусь: Сеул / Азия
  • Регион для моего приложения Cloud Run: us-central1
  • тип подключения к Интернету, который я тестирую: Business, Wired
  • размер изображения контейнера приложения: 343,3 МБ
  • местоположение корзины, которое использует Реестр контейнеров: gcr.io

время разминки WebPageTest из Сеула / Азии

  • Тип содержимого: текст / html
  • Начало запроса: 0,44 с
  • Поиск DNS: 249 мс
  • Первоначальное подключение: 59 мс
  • Согласование SSL: 106 мс
  • Время до первого байта: 961 мс
  • Загрузка контента: 2 мс

WebPageTest из Чикаго, США (время разминки):

  • Тип содержимого: текст / html
  • Начало запроса: 0,171 с
  • Поиск DNS: 41 мс
  • Первоначальное подключение: 29 мс
  • Согласование SSL: 57 мс
  • Время до первого байта: 61 мс
  • Загрузка контента: 3 мс

ОТВЕТ Steren, менеджера по продукту Cloud Run

Мы обнаружили высокую задержку при вызове сервисов Cloud Run из некоторых регионов мира. К сожалению, Сеул кажется одним из них.


person jin c    schedule 29.05.2019    source источник
comment
Вы видите какие-либо ошибки / сбои в журналах контейнера?   -  person Ahmet Alp Balkan    schedule 29.05.2019
comment
Я не могу воспроизвести это. Я развернул образец (github.com / knative / docs / tree / master / docs / serve / samples /) в мою учетную запись, и он постоянно обслуживает около 150 мс при подключении к моей домашней сети (кроме первого вызова). Пожалуйста, свяжитесь со службой поддержки Google Cloud и сообщите данные своей учетной записи / проекта.   -  person Ahmet Alp Balkan    schedule 29.05.2019


Ответы (2)


[Обновление: у этого человека проблемы с сетью в его районе. Я без проблем проверил его конечную точку из Сиэтла. Подробности в комментариях ниже.]

Последние несколько месяцев я постоянно работал с Cloud Run. Я развернул несколько производственных приложений и десятки тестовых сервисов. Я в Сиэтле, Cloud Run находится в центре США1. Я ни разу не заметил задержки. На самом деле я впечатлен тем, как быстро контейнер запускается.

Для одной из моих служб время холодного запуска до первого байта составляет 485 мс. Следующий вызов 266 мс, 360 мс. Мой контейнер проверяет сертификаты SSL (2) в Интернете. Время отклика очень хорошее.

Для другой службы, которая является веб-сайтом PHP, время до первого байта при холодном запуске составляет 312 мс, затем 94 мс, 112 мс.

Какие факторы могут отличаться для вас?

  1. Насколько велик ваш образ контейнера? Проверьте размер реестра контейнеров. Мои контейнеры меньше 100 МБ. Чем больше емкость, тем больше время холодного старта.
  2. Где находится корзина, которую использует Реестр контейнеров? Вы хотите, чтобы ведро было в us-central1 или, по крайней мере, в США. Это скоро изменится, когда будут объявлены новые регионы Cloud Run.
  3. Под каким типом подключения к Интернету вы тестируете? Домашний или деловой. Беспроводное или Ethernet-соединение? Откуда вы проводите тестирование? Запустите временный экземпляр Compute Engine, повторите тесты в Cloud Run и сравните. Это удалит вашего интернет-провайдера из уравнения.

Увеличьте объем памяти, выделенной контейнеру. Это влияет на производительность? Python / Flask не требует много памяти, мои контейнеры обычно имеют размер 128 МБ и 256 МБ. Образы контейнеров загружаются в память, поэтому, если у вас раздутый контейнер, у вас может остаться достаточно памяти, что снижает производительность.

Что вам показывают журналы Stackdriver? Вы можете видеть запуски контейнеров, запросы и завершения контейнеров.

person John Hanley    schedule 29.05.2019
comment
Я нахожусь в Южной Корее и регион такой же, как ваш, us-central1. Как вы думаете, проблема в сетевом расстоянии? Вот как я это рассчитал, только что. $ time curl https://helloworld-uplrvvyqza-uc.a.run.app/ Hello World! real 0m1.434s user 0m0.024s sys 0m0.008s Поскольку вы находитесь в Сиэтле, что вы увидите, если запустите ту же команду, что и моя: $ time curl https://helloworld-uplrvvyqza-uc.a.run.app/? - person jin c; 29.05.2019
comment
Не используйте time. Curl имеет встроенные функции. Вы хотите измерить время до первого байта: `curl example.com -w% {time_starttransfer} \ n. Однако вы не ответили ни на один мой вопрос, за исключением того, где вы находитесь. Вы должны выполнить работу по отладке, мы можем дать вам только совет. - person John Hanley; 29.05.2019
comment
И причина, по которой, я думаю, не будет проблемой расстояния в сети, заключается в следующем: $ ping -c 3 helloworld-uplrvvyqza-uc.a.run.app PING helloworld-uplrvvyqza-uc.a.run.app (216.239.36.53): 56 data bytes 64 bytes from 216.239.36.53: icmp_seq=0 ttl=53 time=36.539 ms 64 bytes from 216.239.36.53: icmp_seq=1 ttl=53 time=36.611 ms 64 bytes from 216.239.36.53: icmp_seq=2 ttl=53 time=40.553 ms --- helloworld-uplrvvyqza-uc.a.run.app ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 36.539/37.901/40.553/1.875 ms - person jin c; 29.05.2019
comment
Извините за путаницу. Я отвечу на то, о чем вы просили. Я просто хотел сначала вычеркнуть сетевой фактор. - person jin c; 29.05.2019
comment
Отредактируйте свой вопрос для получения дополнительной информации. Не используйте комментарии. Также я подробно рассказал, как это отладить. Использование time, ping и т. Д. Вам не поможет. Для проверки связи вы измеряете время отклика на интерфейс балансировщика нагрузки, а не на службу Cloud Run. - person John Hanley; 29.05.2019
comment
Хорошо, я редактирую вопрос. Спасибо за советы. Я вернусь к вам с более подробной информацией :) - person jin c; 29.05.2019
comment
Вы не исключили, что проблема в сети. Ping используется как окончательное решение. Нет. Это всего лишь инструмент для измерения времени приема-передачи для протокола ICMP. Это не имеет ничего общего с HTTP / HTTPS. - person John Hanley; 29.05.2019
comment
Примечание. Я не заметил вашего URL-адреса службы Cloud Run. Я только что проверил из Сиэтла. Я вижу нормальное время отклика (похоже на мое) - у вас на 30 мс быстрее. Я предполагаю, что это ваша связь с вашим интернет-провайдером. Запустите небольшой экземпляр рядом с вами и протестируйте его с помощью этого экземпляра. Это приведет к удалению вашего интернет-провайдера. - person John Hanley; 29.05.2019
comment
Предупреждение безопасности: поскольку вы опубликовали конечную точку службы. Удалите его и создайте новую службу с другим именем. Защити себя. - person John Hanley; 29.05.2019
comment
Я отредактировал свой вопрос. Я вижу тот же результат, что и ваш, когда запускаю cURL в США. Это достаточно быстро. Как вы думаете, можно ли с уверенностью сказать, что основная причина столь медленного движения из Сеула / Азии до моего приложения в us-central1 связана с задержкой между интернет-провайдерами? - person jin c; 30.05.2019
comment
И спасибо за предупреждение системы безопасности. Я собираюсь выключить его, пока не стало слишком поздно. - person jin c; 30.05.2019
comment
На данный момент я могу только догадываться. Я бы создал экземпляр виртуальной машины в Азии и протестировал бы оттуда. Ваша проблема, скорее всего, связана с подключением к Интернет-провайдеру. - person John Hanley; 30.05.2019
comment
Судя по всем метрикам, которые я собирал и регистрировал в Stackdriver, это связано с расстоянием в сети, а не с самим приложением. Приложение в основном завершает свою работу в течение 1 мс, поэтому теперь я могу сказать, что большая часть TTFB была предназначена для сети. Отсюда еще один вопрос к вам. Согласование SSL заняло всего 106 мс, тогда как TTFB занял 961 мс из Азии в центральный нас1. Разве в этом случае согласование SSL не проходит через интернет-провайдера? Почему вы думаете, что рукопожатие SSL занимает гораздо меньше времени, чем TTFB? Происходит ли согласование SSL где-то еще ближе ко мне, даже если я закручиваю свое приложение в us-central1? - person jin c; 31.05.2019
comment
Согласование SSL осуществляется между клиентом (например, веб-браузером) и интерфейсом балансировщика нагрузки Googe. Как только это будет завершено, Load Balancer будет прокси-сервером через HTTP в вашу службу Cloud Run. Я не знаю подробностей о значении интерфейса Cloud Run для обычных балансировщиков нагрузки HTTP; они глобальны. Учитывая, что Cloud Run находится в стадии бета-тестирования, в настоящее время они могут быть региональными (я предполагаю). Я бы создал новый вопрос, задав этот вопрос, поскольку команда Cloud Run отслеживает этот тег. Меня интересует ответ. - person John Hanley; 31.05.2019
comment
Однако при измерении вам необходимо четко указать, что вы измеряете и откуда. Ваш домашний Интернет не в счет - слишком много переменных для домашних интернет-провайдеров. - person John Hanley; 31.05.2019
comment
Спасибо вам за все. Я рассмотрю любой новый вопрос, который вы предложите :) - person jin c; 31.05.2019
comment
Еще кое-что. Что вы имели в виду под проблемой для my ISP? Было ли одной из ваших проблем, когда мой интернет-провайдер ограничивал исходящий трафик в Cloud Run? Или вы имели в виду какого-либо Интернет-провайдера между моим терминалом и моим приложением в Cloud Run? Какие возможные факторы со стороны интернет-провайдера, по вашему мнению, вызвали такой длинный TTFB (961 мс) для моего случая? - person jin c; 31.05.2019
comment
Я говорю о том, что ваш интернет-провайдер, мой интернет-провайдер и т. Д. Имеют шаблоны трафика, которые мы не можем контролировать. Все ваши соседи могут смотреть фильмы и т. Д. При устранении проблемы попробуйте удалить неизвестные, чтобы получить более точную информацию. - person John Hanley; 31.05.2019

(Менеджер по продукту Cloud Run здесь)

Мы обнаружили высокую задержку при вызове сервисов Cloud Run из некоторых регионов мира. К сожалению, Сеул кажется одним из них.

Мы явным образом обозначим это как известную проблему, и мы работаем над ее устранением, прежде чем Общие Доступность. Не стесняйтесь открывать новую проблему в нашей общедоступной системе отслеживания проблем

person Steren    schedule 03.06.2019
comment
Спасибо за то, что поделились. Почему такая высокая задержка из Мумбаи, Сеула и Сан-Паулу? Любая известная причина в деталях, пожалуйста? - person jin c; 04.06.2019