оптимизация пересылки данных по сети в Linux ч 3

По приведенному URL русских версий статей не наблюдается...

По приведенному URL русских версий статей не наблюдается...

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

Почему выпендрёж?
Часто ищешь нужную доку, а она есть только на венгерском или на датском.
Переводчика-венгра тогда что-ли искать?
А английский все знают. Лучше писать универсальные доки

Специально для ненашедших: http://www.sw.ru/r/upload/builder_2002_03_12_russian.pdf http://www.sw.ru/r/upload/builder_2002_03_26_russian.pdf третья статья еще не размещена, скоро будет.

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

Alex Tormasov

2Tor: все-таки, используют ли последние в 1.3.x ветки апачи приведенные подходы по уменьшению времени отклика и минимизации пересылки данных? Как я понял, нет - а почему так? В каким ОС кроме Linux и BSD реализавана TCP_DEFER_ACCEPT? Ну и показательный вопрос для всяких Ogr'ов, ирсей и Бл*зменов - что Вы думаете о виндовом TCP стеке? Есть ли там хоть одна из перечисленных Вами в статье опций для сокетов? На сколько (в %) увеличивается производительность веб-сервера, скажем отдающего статику из Апача, при использовании всех указанных опций на сокеты, и с умом? Большое спасибо за ответы заранее!

Вопрос: почему по опциям TCP стэк в линуксе не сделать так же как в BSD, т.е. за чем надо было SO_ACCEPTFILTER обзывать как TCP_DEFER_ACCEPT?
Что касается опций w2k tcp то см. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wsap...

> 2Tor: все-таки, используют ли последние в 1.3.x ветки апачи приведенные подходы по уменьшению времени отклика и минимизации
> пересылки данных? Как я понял, нет - а почему так? 

Вопрос не по адресу.


> В каким ОС кроме Linux и BSD реализавана TCP_DEFER_ACCEPT?

Возможно в AIX. Возможно в win2000.


> Ну и показательный
> вопрос для всяких Ogr'ов, ирсей и Бл*зменов - что Вы думаете о виндовом TCP стеке?

Я про него не думаю. :-)

В nt никакого "стека" не было, было что-то жалкое.
В win2000 --- нормальный честный стек, не хуже прочих, а то и получше.
Про XP не знаю ничего.


>    Есть ли там хоть одна из перечисленных Вами в
> статье опций для сокетов?

sendfile там есть. Есть еще acceptx() (accept() + получение headerа),
который подразумевает deferred accept. Больше ничего не знаю, ms не
публикует какие-либо документы описывающих функционирование на таком уровне.
По крайней мере, API который использовал IIS во времена mindcraft
так и остался тотально секретным.


> На сколько (в %) увеличивается производительность веб-сервера, скажем отдающего статику из Апача, при
> использовании всех указанных опций на сокеты, и с умом?

Из апача как он есть манипуляции с ackами можно даже не заметить.
Что такое пара-тройка пакетов с его жутким оверхедом?

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

Alexey

Алексей, было очень интересно услышать Ваши ответы. Большое спасибо!
Есть еще несколько вопросов:
Что Вы можете сказать об оптимальности/быстродействии TCP стэка в linux-2.4 на SMP машинах (скажем на 4 процессорах)? Существенно ли он отстает от TCP стэка win2k на том же железе (и отстает ли)?
Что вообще можете сказать о протоколе TCP (не о стэке протоколов, а о самом TCP который поверх IP)- можно ли было сделать его чуть-чуть лучше или его можно считать очень близким к идеалу?
Что можете сказать про IPv6 - своевременности и достаточности для нужд (предполагаемые варианты ответов: /Все что нужно, в нем есть, но не все что есть, нужно/Немножко не хватает, можно было поддерживать еще что-то/был выбран кривой подход/другое :)/?
Большое спасибо за ответы!

А меня (сорри за вопрос) интересует, какой примерно гонорар можно получить за подобную (в смысле толковую, без воды, свежую в плане содержания, не очень короткую) статью от издателей таких сайтов примерно как builder.com.com - сам рассматриваю возможность приработка таковыми.. Алексей, не намекнете часом? Благодарен заранее.

> Вопрос: почему по опциям TCP стэк в линуксе не сделать так же как в BSD, т.е. за чем надо было SO_ACCEPTFILTER обзывать как
> TCP_DEFER_ACCEPT?

Потому что эту опцию я придумал. :-) Ой, вру, вообще-то я хотел сделать acceptx(), чтоб еще и несколко syscalls сэкономить, но доказать необходимость этого не смог. TCP_DEFER_ACCEPT используется TUXом, а acceptx() был бы полезен только apache, которому оптимизации такого рода помогают как мертвому
припарки.

Хотя если кото-то придумает другое разумное приложение SO_ACCEPTFILTER, нет проблем позаимствовать.


Alexey

> Вопрос: почему по опциям TCP стэк в линуксе не сделать так же как в BSD, т.е. за чем надо было SO_ACCEPTFILTER обзывать как > TCP_DEFER_ACCEPT?

Потому что эту опцию я придумал. :-) Ой, вру, вообще-то я хотел сделать acceptx(), чтоб еще и несколко syscalls сэкономить, но доказать необходимость этого не смог. TCP_DEFER_ACCEPT используется TUXом, а acceptx() был бы полезен только apache, которому оптимизации такого рода помогают как мертвому припарки.

Хотя если кото-то придумает другое разумное приложение SO_ACCEPTFILTER, нет проблем позаимствовать.

Alexey

