2016-12-10 6 views
0

Я перерабатываю часть инфраструктуры существующего приложения, которое отправляет пакеты данных UDP на адреса 1 ... N (часто многоадресной рассылки). В настоящее время существуют, скажем, объекты передатчика T, а в некоторых случаях все передатчики отправляются на тот же адрес.Эффективность отправки пакетов UDP по тому же адресу

Чтобы упростить и предоставить примерный пример, скажем, что есть 3 объекта передатчика, и все они должны быть отправлены на один конкретный адрес. Мой вопрос ... эффективнее ?:

Вариант 1) Поместите мьютекс вокруг одного разъема и включите все передатчики (T) в один и тот же разъем.

T----\ 
T----->Socket 
T----/ 

Вариант 2) Используйте три отдельных разъема, все отправляются в одно и то же место.

T----->Socket 1 
T----->Socket 2 
T----->Socket 3 

Я подозреваю, что со вторым вариантом, под капотом, ОСЫ или NIC помещает мьютекс вокруг окончательной передачи так в большой картине, Вариант 2, вероятно, не много отличается от варианта 1.

На следующей неделе я, вероятно, настрою эксперимент на своем компьютере разработки, но я не могу проверить все потенциальные конфигурации компьютеров, которые могут быть установлены пользователями. Я также понимаю, что существуют разные реализации - Windows vs Linux, разные производители наборов микросхем NIC и т. Д., Но мне интересно, может ли кто-нибудь иметь какой-то прошлый опыт или архитектурные знания, которые могли бы пролить свет на преимущество одного варианта над другим.

Спасибо!

+1

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

ответ

0

После запуска некоторых тестов на компьютере под управлением Windows 10 у меня есть «ответ», который по крайней мере дает мне приблизительное представление о том, чего ожидать. Я не могу быть на 100% уверен, что каждая система будет вести себя одинаково, но большинство серверов, на которых я запускаю, используют Intel NIC и Windows 10, а мои типичные размеры пакетов составляют около 1200 байт, поэтому ответ, по крайней мере, делает меня удобным, это правильно для моего конкретного сценария. Я решил опубликовать результаты здесь, если это может помочь кому-либо еще воспользоваться экспериментом.

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

Это схема тестирования я использовал:

  • 2,700,000 пакетов в 1200 байт каждый.
  • Режим выпуска, 64 бит.
  • i7-3930K CPU, адаптер Intel Gigabit CT PCIE.

А вот результаты

  • 1 Передатчик: SharedSocket = 28,2650 сек: 1 розетка = 28,2073 сек.
  • 3 Передатчики: SharedSocket = 28.4485 с: MultipleSockets = 27.5190 сек.
  • 6 Передатчики: SharedSocket = 28.7414 с: MultipleSockets = 27.3485 сек.
  • 12 Передатчики: SharedSocket = 27.9463 с: MulitpleSockets = 27,3479 сек.

Как и ожидалось, испытание только с одной нитью имело почти одинаковое время для обоих. Тем не менее, в случае с 3, 6 и 12 передатчиками, увеличение на 3% лучше, если использовать один сокет на поток вместо совместного использования. Это не большая разница, но если вы пытаетесь выжать каждую последнюю унцию из своей системы, это может быть полезной статистикой. Мое особое приложение предназначено для передачи большого количества видео.

Как раз как проверка работоспособности .... вот скриншот сетевой страницы TaskManager на стороне сервера. Вы можете увидеть увеличение пропускной способности примерно на полпути через тест, что совпадает с переключением на второй тест с несколькими гнездами. Я включил скринкап клиентского компьютера (это был ящик Windows 7).

Screenshot