The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Предложение по включению режима TCP_NODELAY по умолчанию, opennews (??), 10-Май-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


18. "Предложение по включению режима TCP_NODELAY по умолчанию"  –3 +/
Сообщение от 12yoexpert (ok), 10-Май-24, 11:53 
Последний довод это какой-то вынос мозга, нет слов. Как будто кроме перекладывателей json-ов на свете больше никого нет
Ответить | Правка | Наверх | Cообщить модератору

22. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (6), 10-Май-24, 11:58 
Что ещё есть? Давай перечисляй.
Ответить | Правка | Наверх | Cообщить модератору

103. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от MaleDog (?), 11-Май-24, 21:40 
Любой алгоритм, где на надежность и гарантия доставки важнее скорости. Но нет, давайте сделаем, как удобнее "прикладникам", а не "сетевикам" и "системщикам". Это как с монгой по умолчанию выставим "0.0.0.0", а кому надо безопасно поставит "127.0.0.1". Напомнить к чему привело?
Ответить | Правка | Наверх | Cообщить модератору

23. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (23), 10-Май-24, 12:05 
Тут не идёт речь о "на свете". Речь об AWS.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

29. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от 12yoexpert (ok), 10-Май-24, 13:16 
нет, тут речь о дефолтном конфиге ядра
Ответить | Правка | Наверх | Cообщить модератору

42. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 10-Май-24, 14:51 
Он касается всех, не только перекладывателей json'а:

> Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.

Если ты дёргаешь ядро на каждый отправляемый байт, то либо ты никогда не слышал про буферизацию, либо тебе действительно _надо_ отправлять по байту, и ты готов терпеть накладные расходы на лишние сисколлы.

В первом случае, тебе следует заняться повышением образованности, и проложить между своим кодом и сисколлами прослойку буферизирующего стрима (в качестве грязного и дешёвого способа можешь использовать fdopen).

Во втором случае, ты сознательно отказываешься от буферизации, и ты будешь выставлять TCP_NODELAY, чтобы ядро не впихивало бы тебе её принудительно, чтобы жертвы производительности, принесённые тобою на алтарь сисколлов, не прошли бы даром.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

50. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (50), 10-Май-24, 16:55 
Это воннаби дед, у него от слов современный, api, json начинается кружится голова и мутнеет перед глазами.
Ответить | Правка | Наверх | Cообщить модератору

80. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:35 
Подход "сделаем всё сами правильно" это отказ от кооперации, когда в ядре за вас уже всё сделали давным давно.
Да, сисколы дорогие относительно буферизации в приложении, но не факт что в приложении получится сделать лучше и что этим вообще стоит заниматся.

Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.
А таймер это ещё один сискол...

В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

107. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 12-Май-24, 09:07 
> Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.

Идеальная замена алгоритма буферизации, не потребует ничего этого. В ядре генерализованный алгоритм, который ничего не знает о характере генерации данных, и поэтому ориентируется на таймер. Юзерспейс, же, генерирующий данные, может поступать интереснее. Например, если тебе надо отправить http запрос, ты можешь создать буфер в десяток килобайт, и писать запрос туда, чтобы потом одним сисколлом отправить. Если буфер маловат для запроса, скидываешь содержимое в ядро и продолжаешь писать в него. Нет никакой нужды в таймерах. Юзерспейс часто знает, когда важно отправлять данные немедленно по мере появления, когда нет смысла отправлять раньше времени (половину http запроса бессмысленно отправлять пораньше, прежде чем ты вторую дописал), а когда требуется более сложная и менее эффективная схема как в ядре.

Если тебе нужен таймер для буферизации, то тебе уже не повезло с задачей, и имеет смысл остановиться и подумать, а нельзя ли как-нибудь без него.

> А таймер это ещё один сискол...

Попробуй посчитать. Вот представь, что приложение генерирует данные по байту, что временя до следующего байта распределяется по Пуассону. Приложение хотело бы байты отправлять по мере появления, чтобы не терять латенси, но готово отчасти пожертвовать латенси ради срупута. Зная задержку на буферизацию в ядре, попробуй прикинуть при каких лямбдах буферизация в ядре будет выгоднее периодической (10 раз в сек?) обработки SIGALRM, а потом попробуй нафантазировать случай, который реализует такую лямбду, при этом хотя бы отдалённо выглядя реалистично. В этом случае, ведь, надо чтобы требования к задержкам со стороны задачи примерно бы совпадали с тем, что ядро использует. На осмысленность экономии трёх байт трафика, давай забьём, примем её как данность, чтобы не сравнивать яблоки с апельсинами, экономию трафика и латенси.

> В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Было бы убедительнее, если бы ты привёл пример.

Ответить | Правка | Наверх | Cообщить модератору

108. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 12-Май-24, 10:47 
Как минимум при прототипировании не имеет смысла возится вообще с буферизацией у себя.
В остальном для любой задачи где частота вызова не сильно высокая и не будет расти количество таких писаталей.
Какой нить датчик или сериал порт.


SIGALRM - это какое то жуткое легаси, create_timer_fd(), kqueue() - вот современные методы.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру