#tcp #netty
#tcp #netty
Вопрос:
В нашей производственной среде возникла странная проблема: задержка выше при низком трафике. Затем я создаю Tcp-сервер и клиент с Netty4 и отправляю данные с помощью одного соединения. Каждый запрос составляет 100 КБ. Задержка в qps (запрос в секунду) = 1 намного выше, чем в qps = 100. Условия:
- Задержка PING между сервером и клиентом составляет около 2 мс.
- опция TCP_NODELAY включена с обеих сторон.
- на стороне сервера он будет находиться в режиме ожидания в течение 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 может быть включен в одно и то же скользящее окно.