Снижение задержки в сети при передаче приложений большого объема в интрасети - PullRequest
4 голосов
/ 28 марта 2011

У нас есть набор серверных приложений, которые получают данные измерений от оборудования / инструментов.Время передачи сообщений в настоящее время является нашим главным узким местом, поэтому мы заинтересованы в его сокращении для улучшения процесса.Связь между инструментами и серверными приложениями осуществляется через сокеты TCP / IP, созданные с помощью C ++ в Redhat Linux.

Можно ли сократить время передачи сообщений с помощью аппаратного обеспечения, изменив параметры конфигурации TCP / IP или настроив функции ядра tcp?(мы можем пожертвовать безопасностью ради скорости, так как связь находится в защищенной внутренней сети)

Ответы [ 5 ]

5 голосов
/ 28 марта 2011

В зависимости от рабочей нагрузки отключение Алгоритма Nagle для сокетного соединения может очень помочь.

При работе с большими объемами небольших сообщений я обнаружил, что это имеет огромное значение.

По памяти я считаю, что опция сокета для C ++ называлась TCP_NODELAY

2 голосов
/ 29 марта 2011

Как предложил @Jerry Coffin, вы можете переключиться на UDP . UDP является ненадежным протоколом, это означает, что вы можете потерять свои пакеты, или они могут прийти в неправильном порядке, или дублироваться. Таким образом, вы должны обрабатывать эти случаи на уровне приложения. Поскольку вы можете потерять некоторые данные (как вы указали в своем комментарии), нет необходимости в повторной передаче (самая сложная часть любого надежного протокола). Вам просто нужно отбросить устаревшие пакеты. Используйте простую порядковую нумерацию, и все готово.

Да, вы можете использовать RTP (он имеет порядковую нумерацию), но вам это не нужно. RTP выглядит излишним для вашего простого случая. Он имеет много других функций и используется в основном для потоковой передачи мультимедиа.

[РЕДАКТИРОВАТЬ] и аналогичный вопрос здесь

1 голос
/ 28 марта 2011

С аппаратной стороны попробуйте Серверные сетевые платы Intel и убедитесь, что Механизм разгрузки TCP (ToE) включен.

Также необходимо принять важное решение.между задержкой и goodput , если вы хотите увеличить задержку за счет goodput, рассмотрите возможность сокращения периода объединения прерываний.Обратитесь к документации Intel для получения более подробной информации, поскольку они предлагают множество настраиваемых параметров.

0 голосов
/ 28 марта 2011

Да.

Google "Размер кадра TCP" для деталей.

0 голосов
/ 28 марта 2011

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

...