Здравствуйте, 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 показывал максимальный
вес — улучшение в производительности заметно сразу.

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