Доброе утро!

Есть серверное приложение (сервер) и клиентское стресс приложение (стресс).
Если запускать сервер и стресс на одном компьютере через loopback 127.0.0.1, то чтобы перенапрячь сервер (чтобы он отклонился от 0 в загрузке ЦП) необходимо запустить 10 (десять) копий стресса.
Если запускать на разных компьютерах через Ethernet, то одной копии стресса достаточно. Загрузка (количество UDP пакетов в секунду) пропорциональна количеству копий стресса.
На компьютере, где работает сервер, стоит какой-то чип REALTEK встроенный в материнскую плату. Каковы прогнозы, если поставить серверную сетевую плату, например, эту?

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

Заранее благодарю за советы, да и просто мысли вслух.
Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Есть серверное приложение (сервер) и клиентское стресс приложение (стресс).
ЛБ>Если запускать сервер и стресс на одном компьютере через loopback 127.0.0.1, то чтобы перенапрячь сервер (чтобы он отклонился от 0 в загрузке ЦП) необходимо запустить 10 (десять) копий стресса.
ЛБ>Если запускать на разных компьютерах через Ethernet, то одной копии стресса достаточно. Загрузка (количество UDP пакетов в секунду) пропорциональна количеству копий стресса.
ЛБ>На компьютере, где работает сервер, стоит какой-то чип REALTEK встроенный в материнскую плату. Каковы прогнозы, если поставить серверную сетевую плату, например, эту?

А какое количество этих самых пакетов в секунду у одного стресс-клиента и какой процессор на сервере?
То, на чём экономится в случае loopback и не экономится на простейших адаптерах — это offloading подсчётов контрольных сумм и деления TCP сегмента на IP пакеты (для UDP, понятно, неприменимо). Да, установка такой карточки решит эту проблему, но мне кажется, что это перебор; даже среди Intel можно найти адекватные модели с поддержкой нужных характеристик за 30, а не 90 долларов. В верхнем сегменте сетевух идут уже варианты с умением удалённого управления (IPMI и аналоги), оффлоадингом IPSec шифрования, и прочие особые навороты.

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

ЛБ>То есть меня несколько озадачила разница в 1000% (тысяча процентов). Я написал сервер на блокирующих сокетах с тем, чтобы когда все выше сокетов отлажу перейти на асинхронные с портами завершения и пулом потоков. Получается все это чушь собачья и основные потери на уровне сетевого адаптера, драйверов и стека протоколов ниже IP.

Мне вот тоже кажется, что сама по себе передача через реальный сетевой канал не даст такого эффекта. Работает что-то ещё.
Например, может быть неоптимальный шедулинг. В случае loopback данные оказываются в приёмном сокете ещё до выхода из send() в передающем сокете. В случае удалённой сети между ними заметная задержка. Может, что-то делается в это время, из чего сложно переключиться.
Да хоть вымывание процессорных кэшей...

Здравствуйте, netch80, Вы писали:

N>А какое количество этих самых пакетов в секунду у одного стресс-клиента и какой процессор на сервере?

Одна копия стресса генерирует 600 — 800 коротеньких UDP пакетов в секунду. Точнее сказать сейчас не могу. Но это хорошая оценка и снизу, и сверху.
Процессор Intel Core i5-2400, 4 ядра, 3,1 GHz.

N>Да, установка такой карточки решит эту проблему, но мне кажется, что это перебор; даже среди Intel можно найти адекватные модели с поддержкой нужных характеристик за 30, а не 90 долларов. В верхнем сегменте сетевух идут уже варианты с умением удалённого управления (IPMI и аналоги), оффлоадингом IPSec шифрования, и прочие особые навороты.

N>Кстати, если эта ссылка у них верна, то модель разработки 2005-го года за 90 вечнозелёных может вполне соответствовать современной в треть этой цены

Вот их прайс на карты Intel. Все что дешевле этой вместо магического слова Server имеет слово Desktop. Я буду рад реальной ссылке на что-либо лучше и при этом дешевле этого.

