В чем разница в производительности между вызовом метода JVM и удаленным вызовом? - PullRequest
Новая
       37

В чем разница в производительности между вызовом метода JVM и удаленным вызовом?

5 голосов
/ 24 сентября 2011

Я собираю некоторые данные о разнице в производительности между вызовом метода JVM и удаленным вызовом метода с использованием двоичного протокола (другими словами, не SOAP). Я разрабатываю платформу, в которой вызов метода может быть локальным или удаленным по усмотрению каркаса, и мне интересно, в какой момент «стоит» оценить метод удаленно, либо на гораздо более быстром сервере, либо вычислить сетку какой-то. Я знаю, что удаленный вызов будет намного, намного медленнее, поэтому я в основном заинтересован в понимании разницы в порядке величины. Это в 10 раз медленнее, или в 100, или в 1000? У кого-нибудь есть данные по этому поводу? При необходимости я напишу свои собственные тесты, но надеюсь снова использовать имеющиеся знания. Спасибо!

Ответы [ 3 ]

3 голосов
/ 24 сентября 2011

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

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

Ваша точка безубыточности связана с тем, насколько ценным является совместное использование функциональности, а не скорости вызова метода.

3 голосов
/ 24 сентября 2011

Разработав RMI с низкой задержкой (~ 20 мксек мин), он все еще в 1000 раз медленнее, чем прямой вызов.Если вы используете обычный Java RMI (~ 500 микросекунд в минуту), он может быть в 25 000 раз медленнее.

ПРИМЕЧАНИЕ. Это только очень приблизительная оценка, чтобы дать вам общее представление о разнице, которую вы можете увидеть.Есть много сложных факторов, которые могут кардинально изменить эти цифры.В зависимости от того, что делает метод, разница может быть намного ниже, особенно если вы выполняете RMI для того же процесса, если сеть относительно медленная, разница может быть намного больше.

Кроме того, даже при наличииочень большая относительная разница, возможно, это не будет иметь большого значения для всего вашего приложения.

Чтобы уточнить мой последний комментарий ...

Допустим, у вас естьGUI, который должен опрашивать некоторые данные каждую секунду, и для этого используется фоновый поток.Допустим, использование RMI занимает 50 мс, а альтернатива - прямой вызов метода для локальной копии распределенного кэша - 0,0005 мс.Казалось бы, огромная разница в 100 000 раз.Тем не менее, вызов RMI может начаться на 50 мс раньше, все равно опрашивать каждую секунду, разница для пользователя практически отсутствует.

Что может быть гораздо важнее, когда RMI по сравнению с использованием другого подхода намного проще (если это правильный инструмент для работы)

Альтернативой использованию RMI является использование JMS.Что лучше, зависит от вашей ситуации.

3 голосов
/ 24 сентября 2011

Невозможно точно ответить на ваш вопрос. Соотношение времени выполнения зависит от таких факторов, как:

  • Размер / сложность параметров и возвращаемых значений, которые необходимо сериализовать для удаленного вызова.
  • Время выполнения самого метода
  • Пропускная способность / задержка сетевого подключения

Но в целом прямые вызовы методов JVM очень быстрые, любой тип сериализации в сочетании с задержкой в ​​сети, вызванной RMI, может привести к значительным накладным расходам. Посмотрите на эти цифры, чтобы получить приблизительную оценку накладных расходов:

http://surana.wordpress.com/2009/01/01/numbers-everyone-should-know/

Кроме того, вам нужно будет тестировать.

Один совет - убедитесь, что вы используете действительно хорошую пару библиотек двоичных сериализаций (avro, буфер протокола, крио и т. Д.) С приличной коммуникационной инфраструктурой (например, Netty). Эти инструменты намного лучше, чем стандартные средства сериализации / ввода-вывода Java, и, вероятно, лучше, чем все, что вы можете написать самостоятельно за разумное время.

...