Насколько быстрым может быть RMI?

Question

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

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

Я думаю, мой настоящий вопрос таков: существуют ли какие-либо варианты взаимодействия между приложениями в Java, которые проходят через что-то БОЛЕЕ БЫСТРОЕ, чем TCP / IP? Я имею в виду вещи, уже реализованные в Java, а не возможности JNI, которые мне нужно было бы реализовать :)

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

Answer 1

Есть ли какие-либо варианты взаимодействия между приложениями на Java, которые проходят через что-то БЫСТРЕЕ, чем TCP/IP?

Не существенно...НАСКОЛЬКО МНЕ ИЗВЕСТНО.

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

Чтобы добиться большей пропускной способности, необходимо сосредоточиться на следующем:

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

Глупо ли думать, что 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 работали локально.