Ожидаемая производительность с getstream.io

Question

Документация getstream.io гласит, что можно ожидать получение канала примерно через 60 мс. Когда я получаю свои фиды, они содержат поле с именем "длительность", которое, как я понимаю, является рассчитанным временем обработки на стороне сервера. Это значение стабильно составляет около 10-40 мс, в среднем около 15 мс.

Проблема в том, что я редко получаю свои корма менее чем за 150 мс, а среднее время составляет около 200-250 мс, а иногда до 300-400 мс. Это время для получения одного фида, без обогащения и т. Д., И я проверил с помощью tcpdump, что обратная связь по сети низка (около 25 мс), и что время фактически потрачено на ожидание ответа сервера.

Я пытался перемещаться по своему приложению (eu-west и eu-central), но, похоже, это не сильно влияет (опять же, сеть туда и обратно стабильно составляет около 25 мс).

Мой вопрос - действительно ли я должен ожидать 60 мс и продолжать расследование, или 200-400 мс - это нормально? На сайте getstream.io объясняется, что учетные записи разработчиков получают "Низкую приоритетность обработки" - что это означает на практике? Какую разницу я мог ожидать с другим планом?

Я использую нод API низкого уровня.

Answer 1

Потоковые API используют SSL для шифрования трафика. К сожалению, SSL вводит дополнительный сетевой ввод / вывод. Обычно вам нужно платить за увеличенную задержку только один раз, потому что API-интерфейсы Stream HTTP поддерживают постоянное соединение HTTP (так называемое keep-alive).

Вот снимок экрана Wireshark для TCP-трафика двух последовательных запросов API с поддержкой активности клиента на стороне:

4 строки красного цвета указывают на то, что TCP-соединение закрывается каждый раз. Еще одна интересная вещь заключается в том, что рукопожатие занимает почти 100 мс и выполняется дважды (первая связка строк).

После некоторого исследования выясняется, что в библиотеке, используемой для выполнения запросов API к API-интерфейсам Stream (request), функция keep-alive по умолчанию не включена. Такое изменение скоро станет частью библиотеки и доступно в ветке разработки.

Вот скриншот тех же двух запросов с включенным keep-alive (с использованием кода из этой ветки):

На этот раз соединение больше не сбрасывается, и второй HTTP-запрос не выполняет SSL-квитирование.