Наиболее эффективные - Эффективность - для обмена данными между JVM

У меня есть Java-приложение, которое требует связи между различными процессами. Процесс может работать в одной JVM или другой JVM, но работает на одном компьютере.

Мое приложение должно отправить «сообщения» другому процессу (такой же или другой JVM) и забыть об этом. похож на очередь обмена сообщениями, как IBM «MQ», но простую и использует только память, а не IO на жесткий диск для повышения производительности.

Я не уверен, что лучший подход от Performance prescriptive.

  • Интересно, эффективен ли RMI с точки зрения производительности, я думаю, что для этого требуются некоторые накладные расходы.
  • Что относительно сокета TCP/IP с использованием локального хоста?

любая другая мысль?

8
nl ja de
Могу ли я предложить вам протестировать два подхода в вашем конкретном случае, а затем сравнить результаты?
добавлено автор Stephan, источник
@Stephan: Это потребует значительного времени для реализации каждого метода и проверки его.
добавлено автор user836026, источник

2 ответы

Интересно, эффективен ли RMI с точки зрения производительности, я думаю, что для этого требуются некоторые накладные расходы.

RMI эффективен для того, что он делает. Это намного больше, чем нужно большинству людей, но обычно более чем достаточно быстро. Вы должны получать порядка 1-3 K сообщений в секунду с задержкой около 1 миллисекунды.

Как насчет сокета TCP/IP с использованием локального хоста?

Это всегда вариант, но с простой Java Serialization это будет не намного быстрее, чем использование RMI. Как вы делаете сериализацию и десериализацию, критически важно для высокой производительности.


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

По иронии судьбы, если вы хотите использовать диск, он может быть быстрее TCP или UDP (например, ZeroMQ), плюс вы получите постоянство «бесплатно».

Эта библиотека (я автор) может выполнять миллионы сообщений в секунду между процессами с задержкой до 100 наносекунды (350x ниже, чем ZeroMQ) https://github.com/peter-lawrey/Java-Chronicle Преимущества

  • сверхбыстрая сериализация и десериализация, то, что большинство транспортных тестов не включает в себя это, поскольку это часто занимает гораздо больше времени, чем транспортные расходы.
  • заключается в том, что вы можете отслеживать, что происходит между очередями в любое время после отправки сообщения.
  • воспроизвести все сообщения.
  • производитель может представлять собой любой объем данных перед вашим потребителем, чтобы грамотно обрабатывать микро-пакет до размера вашего дискового пространства. например потребитель может быть туберкулезом позади.
  • поддерживает репликацию по TCP.
  • перезапуск пользователя или производителя в значительной степени прозрачен.
16
добавлено
Спасибо #Peter за очень полезный ответ. Однако мне трудно понять, почему MQ, использующий персистенцию (запись на жесткий диск), как ваша, работает лучше, чем MM, как ZeroMQ.
добавлено автор user836026, источник
Спасибо ... больше вопросов, пожалуйста, я понимаю, что если я использую простой Java-сокет, я мог бы сделать сериализацию с помощью ObjectInputStream-ObjectOutputStream. если это так, почему все еще люди идут в Java RMI.
добавлено автор user836026, источник
ZeroMQ все еще использует системные вызовы, и это требует времени. esp, если вы добавите задержку по ядру, которая составляет около 10 - 30 микросекунд. Благодаря совместному использованию файла с отображением памяти между процессами сообщение может перейти от одного процесса к другому без системного вызова или с участием ядра. Для увеличения файла необходимо выполнить некоторые системные вызовы, но по умолчанию это 128 бит.
добавлено автор Peter Lawrey, источник
С RMI или RPC вы должны сделать вызов удаленного объекта. Это означает, что вы можете вызвать rmiObject.method (a, b, 125); , как если бы он был локальным для вас. Если вы передаете только объект, вам все равно придется решить, что с ним делать.
добавлено автор Peter Lawrey, источник

Если вы разрабатываете серверное приложение, попробуйте рассмотреть ZeroMQ. Он имеет отличную производительность, позволяет упростить межпроцессорную связь, позволяет создавать асинхронный API.

ZeroMQ declare fantastic performance with InterProcess communication. Even better than TCP sounds great. We are consider this solution for our clusterisation schema.

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

3
добавлено
pro.jvm
pro.jvm
3 503 участник(ов)

Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш сайт: projvm.com projvm.ru Наш канал: @proJVM Вакансии: @jvmjobs Конфы: @jvmconf

Java & Co
Java & Co
2 370 участник(ов)

Можно обсуждать с матом и без всё, что касается жабы, вплоть до холиваров. НЕ ИМЕЕТ ОТНОШЕНИЯ К САЙТУ JAVARUSH.RU ПРАВИЛА - https://t.me/javarush/75723 Вакансии сюда - https://telegram.me/joinchat/B7IzvUCnfo6d8t3yIxKguQ По вопросам - @thedude

learn.java
learn.java
1 888 участник(ов)

Чат для начинающих и не только Статистика: https://combot.org/chat/-1001083535868 Основной чат - @jvmchat

Java Underground
Java Underground
169 участник(ов)

https://vk.com/javatutorial

Javanese Questions
Javanese Questions
109 участник(ов)

Чат предназначен для обмена знаниями строго в формате в вопрос-ответ. Тема — Java, Kotlin и Android. Вопрос должен быть предварительно прогуглен, понятно и грамотно сформулирован, помечен хэштегами. Ответ — тем более. Куски кода размером в несколько строк можно писать прямо здесь, для больших кусков кода стоит использовать http://gist.github.com/, http://pastebin.com/, https://codeshare.io/ или любой аналогичный сервис. В некоторых случаях можно прикреплять скриншоты. Стикеры и гифки запрещены. Дополнять и уточнять вопросы и ответы — редактированием исходного сообщения. Обсуждения должны приводить к редактированию вопроса/ответа и удаляться. По хештегам можно искать существующие вопросы и овтеты: #вопрос #ответ #git #generics #java #server #awt #javafx #swing #kotlin #anko #tornadofx #ktor #android #recyclerView #performance #arch #network #permissions #storage #async