Обзор продукта облачных конечных точек гласит:
Расширяемый прокси-сервер службы обеспечивает безопасность и понимание менее чем за 1 мс на вызов.
Но я наблюдаю большечем 10 мс (может быть, 100 мс время от времени) добавленная задержка.
Наши настройки сервера:
- у нас есть кластер GKE, который имеет:
- Kubernetesразвертывание для модулей, каждый из которых имеет контейнер ESP и наш собственный контейнер, который обслуживает службу gRPC
- службу Kubernetes (типа
LoadBalancer), цель которой относится к контейнеру ESP
- у нас есть конфигурация конечной точки для службы gRPC, которая имеет только базовые компоненты, как показано ниже.
- мы выпустили ключ API для клиентов
У нас былоклиентская программа в другом кластере GKE в той же зоне для этого эксперимента.
С этим параметром наши эксперименты показали:
- с тайм-аутом 15 мс на стороне клиента, более 95% вызововистекло время ожидания
- Панель мониторинга конечных точек GCP, большинство запросов занимало более 100 мс
- на трассировке стекового драйвера, вся задержка принадлежит "Backend"
- , при измерении в нашем собственном контейнере задержка была ниже 5 мс
Загрузка ЦП сервера была очень низкой (ниже 10%), и в это время нет признаков перегрузки.
Если предположить, что gRPC не добавляет большой задержки, мы думаем, что задержка, вероятно, была изESP.
Итак, мы провели еще один эксперимент с обходом ESP:
- мы изменили сервис Kubernetes таким образом, чтобы он ссылался на наш собственный контейнер, а не на контейнер ESP
После этого исправления задержка, измеренная на клиенте, была снижена до 5 мс.
Итак, если наши эксперименты были правильными, кажется, что контейнер ESP добавляет задержку, а не 1 мс, что рекламируется в обзоре продукта.Мы что-то упустили?
Конфигурация конечной точки:
type: google.api.Service
config_version: 3
name: foo.endpoints.bar.cloud.goog
title: foo in bar
apis:
- name: com.bar.FooService