производительность Разъем на линукс

Исходя из моего последнего вопроса:производительность Разъем на линукс

Performance issue using Javas Object streams with Sockets

Я смотрю на производительность сокетов на Linux. В приведенном выше примере я получаю время в оба конца ~ 65 μ сек. Если я сделаю два фикса в файловой системе, это уменьшится до ~ 45 μ сек. Дополнительное время, использующее сокеты localhost, должно быть связано с тем, что я нахожусь в сетевом стеке.

Есть ли какая-то конфигурация ОС, которая может сделать локальный хост так быстро, как именованный канал?

uname -a 
Linux fiatpap1d 2.4.21-63.ELhugemem #1 SMP Wed Oct 28 23:12:58 EDT 2009 i686 athlon i386 GNU/Linux

Заранее благодарен!

источник

2010-07-27 Jonathan

Вы используете ядро на основе 2.4? Это часть проблемы. –

Да, я также все еще использую проигрыватель;) Знаете ли вы, что если более поздняя версия ядра будет оптимизировать сетевой трафик по-другому? – Jonathan

Возможно, нет, не могли бы вы объяснить, почему использование именованных каналов не подходит? Вы пытались использовать UDP вместо TCP? (DatagramSocket) – Ivan

Я не могу помочь вам на фронте Java, но вы можете взглянуть на сокеты домена UNIX. Вот вопрос с обсуждения о том, как использовать их в Java:

UNIX socket implementation for Java?

источник

2010-07-27 16:05:15

Да, я мог бы использовать что-то на основе jni. Я бы предпочел не делать этого, если это вообще возможно. Я надеялся, что некоторые более поздние версии Linux сделают эту оптимизацию для меня. – Jonathan

Ваши предыдущие вопросы делают два ложных предположения:

ICMP_ECHO (а.к.а. звона) дает значимую информацию синхронизации. Это, в частности, не может быть (и должно быть) уровнем ICMP с низким приоритетом обслуживания.
Это маршалинг данных через промежуточные интерфейсы Java не является узким местом. Потому что это.

Ваши методы тестирования очень подозрительны. Что вы пытаетесь достичь?

источник

2010-07-27 16:15:29 msw

Ад да. Отличный ответ. Прокляните эти бесчисленные интерфейсы Java и их стоимость исполнения. –

На 1. ping дает мне ~ то же время, что и мой тест, используя именованные каналы. 2. Как вы пришли к такому выводу? – Jonathan

С приведенным выше примером я получаю время в оба конца ~ 65 мкс. Если я сделаю два фикса в файловой системе, это уменьшится до ~ 45 мкс. Дополнительное время, использующее сокеты localhost, должно быть связано с тем, что я нахожусь в сетевом стеке.

Да, и этого можно ожидать.

FIFO - довольно примитивный метод общения. Их состояние по существу является переменной bool. Чтения и записи проходят через один и тот же предварительно выделенный буфер фиксированного размера. Таким образом, ОС может и оптимизирует операции.

Розетки более сложные. У них есть полноценный конечный автомат TCP. Буферизация динамическая и двунаправленная (recv, send буферируются отдельно). Это означает, что когда вы пишете что-то в локальном сокете, вы почти всегда имеете какое-то управление динамической памятью. Linux пытается избежать этого как можно больше: трюки с нулевой копией/однократной копией реализуются повсеместно. Тем не менее, очевидно, что, поскольку звонки должны проходить через дополнительный код, они будут медленнее.

В конце концов, учитывая, насколько больше сокетов сравнивается с FIFO, разница 20us откровенно - это утверждение о том, насколько хороша производительность сокета Linux.

P.S. 65us rtt = ~ 35us в одном направлении. 1s/35us = ~ 30K пакетов в секунду. Для сетевого кода без оптимизации, используя одно соединение, которое звучит правильно.

источник

2010-07-28 11:22:26 Dummy00001

производительность Разъем на линукс

ответ

Смежные вопросы