Многоадресная рассылка - PullRequest
       27

Многоадресная рассылка

5 голосов
/ 18 сентября 2009

Недавно мы завершили анализ производительности многоадресной отправки. К счастью, Java и C работали почти одинаково, поскольку мы тестировали разные скорости отправки трафика в Windows и Solaris.

Однако мы заметили, что время отправки многоадресного сообщения увеличивается с увеличением времени между отправками. Чем чаще мы вызываем отправку, тем меньше времени требуется для завершения отправки.

Приложение позволяет нам контролировать количество времени, которое мы ожидаем между вызовами отправки, ниже вы видите, как время увеличивается с увеличением задержки между пакетами. При отправке 1000 пакетов в секунду (время ожидания 1 мс) для отправки вызова требуется всего 13 микросекунд. При 1 пакете в секунду (время ожидания 1000 мс) это время увеличивается до 20 микросекунд.

Wait time (ms)                      us to send
0                                   8.67   
1                                   12.97  
10                                  13.06  
100                                 18.03  
1000                                20.82
10000                               57.20  

Мы видим это явление как на Java, так и на C, а также в Windows и Solaris. Мы проводим тестирование на сервере Dell 1950 с двухпортовой сетевой картой Intel Pro 1000. Микро-бенчмаркинг сложен, особенно в Java, но мы не думаем, что это связано с JITing или GC.

Java-код и командная строка, которые я использую для тестов, находятся по адресу: http://www.moneyandsoftware.com/2009/09/18/multicast-send-performance/

Ответы [ 4 ]

3 голосов
/ 06 февраля 2010

Это может быть артефактом объединения прерываний с NIC на этом конкретном хосте, посмотрите эту статью на 29 West на эту тему, они показывают, как задержка может увеличиться до 125 мкс на NIC e1000,

http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html

2 голосов
/ 18 сентября 2009

Некоторые теории:

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

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

Альтернативная причина - утечка памяти или некоторое снижение производительности в вашем приложении / тесте / платформе. Это также (если оно существует) означает, что чем дольше вы ждете, тем дольше у него будет время ухудшать производительность и, следовательно, дольше будет отправляться.

ТАКЖЕ - если вы тратите больше времени между пакетами для их отправки - вы можете превысить тайм-ауты изучения адреса - как таблицы IP, так и таблицы MAC. Если срок действия этих таблиц / кэшей истек, им нужно будет заново их переучить, прежде чем пересылать пакет.

Удачи!

1 голос
/ 06 февраля 2010

Как вы ждете между отправками? Вы пробовали заняты ожиданием, чтобы не отказываться от процессора?

1 голос
/ 18 сентября 2009

Код для выполнения этих задач кэшируется ближе к ЦП (возможно, даже в регистрах), когда только что произошел вызов.

...