ЛБ>>То есть меня несколько озадачила разница в 1000% (тысяча процентов). Я написал сервер на блокирующих сокетах с тем, чтобы когда все выше сокетов отлажу перейти на асинхронные с портами завершения и пулом потоков. Получается все это чушь собачья и основные потери на уровне сетевого адаптера, драйверов и стека протоколов ниже IP.

N>Мне вот тоже кажется, что сама по себе передача через реальный сетевой канал не даст такого эффекта. Работает что-то ещё.
N>Например, может быть неоптимальный шедулинг. В случае loopback данные оказываются в приёмном сокете ещё до выхода из send() в передающем сокете. В случае удалённой сети между ними заметная задержка. Может, что-то делается в это время, из чего сложно переключиться.
N>Да хоть вымывание процессорных кэшей...

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

Лазар

ЛБ>То есть меня несколько озадачила разница в 1000% (тысяча процентов). Я написал сервер на блокирующих сокетах с тем, чтобы когда все выше сокетов отлажу перейти на асинхронные с портами завершения и пулом потоков. Получается все это чушь собачья и основные потери на уровне сетевого адаптера, драйверов и стека протоколов ниже IP.

Какой объем трафика и количество IP пакетов при этом генерируется? Больше похоже на ошибки в программе (вроде лишнего активного wait)
Если код тестов не секретен, может, выложите его?

Здравствуйте, SkyDance, Вы писали:

ЛБ>>То есть меня несколько озадачила разница в 1000% (тысяча процентов). Я написал сервер на блокирующих сокетах с тем, чтобы когда все выше сокетов отлажу перейти на асинхронные с портами завершения и пулом потоков. Получается все это чушь собачья и основные потери на уровне сетевого адаптера, драйверов и стека протоколов ниже IP.

SD>Какой объем трафика и количество IP пакетов при этом генерируется?

На этот вопрос я уже ответил в соседней ветке.

SD>Больше похоже на ошибки в программе (вроде лишнего активного wait)

А почему с loopback не проявляется?

SD>Если код тестов не секретен, может, выложите его?

На самом деле не хотелось бы.
К тому же это файл в 2000 строк далеко не самого красивого кода.
Я как раз сейчас занимаюсь его переписыванием, но после этого нагрузка на сервер упадет где-то вдвое и это уже будет другой case.

Да, виноват, в этом форуме надо было указать платформу. Это — Windows.
Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Здравствуйте, netch80, Вы писали:

N>>А какое количество этих самых пакетов в секунду у одного стресс-клиента и какой процессор на сервере?

ЛБ>Одна копия стресса генерирует 600 — 800 коротеньких UDP пакетов в секунду. Точнее сказать сейчас не могу. Но это хорошая оценка и снизу, и сверху.

На самом деле я все send написал нагло по три раза, чтобы сделать вид, что повторяю из-за утери UDP пакета, и чтобы сервер умел отфильтровывать повторы.
Так что вышеуказанное надо умножить на троечку.

Лазар

1) Какая ОС?
2) Есть ли антивирус/фаервол?

Здравствуйте, Аноним, Вы писали:

А>1) Какая ОС?

На этот вопрос уже ответил — Windows

А>2) Есть ли антивирус/фаервол?

От первого у меня аллергия — никогда не ставил. Но есть Microsoft Security Essentials. Вызывает сомнения, что они туда влезли.
Второе включено, соответствующий порт открыт. Но неужели Firewall может посадить производительность в 10 раз? Вряд ли, хотя эту версию надо будет проверить.

Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Второе включено, соответствующий порт открыт. Но неужели Firewall может посадить производительность в 10 раз? Вряд ли, хотя эту версию надо будет проверить.

Отключить брандмауэр Windows (не рекомендуется) — даже страшно немножко стало!
Нет, использование процессора пляшет 5% — 10%. С брандмауэром было столько же.
Я, правда, после отключения брандмауэра Windows не перезагружал.

Лазар

ЛБ>Отключить брандмауэр Windows (не рекомендуется) — даже страшно немножко стало!
ЛБ>Нет, использование процессора пляшет 5% — 10%. С брандмауэром было столько же.
ЛБ>Я, правда, после отключения брандмауэра Windows не перезагружал.

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