2Alexey. А ограничение на 2Gb в sendfile() предполагается снять когда-нибудь? (Прочитал твою первую статью, попытался заюзать sendfile(), и обломился на файлах >2Gb :(.

2Alexey: Спасибо за ответ. Просто по статье сложилось впечатление, что это тоже самое что и во FreeBSD.
Ты не мог бы написать краткий обзор чем использование tcp в линуксе отличается от "стандартного"? Т.е. хотя бы краткий список функций и опций, особенно если это будет сопровождатся пояснениями как это делается в других системах.
Я думаю что за это builder.com вполне заплатит.

Есть так называемые BSD'измы. Это вовсе не "стандарт", как кто-то считает.
Это BSD'измы ;) В gcc даже есть опция -D_BSD_SOURCE, и он понимает, что от него хотят...

2anonymous (*) (2002-04-21 06:08:06.959): "В gcc даже есть опция -D_BSD_SOURCE, и он понимает, что от него хотят..."
Ну вообще-то даная конструкция всего лишь определяет что макрос _BSD_SOURCE определен и к самому компилятору это мало какое отношение имеет.

   Ты  не  мог  бы написать краткий обзор чем использование tcp в линуксе
   отличается  от  "стандартного"?  Т.е. хотя бы краткий список функций и
   опций,  особенно  если  это  будет  сопровождатся  пояснениями как это
   делается в других системах.
Идиот, может тебя еще и в попу трахнуть?
Линукс это юникс, все что описано в single unix specification, в нем есть,
плюс некоторые добавленные socket options которые делают fine-tuning
of TCP stack (плюс sendfile). Грубо говоря, если под какой-то юникс написано только
с семантикой и вызовами, описанными в single unix specification, то и на линуксе
будет работать без нареканий и багов.
 Такие тупые вопросы мог только ты задать, толком не работавший с линухом
даже как юзер.
NB: Я не Алексей Тормасов.

2anonymous (*) (2002-04-21 12:41:31.873): "NB: Я не Алексей Тормасов"
Оно и заметно.

> макрос _BSD_SOURCE определен и к самому компилятору это мало какое отношение имеет.

А слабо сделать grep BDS_SOURCE в исходниках gcc? Как сделаешь, доложи нам,
относится он к компилятору или нет.

2anonymous (*) (2002-04-22 02:21:16.716): "А слабо сделать grep BDS_SOURCE в исходниках gcc?"
А ты сам сделай по *исходникам* gcc. Просьба не путать с исходниками и h-Файлами от glibc.

Я сделал. Предлагаю повторить мой опыт. Инклюд-файлы glibc
лежат в /usr/unclude, к твоему сведению, а не в исходниках gcc.

2anonymous (*) (2002-04-22 06:43:03.442): "Я сделал. Предлагаю повторить мой опыт"
Очень сомневаюсь что ты понял, результат своего поиска.

> Что Вы можете сказать об оптимальности/быстродействии TCP стэка в linux-2.4 > на SMP машинах (скажем на 4 процессорах)? Существенно ли > он отстает от TCP стэка win2k на том же железе (и отстает ли)?

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

Однако, мы не поддерживаем некоторые важные вещи, зависящие от hardware, которые поддерживаются в win2k. Например, TCP LARGESEND (имеется в таких гигабитных адаптерах как intel e1000 и 3com tigon3, позволяет сделать существенную часть работы без участия cpu). Для недавно появившегося tigon3 мы это сделаем в 2.5, а вот насчет e1000... это зависит от степени дружелюбности intel.

> Что вообще можете сказать о протоколе TCP (не о стэке протоколов, а о самом TCP который поверх IP)- можно ли было сделать его > чуть-чуть лучше или его можно считать очень близким к идеалу?

Можно и не чуть-чуть. TCP непрерывно развивается. Например, SACKs стали реально использоваться совсем недавно.

Новые вещи, которые обещают быть полезными: ECN (explicit congestion notification), DSACK (duplicate SACK). Тот же LARGESEND тоже по сути расширение.

> Что можете сказать про IPv6 - своевременности и достаточности для нужд (предполагаемые варианты ответов: /Все что нужно, в нем есть, > но не все что есть, нужно/Немножко не хватает, можно было поддерживать еще что-то/был выбран кривой подход/другое :)/?

Ничего нового там нет.

Фактически, в процессе развития IPv6 "деградировал" в IPv4 c более длинным адресом. "Деградировал" стоит в кавычках, потому что IPv4 по сути не имеет _существенных_ недостатков. Все особенности, иногда рекламируемые как нечто присущее IPv6 (QoS, IPsec, Mobile etc), на самом деле были изобретены, впервые появились и уже давно используются в контексте IPv4.

С одной стороны IPv6 "cвоевременно", ясно ведь что на каждый умный пылесос IPv4 адрес не поставишь. С другой стороны --- уже поздно, публика настолько развращена NATом, что никакой IPv6 от такой вредной привычки уже не отучит. Если киты (то бишь cisco и microsoft) будут недостаточно тверды и позволят NATу дать метастазы в IPv6, его можно списать как абсолютно бесполезную игрушку. Надежда пока есть, см. f.e. http://news.com.com/2100-1033-885664.html

Хотя на практике IPv4+NAT работает прекрасно. Так что нужды в расширении адресного пространства и, соответственно, в IPv6 просто нет.

Alexey

Алексей, огромное спасибо за ответы - было очень интересно их получить!
Еще один вопрос - на сколько процентов TCP stack of linux-2.4 можно считать сделанным россиянами (или людьми со славянскими фамилиями - что будет больше :))? Критерии участия - 1) кол-во строк кода, 2) авторство идей реализации нетривиальных мест (особенно с новаторским подходом).
Большое спасибо за ответ заранее..