Простое приложение HelloWorld в cloudrun (или knative) кажется слишком медленным
Я развернул образец приложения HelloWorld на Google Cloud Run, который в основном представляет собой k-native, и каждый вызов API занимает в лучшем случае 1,4 секунды в сквозном режиме. Так должно быть?
Пример приложения находится по адресу https://cloud.google.com/run/docs/quickstarts/сборка-и-развертывание.
Я развернул то же самое приложение на своем локальном хосте в качестве контейнера докеров, и это заняло около 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 мс, более или менее.
Итак, мои вопросы заключаются в следующем:
Это потенциально непреднамеренная ошибка? Это техническая трудность, которая будет решена в конце концов? А может, ничего страшного, просто SLA
k-native?Если все в порядке с
Google Cloud Runи/илиk-native, то какой фактор является доминирующим фактором, отнимающим время для моего вызова API? Я хотел бы изучить механизм.
Дополнительные детали:
- Где я нахожусь: Сеул/Азия
- Регион для моего приложения Cloud Run: us-central1
- тип подключения к Интернету, который я тестирую: бизнес, проводной
- размер образа контейнера приложения: 343,3 МБ
- расположение ведра, которое использует Container Registry: gcr.io
Веб-страницаТест из Сеула/Азии (время разогрева):
- Тип контента: текст/html
- Начало запроса: 0,44 с
- Поиск DNS: 249 мс
- Начальное соединение: 59 мс
- Согласование SSL: 106 мс
- Время до первого байта: 961 мс
- Загрузка контента: 2 мс
Веб-страницаТест из Чикаго/США (время разогрева):
- Тип контента: текст/html
- Начало запроса: 0,171 с
- Поиск DNS: 41 мс
- Начальное соединение: 29 мс
- Согласование SSL: 57 мс
- Время до первого байта: 61 мс
- Загрузка контента: 3 мс
ОТВЕТ Стерена, менеджера по продукту Cloud Run
We have detected high latency when calling Cloud Run services from some particular regions in the world. Sadly, Seoul seems to be one of them.
Я не могу воспроизвести это. Я развернул образец (github.com/knative/docs/tree/master/docs/serving/samples/…) в своей учетной записи, и он постоянно обслуживает около 150 мс при подключении к домашней сети (кроме первого вызова). Пожалуйста, свяжитесь со службой поддержки Google Cloud и сообщите данные своей учетной записи/проекта.
Ответы 2
[Обновление: у этого человека проблемы с сетью в его районе. Я проверил его конечную точку из Сиэтла без проблем. Подробности в комментариях ниже.]
Последние несколько месяцев я постоянно работал с Cloud Run. Я развернул несколько производственных приложений и десятки тестовых сервисов. Я в Сиэтле, Cloud Run в us-central1. Я никогда не замечал задержки. На самом деле, я впечатлен тем, как быстро запускается контейнер.
Для одной из моих служб я вижу время холодного запуска до первого байта 485 мс. Следующий вызов 266 мс, 360 мс. Мой контейнер проверяет сертификаты SSL (2) в Интернете. Время отклика очень хорошее.
Для другого сервиса, который является веб-сайтом PHP, время до первого байта при холодном запуске составляет 312 мс, затем 94 мс, 112 мс.
Какие факторы могут отличаться для вас?
- Насколько велик ваш образ контейнера? Проверьте Container Registry, чтобы узнать размер. Мои контейнеры меньше 100 МБ. Чем больше емкость, тем дольше время холодного старта.
- Где находится сегмент, который использует Container Registry? Вы хотите, чтобы ведро было в us-central1 или, по крайней мере, в US. Это скоро изменится, когда будут объявлены новые регионы Cloud Run.
- Какой тип подключения к Интернету вы тестируете? Домашний или Бизнес. Беспроводное или Ethernet-соединение? Откуда вы тестируете? Запустите временный экземпляр Compute Engine, повторите свои тесты в Cloud Run и сравните. Это удалит вашего интернет-провайдера из уравнения.
Увеличьте объем памяти, выделенной контейнеру. Влияет ли это на производительность? Python/Flask не требует много памяти, мои контейнеры обычно имеют размер 128 МБ и 256 МБ. Образы контейнеров загружаются в память, поэтому, если у вас есть раздутый контейнер, теперь у вас может быть достаточно памяти, что снижает производительность.
Что показывают журналы Stackdriver? Вы можете видеть запуск контейнера, запросы и завершение контейнера.
Я нахожусь в Южной Корее, и регион такой же, как у вас, 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/?
Не используйте time. Curl имеет встроенные функции. Вы хотите измерить время до первого байта: `curl example.com -w "%{time_starttransfer}\n". Однако вы не ответили ни на один вопрос, который я задал, кроме того, где вы находитесь. Вы должны выполнить работу по отладке, мы можем только дать вам совет.
И причина, по которой я думаю, что это не будет проблемой сетевого расстояния, заключается в следующем: $ 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
Извините за путаницу. Я собираюсь ответить на то, что вы просили. Я просто хотел сначала вычеркнуть сетевой фактор.
Отредактируйте свой вопрос для получения дополнительной информации. Не используйте комментарии. Кроме того, я подробно рассказал, как это отлаживать. Использование time, ping и т. д. вам не поможет. Для проверки связи вы измеряете время отклика на внешний интерфейс балансировщика нагрузки, а не на службу Cloud Run.
Хорошо, я отредактирую вопрос. Спасибо за советы. Я вернусь к вам с более подробной информацией :)
Вы не исключили, что проблема в сети. Пингом злоупотребляют как окончательным решением. Это не. Это просто инструмент для измерения времени приема-передачи для протокола ICMP. Это не имеет ничего общего с HTTP/HTTPS.
Примечание. Я не заметил URL вашего сервиса Cloud Run. Я только что проверил из Сиэтла. Я вижу нормальное время отклика (похожее на мое) - ваше быстрее на 30 мс. Я предполагаю, что ваше соединение с вашим провайдером. Запустите небольшой экземпляр рядом с вами и протестируйте его. Это удалит ваше соединение с провайдером.
Предупреждение о безопасности: поскольку вы опубликовали конечную точку службы. Удалите его и создайте новую службу с другим именем. Защити себя.
Я отредактировал свой вопрос. Я вижу тот же результат, что и ваш, когда запускаю cURL в США. Это достаточно быстро. Теперь, как вы думаете, можно с уверенностью сказать, что основная причина такой медленной доставки из Сеула/Азии в мое приложение в us-central1 связана с задержкой между поставщиками услуг Интернета?
И спасибо за предупреждение безопасности. Я собираюсь закрыть его, пока не стало слишком поздно.
На данный момент я могу только предполагать. Я бы создал экземпляр виртуальной машины в Азии и протестировал его оттуда. Ваша проблема, скорее всего, связана с подключением к провайдеру.
Согласно всем метрикам, которые я собрал и записал в Stackdriver, это связано с удаленностью сети, а не с самим приложением. Приложение в основном завершает свою работу в течение 1 мс, поэтому теперь я могу сказать, что большая часть TTFB была предназначена для сети. Отсюда еще один вопрос к вам. Согласование SSL заняло всего 106 мс, тогда как TTFB потребовалось 961 мс от Азии до us-central1. В этом случае согласование SSL не проходит через интернет-провайдера? Почему вы предполагаете, что рукопожатие SSL занимает гораздо меньше времени, чем TTFB? Происходит ли согласование SSL где-то еще ближе ко мне, даже если я использую cURL своего приложения в us-central1?
Согласование SSL происходит между клиентом (например, веб-браузером) и внешним интерфейсом Google Load Balancer. Как только это будет завершено, балансировщик нагрузки проксирует через HTTP вашу службу Cloud Run. Я не знаю подробностей о значении Cloud Run Front-end для обычных балансировщиков нагрузки HTTP; они глобальны. Учитывая, что Cloud Run находится в стадии бета-тестирования, в настоящее время они могут быть региональными (я предполагаю). Я бы создал новый вопрос с этим вопросом, поскольку команда Cloud Run отслеживает этот тег. Меня интересует ответ.
Тем не менее, при измерении вы должны быть точны в том, что вы измеряете и откуда. Ваш домашний интернет не в счет — слишком много переменных для домашних интернет-провайдеров.
Спасибо тебе за все. Я рассмотрю новый вопрос, любой из предложенных вами :)
Еще кое-что. Что вы имели в виду под проблемой для my ISP? Был ли мой интернет-провайдер, ограничивающий исходящий трафик в Cloud Run, одной из ваших проблем? Или вы имели в виду каких-либо/некоторых интернет-провайдеров между моим терминалом и моим приложением в Cloud Run? Какие возможные факторы со стороны интернет-провайдера, по вашему мнению, вызвали такой длинный TTFB (961 мс) для моего случая?
Я имею в виду, что у вашего провайдера, моего провайдера и т. д. есть шаблоны трафика, которые мы не можем контролировать. Все ваши соседи могут смотреть фильмы и т. д. При отладке проблемы постарайтесь удалить неизвестные, чтобы получить более точную информацию.
(менеджер продукта Cloud Run здесь)
Мы обнаружили большую задержку при вызове служб Cloud Run из некоторых регионов мира. К сожалению, Сеул, похоже, один из них.
Мы явно зафиксируем это как Известная проблема, и мы работаем над исправлением этого перед общедоступной версией. Не стесняйтесь открывать новую тему в нашем публичный трекер проблем
Спасибо, что поделились. Почему такая высокая задержка из Мумбаи, Сеула и Сан-Паулу? Любая известная причина в деталях, пожалуйста?
Видите ли вы какие-либо ошибки/сбои в журналах контейнера?