PS: если вам будут говорить про VTune — набейте в лицо
PPSS: если вам будут говорить про CodeAnalyst — набейте в по вашему выбору

Здравствуйте, Аноним, Вы писали:

Прошу прощения за задержку, сгонял в Москву за сетевой платой. Нет, не самолетом из Тбилиси.

А>Вообще, есть один общепринятый метод решения подобных проблем: профилирование.
А>Для винды есть два стиля кунг-фу: простой и правильный
А>Простой: находим утилиту kernrate, настраиваем правильно символы и смотрим, кто жрет процессор
А>Правильный: учимся работать с XPerf логами. Знающие люди делают с ним чудеса, но с ним надо немного преодолеть порог вхождения, если допустимо так выразится в приличном обществе.

Наверно, все-таки придется и это делать. Я думал обойтись малой кровью.

А>PS: если вам будут говорить про VTune — набейте в лицо
А>PPSS: если вам будут говорить про CodeAnalyst — набейте в по вашему выбору

Учту,
Сергей

ЛБ>Наверно, все-таки придется и это делать. Я думал обойтись малой кровью.

kernrate — это совсем маленькая кровь, делов на 5 мин. Бывает, сразу видно кто виноват.

ЛБ>Учту,
ЛБ>Сергей

Я не Сергей

Здравствуйте, Аноним, Вы писали:

ЛБ>>Наверно, все-таки придется и это делать. Я думал обойтись малой кровью.

А>kernrate — это совсем маленькая кровь, делов на 5 мин. Бывает, сразу видно кто виноват.

ЛБ>>Учту,
ЛБ>>Сергей

А>Я не Сергей

Это я иногда забываюсь и подписываюсь своим именем!

ЛБ>>>Учту,
ЛБ>>>Сергей
А>>Я не Сергей
ЛБ>Это я иногда забываюсь и подписываюсь своим именем!
А фамилия — Кузнецов?

Здравствуйте, Аноним, Вы писали:

ЛБ>>>>Учту,
ЛБ>>>>Сергей
А>>>Я не Сергей
ЛБ>>Это я иногда забываюсь и подписываюсь своим именем!
А>А фамилия — Кузнецов?
Нет, Хэйлунцзян

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>А почему с loopback не проявляется?

Общение по loopback (или по портам одного и того же собственного IP) выполняется путём простого перекладывания данных из передающего буфера в приёмный без спуска до сетевой карты и её драйверов. Само собой, это быстрее (memcpy против переключения между ядром и юзермодом).

Попробуйте вставить дополнительную сетевую карту, соединить её со встроенной картой кросоверным кабелем (стандартный "прямой" обжим может не прокатить, в зависимости от конкретных чипов), назначить обоих сетевухам разные IP и гонять трафик между ними.

Ещё один вопрос: что за сетевое оборудование применяется между источником и целевым узлом? Надо понимать, что DLink/Netgear/etc за $50 — хороший раутер для дома, но выжать на нём даже устойчивую "сотку" по сути нереально, даже если заявлена поддержка гигабита. Настоящие полноскоростные железки стоят совсем другие деньги

Здравствуйте, Mr.Delphist, Вы писали:

MD>Попробуйте вставить дополнительную сетевую карту, соединить её со встроенной картой кросоверным кабелем (стандартный "прямой" обжим может не прокатить, в зависимости от конкретных чипов), назначить обоих сетевухам разные IP и гонять трафик между ними.

А реально сработает?
В случае всех известных мне Unix без дополнительного NAT на границах интерфейсов или специального policy routing не получится, потому что стек, увидев адрес получателя из собственного набора, сразу завернёт пакет через loopback, и 127.0.0.1 для этого не требуется.

MD>Ещё один вопрос: что за сетевое оборудование применяется между источником и целевым узлом? Надо понимать, что DLink/Netgear/etc за $50 — хороший раутер для дома, но выжать на нём даже устойчивую "сотку" по сути нереально, даже если заявлена поддержка гигабита. Настоящие полноскоростные железки стоят совсем другие деньги

