Как быстро может быть RMI? - PullRequest
4 голосов
/ 15 января 2010

Я видел вопрос: Связь между двумя отдельными настольными приложениями Java (ответ: JGroups), и я думаю о реализации чего-либо с помощью JavaGroups или прямого RMI, но скорость важна. Я не отсылаю большие объемы данных (содержимое MIDI-сообщений, поэтому по 3 байта каждое, не более двух сообщений каждые три миллисекунды), и все это будет на одной машине. Не глупо ли думать, что RMI / JGroups на одной физической машине будут работать медленно?

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

Полагаю, мой настоящий вопрос таков: есть ли какие-либо варианты взаимодействия interpp в Java, которые проходят через нечто более быстрое, чем TCP / IP? Я имею в виду вещи, уже реализованные в Java, а не возможности JNI, которые я нужно реализовать:)

Я знаю, не оптимизировать рано и все такое, но и лучше, чем потом сожалеть.

Ответы [ 4 ]

5 голосов
/ 15 января 2010

Существуют ли какие-либо варианты взаимодействия на языке interpp в Java, которые проходят через нечто более быстрое, чем TCP / IP?

Не значительно ... AFAIK.

Но я думаю, что вы думаете об этом неправильно. Предполагая, что вы перемещаете небольшие сообщения, основной причиной снижения производительности будут накладные расходы, а не скорость, с которой перемещаются байты. Эти накладные расходы включают такие вещи, как время, необходимое для выполнения системных вызовов, для переключения контекстов процесса на стороне клиента и сервера, для обработки заголовков пакетов сообщений в ядре и для маршрутизации пакетов. И любое синхронное RPC-подобное взаимодействие влечет за собой вызов, ожидающий ответа; то есть приложение -> сервер -> время прохождения в оба конца.

Способ повышения пропускной способности заключается в следующем:

  • сокращение количества RPC, необходимых для приложения; например объединяя их, чтобы они были более крупнозернистыми, и

  • поиск путей превращения синхронных взаимодействий в асинхронные взаимодействия; например использование технологий, основанных на сообщениях, а не RPC.

2 голосов
/ 16 января 2010

Если скорость имеет важное значение, вы должны сделать звонок в той же теме. Вы не сможете так быстро использовать сеть.

Однако, предполагая, что скорость не так важна, вы можете выполнять вызовы Java RMI за 500 микросекунд, а с помощью пользовательского кодированного RPC вы можете совершать вызовы по обратной связи примерно за 24 микросекунды. Даже передача данных между потоками в одной JVM может занять 8 микросекунд.

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

Примечание: я говорю здесь микросекунды, а не миллисекунды. Я бы проигнорировал любые варианты, которые занимают несколько миллисекунд для ваших целей.

1 голос
/ 15 января 2010

Этому тесту уже около двух лет, но он показывает, что единственное популярное решение для удаленного взаимодействия Java, более быстрое, чем RMI, - это Hessian 2 (которое, я считаю, все еще находится в бета-версии).

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

0 голосов
/ 17 июля 2018

Глупо ли думать, что RMI / JGroups на одной физической машине будут работать медленно?

Если ваша машина приличная, вероятно, да :) Если вы работаете на машине с множеством процессов, потребляющих процессор и т. Д., То все может быть иначе. Как всегда, лучший способ узнать, испытали ли вы то же, что и я, - это проверить.

Ниже указано время в миллисекундах, использованное с помощью nanoTime в той же JVM. послать строку «123» с помощью rmi и на сервере согласовать ее с «abc», чтобы получить «123abc» и верните его.

Холодная JVM: примерно 0,25 миллисекунды с задержкой

0.250344
0.262695
0.241540
0.282461
0.301057
0.307938
0.282102

Теплая JVM: задержка около 0,07 миллисекунды.

0.87916
0.72474
0.73399
0.64692
0.62488
0.59958
0.59814
0.66389

Таким образом, вы будете в порядке в течение 1 миллисекунды, если RMI-сервер и клиент работают локально.

...