задержка выше при низком трафике с netty

#tcp #netty

#tcp #netty

Вопрос:

В нашей производственной среде возникла странная проблема: задержка выше при низком трафике. Затем я создаю Tcp-сервер и клиент с Netty4 и отправляю данные с помощью одного соединения. Каждый запрос составляет 100 КБ. Задержка в qps (запрос в секунду) = 1 намного выше, чем в qps = 100. Условия:

  1. Задержка PING между сервером и клиентом составляет около 2 мс.
  2. опция TCP_NODELAY включена с обеих сторон.
  3. на стороне сервера он будет находиться в режиме ожидания в течение 20 мс в ответ на использование (имитируя службу prod).

Результат теста:

  • < 24 мс при qps = 100 (100 КБ на запрос);
  • > 35 мс при qps = 1 (100 КБ на запрос);
  • < 23 мс при qps = 1 (1 КБ на запрос);

Задержка при разном размере пакета, когда qps = 1

  • частота пинга: 1,66 мс
  • 100 КБ — 39 мс
  • 50 КБ — 32 мс
  • 20 КБ — 27,38 мс
  • 17 КБ — 26,15 мс
  • 15 КБ — 25,9 мс
  • 10 КБ — 22,62 мс (что приемлемо)

Я хотел бы выяснить причину плохой производительности при низком трафике. Интересно, вызвано ли это некоторыми параметрами Tcp.

Комментарии:

1. В чем ваш вопрос? Пожалуйста, постарайтесь быть более конкретным, задавая вопрос.

2. Попробуйте отключить TCP_NODELAY. TCP_NODELAY ухудшает производительность для протоколов, предназначенных для наложения поверх TCP, и предназначен только в качестве дополнения для протоколов, не предназначенных для работы с TCP. Предположительно, поскольку вы создаете TCP-клиент и сервер, ваш протокол разработан для работы поверх TCP и не должен нуждаться в сбое.

3. Возможно, ваша проблема заключается в отключении процессора. Процессору может потребоваться несколько мс, чтобы вернуться к полной мощности после перерыва. При более высокой нагрузке процессор может находиться в менее глубоком режиме ожидания.

4. @TheChubbyPanda Я хочу выяснить, почему задержка выше при низком трафике, и получить такую же производительность при низком трафике, насколько это возможно.

5. @DavidSchwartz Я отключил TCP_NODELAY, но никакого эффекта. И есть какие-либо предложения по отключению процессора? Спасибо.

Ответ №1:

Наконец, мы выяснили причину этой проблемы с высокой задержкой и низким трафиком. При тестировании с различными размерами пакетов поворотным моментом стало 14 КБ: если размер пакета не превышал 14 КБ, задержка была ожидаемой, но если размер пакета увеличивался до 15 КБ, задержка ухудшалась. Итак, мы попытались обновить net.ipv4.tcp_init_cwnd с 10 до 100, задержка снизилась, поскольку запрос с несколькими пакетами TCP может быть включен в одно и то же скользящее окно.