Ну сотку-то они сейчас и выдерживают. Но вообще да, вопрос поставлен правильно — для тестов надо убрать свитч, даже если работают две реально разные железки на концах.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>>А почему с loopback не проявляется?

MD>Общение по loopback (или по портам одного и того же собственного IP) выполняется путём простого перекладывания данных из передающего буфера в приёмный без спуска до сетевой карты и её драйверов. Само собой, это быстрее (memcpy против переключения между ядром и юзермодом).

Ну это-то понятно. Но не в 10 же раз!
Просто мне предлагали проверить синхронизацию и я подумал, что проблемы синхронизации проявились бы и с loopback.

MD>Попробуйте вставить дополнительную сетевую карту, соединить её со встроенной картой кросоверным кабелем (стандартный "прямой" обжим может не прокатить, в зависимости от конкретных чипов), назначить обоих сетевухам разные IP и гонять трафик между ними.

Было время когда я и так работал и кросс где-то должен валяться. Дополнительная сетевая карта теперь есть — серверная (деньги выбросил — улучшение микроскопическое).
Найду кросс попробую погонять и так.

MD>Ещё один вопрос: что за сетевое оборудование применяется между источником и целевым узлом? Надо понимать, что DLink/Netgear/etc за $50 — хороший раутер для дома, но выжать на нём даже устойчивую "сотку" по сути нереально, даже если заявлена поддержка гигабита. Настоящие полноскоростные железки стоят совсем другие деньги

Ну в моем тесте оценка снизу 600 UDP * 3 повтора * 40 байт в одном UDP = 72Kb. Почти мегабод. А еще сервер отвечает (правда не на каждый повтор). А еще заголовки UDP, IP, ETHERNET.
А еще сейчас я с третьего (netbook, wi-fi) стресс гоняю (правда в 10 раз медленнее). Выходит в моем тесте D-Link на Ethernet по крайней мере 2 мегабода держит.

Но проблема то не на D-Link, напрягается-то сервер. К тому же сейчас выяснилось, что когда на компьютере, где бегает стресс, открываешь RSDN в IE, то картина загрузки на сервере изменяется драматически. Теперь видно, что у меня в программе тоже где-то глюк есть . Все-таки серверное приложение не должно изменять свой стиль поведения в зависимости от того, что делается на соседнем компьютере. К D-Link тоже появились вопросы (я думал там нормальный switch).

Но мой основной вопрос все-таки в силе. Какое улучшение дает переход на асинхронные сокеты? Не станет ли это просто потерей времени?
А так всем большое спасибо за внимание к проблеме.

Лазар

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Попробуйте вставить дополнительную сетевую карту, соединить её со встроенной картой кросоверным кабелем (стандартный "прямой" обжим может не прокатить, в зависимости от конкретных чипов), назначить обоих сетевухам разные IP и гонять трафик между ними.

N>А реально сработает?
N>В случае всех известных мне Unix без дополнительного NAT на границах интерфейсов или специального policy routing не получится, потому что стек, увидев адрес получателя из собственного набора, сразу завернёт пакет через loopback, и 127.0.0.1 для этого не требуется.

На Windows (либо NT, либо 2000, точно не помню) у меня есть опыт такой работы и (на двух разных картах) все бегало по кабелю.
На UNIX я не работал, но лет десять назад говорил с Евгением Гагиным, разработчиком IOLA. Их ADSL сервер был Linux компьютером с набором многопортовых плат. Он утверждал, что если работа идет между портами на разных платах, то они делают маршрутизацию после полного прихода IP пакета, если между двумя портами на одной плате, то начинают перегонять на выход еще до полного прихода на входе. Но даже в этом случае, как я понял, Linux опускала все к ним в драйвер.

MD>>Ещё один вопрос: что за сетевое оборудование применяется между источником и целевым узлом? Надо понимать, что DLink/Netgear/etc за $50 — хороший раутер для дома, но выжать на нём даже устойчивую "сотку" по сути нереально, даже если заявлена поддержка гигабита. Настоящие полноскоростные железки стоят совсем другие деньги

