#google-cloud-platform #google-cloud-bigtable
#google-cloud-platform #google-cloud-bigtable
Вопрос:
У нас есть контейнерное интернет-приложение GKE, обслуживающее входящий трафик / запрос в Bigtable через балансировщик нагрузки (завершение ssl в Nginx). Запросы синхронны по своей природе. Мы используем клиентскую библиотеку Bigtable на C для взаимодействия с Bigtable. См.- https://github.com/googleapis/google-cloud-cpp
Большинство вызовов «GET» занимают 40-50 мс, что кажется довольно необычным. Я также исследовал Bigtable «Инструмент визуализации ключей» и не вижу никаких проблем с Rowkey и schema.
Чтобы подтвердить, что Bigtable работает нормально из модуля, я запустил образец «hello world» и попытался синхронно получить ответ для примеров строк, и большинство вызовов «GET» занимают 4-5 мс. Теперь я совершенно не уверен, что то, что вызывает вызовы «GET» через одни и те же строки, занимает так много времени, чтобы вернуть ответ, если он вызывается через приложение.
Следует учитывать задержку в сети, но тогда это также приведет к задержке времени отклика для примера кода Python «Hello World». Кроме того, узлы кластера Bigtable и GKE находятся в одной зоне.
Есть идеи, в каких областях я должен искать то же самое для устранения неполадок?
Ответ №1:
Единственное, что приходит на ум, — это начальные накладные расходы на создание bigtable::Table объекта. Вы кэшируете объект между запросами? Возможно ли это сделать?
Второй областью будет аутентификация, хотя я предполагаю, что вы используете один и тот же метод аутентификации как для Python ‘Hello World’, так и для приложения C ?
Если это не поможет, свяжитесь со мной, мой адрес электронной почты должно быть легко найти на сайте GitHub.
Комментарии:
1. Разрыв между двумя последовательными вызовами GET также может быть фактором, нет? Пример кода Python ‘Hello World’ не предлагает никакого промежутка между двумя последовательными чтениями, но фактическое приложение имеет промежуток в 4-5 мс между двумя последовательными чтениями. Не уверен, что этот пробел может оказать такое значительное влияние, вызывая задержку до 40-50 мс. Мысли?
2. Я смог выполнить ваше первое предложение по кэшированию объекта table. Запустил приложение на виртуальной машине и получил задержку в 10-12 мс для каждой строки, но в кластере GKE я все еще вижу задержку в 45-50 мс. Пожалуйста, предложите для GKE.
3. > Не уверен, что этот пробел может оказать такое значительное влияние, вызывая задержку до 40-50 мс. Мысли? Я не думаю, что это могло бы привести к гораздо более длительным «пробелам» (скажем, 1 час), поскольку токены были бы недействительными и нуждались в обновлении, а сокеты могли быть отключены> Что касается эффекта GKE: у меня нет идей. Можете ли вы открыть заявку в службе поддержки?
4. Справедливо ли это предположение о том, что могут быть проблемы с совместимостью между клиентской библиотекой Bigtable C и GKE? Код Python отлично работает при взаимодействии с Bigtable из GKE pod. Озадачен, узнав, что тот же фрагмент кода C также отлично работает на виртуальной машине, но затрудняет работу с GKE.
5. К вашему сведению, я отправил ошибку для нас (Google), чтобы отследить это: github.com/googleapis/google-cloud-cpp/issues/5697