Производительность сокетов на Linux - PullRequest
5 голосов
/ 27 июля 2010

Исходя из моего последнего вопроса:

Проблема производительности при использовании потоков объектов Javas с сокетами

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

Существует ли какая-либо конфигурация ОС, которая позволяет сокету localhost работать так же быстро, как именованный канал?* Заранее спасибо!

Ответы [ 3 ]

2 голосов
/ 28 июля 2010

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

Да, и этого следовало ожидать.

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

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

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

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

1 голос
/ 27 июля 2010

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

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

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

1 голос
/ 27 июля 2010

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

Реализация сокетов UNIX для Java?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...