N>Ну сотку-то они сейчас и выдерживают. Но вообще да, вопрос поставлен правильно — для тестов надо убрать свитч, даже если работают две реально разные железки на концах.

Да без switch с кроссом на двух компьютеров тоже можно.

Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Здравствуйте, netch80, Вы писали:

ЛБ>Их ADSL сервер был Linux компьютером с набором многопортовых плат. Он утверждал, что если работа идет между портами на разных платах, то они делают маршрутизацию после полного прихода IP пакета, если между двумя портами на одной плате, то начинают перегонять на выход еще до полного прихода на входе. Но даже в этом случае, как я понял, Linux опускала все к ним в драйвер.

Что-то тут я сморозил. У них другой случай и, наверно, просто из драйвера в user mode даже не поднималось.

Лазар

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Попробуйте вставить дополнительную сетевую карту, соединить её со встроенной картой кросоверным кабелем (стандартный "прямой" обжим может не прокатить, в зависимости от конкретных чипов), назначить обоих сетевухам разные IP и гонять трафик между ними.

N>А реально сработает?
N>В случае всех известных мне Unix без дополнительного NAT на границах интерфейсов или специального policy routing не получится, потому что стек, увидев адрес получателя из собственного набора, сразу завернёт пакет через loopback, и 127.0.0.1 для этого не требуется.

На винде (как минимум обычной десктопной) — сработает, трафик начинает светиться в WireShark. Но для этого надо, чтобы не просто две сетевухи было, а чтобы между ними был физический маршрут "через провод". Как раз кроссоверный патч-корд является простейшим случаем такой связности. Если патч-корд вынуть, то работать всё будет, но опять как loopback-адреса (без спуска до уровня сетевых карт).

Кстати, ещё один ньюанс, который полезно держать в уме, это модель соглашений о ресолве трафика хоста: Strong and Weak Host Models

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>>А почему с loopback не проявляется?

MD>Общение по loopback (или по портам одного и того же собственного IP) выполняется путём простого перекладывания данных из передающего буфера в приёмный без спуска до сетевой карты и её драйверов. Само собой, это быстрее (memcpy против переключения между ядром и юзермодом).

тем не менее, memcpy этот случится в ядре. Соответственно, все прелести в виде переключений в режим ядра будут присутствовать. Более того, на винде даже для локального трафика происходит некая обработка на уровне tcpip драйвера ( транспортный уровень он как минимум проходит ). Естественно, трафик не доходит до уровня сетевого оборудования, но там как раз и нет никаких особых расходов — инициализация DMA и tasks offload ( по сути, пара записей в регистры сетевой карты ). Короче говоря, я бы вижу никаких оснований, чтобы нагрузка на процессор была ниже для случая loopbak vs hardware. Более того, возможно что при работе через hardware даже ниже будет нагрузка, так как есть теоретическая возможность вообще избежать даже memcpy. Другое дело — что loopback должен иметь большую пропускную способность и меньшую latency.

Лазар Бешкенадзе писал:

ЛБ>То есть меня несколько озадачила разница в 1000% (тысяча процентов).

Большое спасибо анонимному помощнику за совет применить xperf.

Вот наконец-то руки дошли и до этого.
Порог вхождения не так уж и высок, читал документацию и практиковался меньше рабочего
дня, все результаты получены уже на следующий день. Какого же было мое изумление когда
xperf не показал особой загрузки CPU в области, где Task Manager показывал зашкаливание!
Более того, по странному стечению обстоятельств, именно в этой области xperf показал
наименьшую загрузку процессора. Изучение информации на сайте MSDN и в блогах Microsoft
показало, что на то, что изображает Task Manager можно наплевать, в определенных условиях
Task Manager может показывать высокую загрузку там, где ее нет.
Я начал повышать нагрузку на сервер не до каких-либо показаний чего-либо, а до первых
необслуженных запросов. Разница между loopback и реальной сетью — 20%. Это даже меньше
того, на что я рассчитывал.
Более того я попробовал оптимизировать одно из мест, где xperf показывал максимальный
вес — улучшение в производительности заметно сразу.

Пардон всем за то, что потревожил зря.
Лазар