Суть этой проблемы в том, что наше приложение использует веб-сокеты для интерфейсов реального времени. Мы тестируем наше приложение в новой среде, но, как ни странно, мы замечаем увеличивающуюся задержку в TCP-пакетах websocket, связанную с увеличением активности websocket.
Например, если одно событие веб-сокета происходит без какой-либо другой активности в течение 1-минутного периода, ответ от сервера будет мгновенным. Однако, если мы медленно увеличиваем активность клиента, задержка в ответе сервера увеличивается с линейной зависимостью (каждому пакету потребуется больше времени, чтобы достичь клиента с большей активностью).
Для тех, кому интересно, это НЕ связано с приложением, поскольку наши журналы показывают, что наш сервер работает и отвечает на запросы менее чем за 100 мс по желанию. Задержка начинается, когда сервер обрабатывает запрос и создает пакет TCP и отправляет его клиенту (а не наоборот).
Архитектура Эта новая среда работает с виртуальным IP-адресом и использует поддержку активности на балансировщике нагрузки для балансировки трафика между экземплярами. За балансиром стоят два бокса, и весь трафик проходит через него. Наш хост-провайдер управляет балансировщиком, и мы не контролируем эту часть архитектуры.
Теория Может ли это быть как-то связано с буферизацией пакетов в новой среде?
Спасибо за вашу помощь.
Буферизация звучит как разумная теория. Я бы взял захват пакетов с ваших серверов приложений, чтобы убедиться, что вы не видите ничего вроде повторной передачи или другого, возможно, ненормального поведения в потоке TCP (например, обнуление окна TCP?). Wireshark с фильтром захвата для клиентского IP подойдет для этого.
Если вы убедитесь, что захват пакетов выглядит чистым, разумным будет попросить вашего провайдера запустить захват пакетов на его балансировщике нагрузки, чтобы вы могли выполнить анализ.
Наконец, проводили ли вы тестирование в разных местах и на разных машинах? Возможно, буферизация находится где-то между клиентом и провайдером, или с клиентом происходит что-то странное (запуск захвата пакетов на клиенте, а также на ваших серверах одновременно может быть поучительным).
На самом деле это ожидаемое поведение. По мере увеличения объема данных увеличивается размер окна передачи, что в определенной степени увеличивает размер отправляемых пакетов. Более крупные пакеты означают большую эффективность (меньше накладных расходов и времени, затрачиваемого на подтверждения), но они также означают большую задержку. Это компромисс для поддержания надежной доставки при сохранении любой пропускной способности в сетях с сильно различающимися задержками и пропускной способностью.
Проверьте флаг PSH, чтобы TCP быстрее очищал буферы. При некоторых обстоятельствах это может иметь незначительное значение. Однако, если вы ищете стабильно низкую задержку для большого количества небольших сообщений, вам может быть лучше взглянуть на UDP - это означает, что вам придется самостоятельно учитывать обеспечение доставки, но вы можете реализовать немного большую согласованность.