Когда переподключения ускоряют работу по сети. Разбираемся с быстродействием TCP-сокетов

[mbait]

Тесты - огонь! Посылаем полтора байта и ждём ответ, потому срываем покровы на хабре. Чем iperf не угодил?

[ftc]

А чем iperf поможет для организации IPC между плюсовым и PHP-шным приложениями? Изначально-то задача именно в этом стояла. А тут я решил детально разобраться, почему вариант "обмениваться через TCP сокеты" так странно себя ведёт.

[AlanDrakes]

У меня когда-то была обратная задача: собрать на минималистичном железе устройство для теста скорости. И из-за ограниченного объёма памяти для буфера приёма (микроконтроллер) мало что получилось. Хотя обмен данными по кабелю между ПК и устройством таки смог выжать почти 90МБит при TCP соединении.

[ftc]

А как получилось, что оно именно в память упиралось? Или там размер доступной памяти меньше чем MSS у TCP?

[AlanDrakes]

Размер доступной памяти был всего 40кБ, что куда как меньше 64кБ у окна. Приходилось изголяться. А для снижения нагрузки на процессорную часть пытался описать подобие Delayed-ACK, но выходила какая-то фигня. В итоге проект так и не заработал как надо из-за сложности и смены потребностей.

[rPman]

десятков тысяч rps так и не удалось достичь?

[ftc]

Не ставил себе такую цель. Хотя интересно, можно ли к варианту с shared memory приблизиться.

[ryo_oh_ki]

10 мс для сетевого пакета это ненормально долго. У вас принципиально что-то не так работает как должно.

[ftc]

Почитать бы где-нибудь на тему "а как оно правильнее всего делается".
Без учёта многопоточности конечно (т.е. оптимизируем именно обмен между двумя процессами, без попыток сэкономить CPU).

Или если мы тут упираемся в переключения контекста (система не отдаёт нам управление раньше, чем через 10мс) - тогда в таком варианте больше "выжать" не получится. Могу сказать, что у меня эксперимент не совсем чистый - на машине помимо этого теста много всякого крутится, потому это может влиять.

[ryo_oh_ki]

Или если мы тут упираемся в переключения контекста (система не отдаёт нам управление раньше, чем через 10мс)

Это не совсем так работает, "processor time slice" эффективен только при конкуренции за ресурсы ЦП, если есть свободное ядро - всё выполняется параллельно. Более того, это настраиваемый параметр. Но, не думаю, что в вашем случае это имеет значение.

[me21]

То есть у вас сначала в канал уходит 4 байта длины, потом отдельным пакетом тело? Выглядит, как будто алгоритм Нагля как раз отключён и мелкие пакеты не группируются.

[ftc]

Да, именно так. Причем получилось, что я делаю 2 раза write (длина, потом тело), а затем read. А в доке не delayed ack написано, что именно такой кейс работает плохо.

[Kohelet]

Вроде это основы — если вас интересует производительность, собирайте все, что нужно отправить, в одну операцию send.

[ftc]

Почему и написал эту статью - как по мне, получился хороший пример принципа дырявых абстракций. Мораль - если воспринимать TCP-коннект просто как канал, куда можно посылать и получать байты - можно получить неожиданные и неприятные эффекты.

[takeon]

net.ipv4.tcp_low_latency=1 сделает то что вы хотите. Или можно попроверять профили tuned, где есть в названии latency.

Ну и классическое

"после починки проблем с ACK"

Это не баг, это фича