Простое приложение HelloWorld на cloudrun (или 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
  • Тип интернет-соединения, которое я тестирую: Бизнес, Проводной
  • размер изображения контейнера приложения: 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 мс
Источник

1 ответ

Решение

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

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

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

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

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

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

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам