|
|
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Существуют ли простые способы для Subj или проще реализовать свой велосипед? По сути, от RMI мне нужно только создать соединение, вызвать 1-2 метода на ремоут хосте, получить ответ. Все методы работают a la REST, никакой сессии не имеют. Но желателен Subj. Т.е. потенциально иметь возможность: 1. Если какой-то сервер в момент вызова/коннекта не отвечает - переключится на резервный 2. Какая-то банальная балансировка нагрузки. Например один вызов на один сервер, следующий на второй, следующий обратно на первый. Погуглил в И-нет, балансировщики есть, но какие-то уж сильно Enterprise уровня (a la Weblogic). Мне такое не нужно. Пока делаю свой велосипед (вроде не сложно), но чувство, что велосипедостроение не есть хорошо - остается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:00 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, JBoss + Stateless Session Bean В принципе, и руками должно быть не сложно. Балансировщик - вообще любой удобный для вашей сети Резервирование - любой распределенный кэш ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:34 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Если все методы работают методы работают a la REST то надо было и создавать Rest. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:40 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
У меня кол-во вызовов достаточное большое/частое + сейчас много активных потоков плодится (>30-40). Как-то есть подозрение, что HTTP будет недостаточно быстро + большие накладные расходы. Сейчас многопотоковость вычислений реализовал (>30-40 потоков), даже задержки на RMI стали заметны, т.ч. например сейчас все java.io.Serialization меняю на java.io.Externalization. А при HTTP, подозреваю, вообще можно будет тушить свет ))). Про HTTP задумываюсь, но в одном месте он 100% не пролезет по скорости. Т.ч. от RMI не уйти. А мне кажется, мешать в одном проекте два транспортных протокола - то же не есть хорошо. В принципе, и руками должно быть не сложно. Ну да. Получается максимум пара десятков/сотен строк кода. Правда как его отлаживать - не очень понятно. Я опыта построения высоконагруженных систем не имею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:49 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
maytonЕсли все методы работают методы работают a la REST то надо было и создавать Rest. Ну у меня REST и есть, только не HTTP ))) Если читать Вики, https://ru.wikipedia.org/wiki/REST То нигде не сказано, что протокол ТРАНСПОРТНОГО уровня обязательно должен быть HTTP ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:51 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
BlazkowiczРезервирование - любой распределенный кэш А что общего между кешем и резервированием ? И еще вопрос по кэшам. Нужен кэш/прокси, но со специфическим поведением: 1. В кэш должен помещаться запрос ДО ОКОНЧАНИЯ его обработки. Т.к. высока вероятность (очень часто!), что придет несколько одинаковых запросов и, в этом случае, нужно понять что они одинаковые и выполнить только один. 2. Должна быть возможность гибко прописывать политику времени жизни объектов. Т.е. в зависимости от данных запроса, время его жизни в кэше может сильно отличаться. 3. Скорость работы критична Я смотрел на кеши, но наверное, нужно было смотреть на прокси (((. Не уверен, как прокси будут требованию N1 удовлетворять. Если подходящий прокси найдется - то тогда можно и от RPC попытаться уйти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 15:59 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevА что общего между кешем и резервированием ? В данном случае кэш выступает как просто хранилище для сессии. Но если взять Terracotta, то с ней, по-моему, вообще что угодно можно реплицировать. Любое состояние в твоей JVM. Leonid KudryavtsevИ еще вопрос по кэшам. Нужен кэш/прокси, но со специфическим поведением: 1. В кэш должен помещаться запрос ДО ОКОНЧАНИЯ его обработки. Т.к. высока вероятность (очень часто!), что придет несколько одинаковых запросов и, в этом случае, нужно понять что они одинаковые и выполнить только один. 2. Должна быть возможность гибко прописывать политику времени жизни объектов. Т.е. в зависимости от данных запроса, время его жизни в кэше может сильно отличаться. 3. Скорость работы критична EhCache + Terracotta. Но, надо, конечно, планировать в зависимости от того на сколько критично случайное выполнение одинаковых запросов, если они на разные узлы пошли. Если критично, то можно выделить один сервер под задачу унификации запросов, а само выполнение уже распределять. Leonid KudryavtsevЯ смотрел на кеши, но наверное, нужно было смотреть на прокси (((. Не уверен, как прокси будут требованию N1 удовлетворять. Если подходящий прокси найдется - то тогда можно и от RPC попытаться уйти. Не догоняю при чем тут прокси. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 16:12 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevТо нигде не сказано, что протокол ТРАНСПОРТНОГО уровня обязательно должен быть HTTP ))) Ого... ну может быть и не сказано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 16:22 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
BlazkowiczLeonid KudryavtsevИ еще вопрос по кэшам. Нужен кэш/прокси, но со специфическим поведением: 1. В кэш должен помещаться запрос ДО ОКОНЧАНИЯ его обработки. Т.к. высока вероятность (очень часто!), что придет несколько одинаковых запросов и, в этом случае, нужно понять что они одинаковые и выполнить только один. EhCache + Terracotta. По EhCache доку смотрел, но как сделать такое сделать - мне не очень понятно. Было желание его использовать, но у них все "наиболее вкусные фичи" в платной версии. BlazkowiczЕсли критично, то можно выделить один сервер под задачу унификации запросов, а само выполнение уже распределять. Критично. Сейчас даже сильно критично, т.к. последние оптимизации кода привела к тому, что ~ 70% будет похожих и будут приходить почти одновременно. Но задача "унификации запросов" уже автоматически несет за собой почти полное создание функционала кэша. Т.ч. получается, что если ее делать самому, то в общем и кэшь не нужен ))) Просто HashMap в котором запросы "унифицировали" сделать большего размера ))). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 17:22 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
И еще один вопрос: А кто чем пользуется для мониторинга серверов? 1. Что бы была достаточно тесная интеграция с Java / JVM: память, thread, RMI, какие-то свои метрики. 2. Сбор log'ов с серверов в одно централизованное место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 17:34 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, у тебя к каталоге /bin лежит JVisualVm. Запускай смотри. Поставь плагин для JMX, полезная штука. Поставь плагины для мониторинга CPU/Heap. И прочие. JMX - это аналог icmp для Java. Аналогичным функционалом обладает JBoss. Он показывает веб-морду для JMX. Давно лет 5 назад было также полезное веб-приложение PSIProbe. Щас поддерживается или нет - невкурсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 19:02 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Чтобы поднялся JMX-сетевой порт надо java запускать с ключиками. Иначе - только локальные процессы видны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 19:04 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, насчет сбора логов - сложный вопрос. И наверное не в тему Java. Я-бы стаскивал логи как-то по другому. Но у Log4j (старой версии 1.2.x) есть много альтернативных Appenders которе могут писать в syslog, Windows-syslog, jdbc-базу, многое другое. Причем код переписывать не нужно. Достаточно только конфигурирования базового конфига log4j. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 19:18 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
maytonLeonid Kudryavtsev, у тебя к каталоге /bin лежит JVisualVm. Запускай смотри. Поставь плагин для JMX, полезная штука. Поставь плагины для мониторинга CPU/Heap. И прочие. JMX - это аналог icmp для Java. От JVisualVM до адекватной системы мониторинга... как пешком до луны. IMHO Попытаюсь Zabbix поставить, посмотрю на него ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2016, 21:36 |
|
||
|
Java RMI. Балансировка нагрузки, резервирование
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, ты правильно вопрос формулируй. Zabbix - это вообще более общая штука. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 00:19 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39227767&tid=2124115]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
82ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 446ms |

| 0 / 0 |
