Добрый всем день

У меня работает приложение на одном выделенном сервере: Jboss7, Java, struts2 (очень, говорят, похож на struts mvc), hibernate. Отдаленно встал вопрос о расширении серверной мощности для обслуживания большего количества пользователей. Расширение видимо имеет смысл производить горизонтально, потому что в вертикальном расширении быстро наступит предел.

Насколько я понимаю, presentation layer (struts2) и data access layer (hibernate) — это как раз те две части приложения, которые возможно придётся дорабатывать.
Вопросы к вам, коллеги:

1) насколько проблематично такое расширение с точки зрения доработки кода? достаточно ли будет просто настроить кластерную конфигурацию в jboss или чаще всего приходится дорабатывать код?

2) на какие тонкие места в коде стоит обратить внимание?
как я понимаю struts2 объекты всегда создаются под запрос, поэтому в struts2 коде проблем быть не должно?
как насчет hibernate? могут ли конфликтовать экземпляры кода на разных серверах, особенно если включен кеш (сейчас не включен, но хотели разобраться как включать) ?

3) хотелось бы настроить динамическую архитектуру, где дополнительные сервера подключаются по мере загрузки работающих. Реально ли это сделать в J2EE приложении? Реально ли это сделать без Amazon EC2, а на своей (арендованной, конечно же) инфраструктуре выделенных серверов?

Спасибо!

Здравствуйте, ligett, Вы писали:

L>Добрый всем день

L>У меня работает приложение на одном выделенном сервере: Jboss7, Java, struts2 (очень, говорят, похож на struts mvc), hibernate. Отдаленно встал вопрос о расширении серверной мощности для обслуживания большего количества пользователей. Расширение видимо имеет смысл производить горизонтально, потому что в вертикальном расширении быстро наступит предел.

Поставте перед серваками апач (или что-то похожее) со sticky sessions. Если у пользователей только свои данные, то будет скалиться без проблем.
На Jboss-овскую кластеризацию лучше забить.

Здравствуйте, StanislavK, Вы писали:

SK>На Jboss-овскую кластеризацию лучше забить.
Почему?

Здравствуйте, ligett, Вы писали:

L>struts2 (очень, говорят, похож на struts mvc)
На Spring MVC? По-моему не очень. Но задачи решает те же.

L>Насколько я понимаю, presentation layer (struts2) и data access layer (hibernate) — это как раз те две части приложения, которые возможно придётся дорабатывать.
Да, и так работать должно.
Web: HttpSession убедится что сериализуется нормально. Проверить что там лишнего ничего не валяется. Свести размер оной к минимуму.
Persistence: имеет смысл включить репликацию кеша. Для этого стоит настроить хибер на использовать JBoss Cache, причем тот каторый уже есть в контейнере, а не как самостоятельный API.
JBoss и Hiber — друзья на веки, мануала на эту тему должно быть масса.

L>1) насколько проблематично такое расширение с точки зрения доработки кода? достаточно ли будет просто настроить кластерную конфигурацию в jboss или чаще всего приходится дорабатывать код?
Зависит от того как всё реализовано. Если код кривой, в HttpSession хранится что попало. Либо юзер другими средставми привязан к серверу, то будет сложнее реализовать failover.
Если всё пучком и сделано осторожно, то обычной конфигурацией должно всё решится.

L>как я понимаю struts2 объекты всегда создаются под запрос, поэтому в struts2 коде проблем быть не должно?
Да, всё кроме HttpSession, на которую стоит отдельно обратить внимание.

L>как насчет hibernate? могут ли конфликтовать экземпляры кода на разных серверах, особенно если включен кеш (сейчас не включен, но хотели разобраться как включать)?
Конфликтовать? Не думаю.

L>3) хотелось бы настроить динамическую архитектуру, где дополнительные сервера подключаются по мере загрузки работающих. Реально ли это сделать в J2EE приложении? Реально ли это сделать без Amazon EC2, а на своей (арендованной, конечно же) инфраструктуре выделенных серверов?
JBoss это умеет. Там реализован механизм обнаружение нод в сети. Помню старых версиях, кластеризация была включена по-умолчанию. Все девелоперские компы объединялись в кластер и пугали переодически девелоперов, когда тест одного человека, вдруг, запускался на другом компе.
Раньше у JBoss была проблема с репликацией на все ноды. Но сейчас, вроде, это решили. Умеет только одну запасную ноду держать.

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, ligett, Вы писали:

L>>Добрый всем день

L>>У меня работает приложение на одном выделенном сервере: Jboss7, Java, struts2 (очень, говорят, похож на struts mvc), hibernate. Отдаленно встал вопрос о расширении серверной мощности для обслуживания большего количества пользователей. Расширение видимо имеет смысл производить горизонтально, потому что в вертикальном расширении быстро наступит предел.

SK>Поставте перед серваками апач (или что-то похожее) со sticky sessions. Если у пользователей только свои данные, то будет скалиться без проблем.
SK>На Jboss-овскую кластеризацию лучше забить.

Спасибо! посмотрю на стики сешшонс.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, StanislavK, Вы писали:

SK>>На Jboss-овскую кластеризацию лучше забить.
B>Почему?
А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, ligett, Вы писали:

L>>struts2 (очень, говорят, похож на struts mvc)
B>На Spring MVC? По-моему не очень. Но задачи решает те же.

Слышал что архитектурно похожи, в том плане что объекты создаются по запросу от клиента. Впрочем, не уверен.


L>>Насколько я понимаю, presentation layer (struts2) и data access layer (hibernate) — это как раз те две части приложения, которые возможно придётся дорабатывать.
B>Да, и так работать должно.
B>Web: HttpSession убедится что сериализуется нормально. Проверить что там лишнего ничего не валяется. Свести размер оной к минимуму.
B>Persistence: имеет смысл включить репликацию кеша. Для этого стоит настроить хибер на использовать JBoss Cache, причем тот каторый уже есть в контейнере, а не как самостоятельный API.
B>JBoss и Hiber — друзья на веки, мануала на эту тему должно быть масса.

спасибо, буду изучать.

L>>1) насколько проблематично такое расширение с точки зрения доработки кода? достаточно ли будет просто настроить кластерную конфигурацию в jboss или чаще всего приходится дорабатывать код?
B>Зависит от того как всё реализовано. Если код кривой, в HttpSession хранится что попало. Либо юзер другими средставми привязан к серверу, то будет сложнее реализовать failover.
B>Если всё пучком и сделано осторожно, то обычной конфигурацией должно всё решится.

L>>как я понимаю struts2 объекты всегда создаются под запрос, поэтому в struts2 коде проблем быть не должно?
B>Да, всё кроме HttpSession, на которую стоит отдельно обратить внимание.

Спасибо, тоже буду изучать. Кстати как-то так получилось, что HttpSession вообще никак не использовали в коде, так что надеюсь что проблемы с ним не будет.

L>>как насчет hibernate? могут ли конфликтовать экземпляры кода на разных серверах, особенно если включен кеш (сейчас не включен, но хотели разобраться как включать)?
B>Конфликтовать? Не думаю.

L>>3) хотелось бы настроить динамическую архитектуру, где дополнительные сервера подключаются по мере загрузки работающих. Реально ли это сделать в J2EE приложении? Реально ли это сделать без Amazon EC2, а на своей (арендованной, конечно же) инфраструктуре выделенных серверов?
B>JBoss это умеет. Там реализован механизм обнаружение нод в сети. Помню старых версиях, кластеризация была включена по-умолчанию. Все девелоперские компы объединялись в кластер и пугали переодически девелоперов, когда тест одного человека, вдруг, запускался на другом компе.
B>Раньше у JBoss была проблема с репликацией на все ноды. Но сейчас, вроде, это решили. Умеет только одну запасную ноду держать.

Blazkowicz, спасибо большое за подробный ответ!

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, ligett, Вы писали:

L>>Насколько я понимаю, presentation layer (struts2) и data access layer (hibernate) — это как раз те две части приложения, которые возможно придётся дорабатывать.
B>Да, и так работать должно.
B>Web: HttpSession убедится что сериализуется нормально. Проверить что там лишнего ничего не валяется. Свести размер оной к минимуму.
B>Persistence: имеет смысл включить репликацию кеша. Для этого стоит настроить хибер на использовать JBoss Cache, причем тот каторый уже есть в контейнере, а не как самостоятельный API.
B>JBoss и Hiber — друзья на веки, мануала на эту тему должно быть масса.
А вот этого не надо. Репликация, в данном случае (как, впрочем в большинстве случаев, кроме резервирования) — зло. Можно просто включить кеширование на каждой ноде в отдельности. В большинстве web приложений больше и не надо, т.к. данные не пересекаются.

L>>1) насколько проблематично такое расширение с точки зрения доработки кода? достаточно ли будет просто настроить кластерную конфигурацию в jboss или чаще всего приходится дорабатывать код?
B>Зависит от того как всё реализовано. Если код кривой, в HttpSession хранится что попало. Либо юзер другими средставми привязан к серверу, то будет сложнее реализовать failover.
B>Если всё пучком и сделано осторожно, то обычной конфигурацией должно всё решится.
И сессию тоже не надо реплицировать. Sticky session решит все проблемы.

Здравствуйте, StanislavK, Вы писали:

SK>А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже.
JBoss, вроде лучшее что есть в opensource. И в случае чего, всегда можно подебажить и допилить до желаемого. В чем проблема-то?

Здравствуйте, StanislavK, Вы писали:

SK>А зачем?
А ещё затем что у автора темы вообще опыт в данной области нулевой и пилить кластеризацию руками с нуля, ИМХО, будет ошибочным решением, пока нет достаточно широкого понимания всех процессов.

Здравствуйте, StanislavK, Вы писали:

SK>А вот этого не надо. Репликация, в данном случае (как, впрочем в большинстве случаев, кроме резервирования) — зло. Можно просто включить кеширование на каждой ноде в отдельности. В большинстве web приложений больше и не надо, т.к. данные не пересекаются.
Угу, только в процессе failover это будет выглядеть так.
Нода упала, все клиенты пошли на резервную. Кеш пуст. И давай все вместе запросами базу нагибать.

SK>И сессию тоже не надо реплицировать. Sticky session решит все проблемы.
Какие ещё проблемы оно решит? Это просто способ распределения нагрузки.

Здравствуйте, ligett, Вы писали:

L>Спасибо, тоже буду изучать. Кстати как-то так получилось, что HttpSession вообще никак не использовали в коде, так что надеюсь что проблемы с ним не будет.
Напрямую не использовали, или вообще Session Scope в Struts 2 нигде не упоминается у вас? Состояние всё в базе хранится? И нет кеша второго уровня...
А аутентификация как реализована?
Если у вас всё на столько круто, что вся сессия живет на клиенте и в базе, тогда и репликацию можно будет свести к минимуму.

Здравствуйте, Blazkowicz, Вы писали:

SK>>А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже.
B>JBoss, вроде лучшее что есть в opensource. И в случае чего, всегда можно подебажить и допилить до желаемого. В чем проблема-то?
Почему лучшее? Как определить критерий лучшего? Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.

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

Здравствуйте, Blazkowicz, Вы писали:

SK>>А зачем?
B>А ещё затем что у автора темы вообще опыт в данной области нулевой и пилить кластеризацию руками с нуля, ИМХО, будет ошибочным решением, пока нет достаточно широкого понимания всех процессов.

Я не предлагал пилить с нуля, я предлагал не использовать jboss для решения проблемы. см: http://rsdn.ru/forum/java/5189334.1

Автор: StanislavK
Дата: 03.06.13

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, ligett, Вы писали:

L>>Спасибо, тоже буду изучать. Кстати как-то так получилось, что HttpSession вообще никак не использовали в коде, так что надеюсь что проблемы с ним не будет.
B>Напрямую не использовали, или вообще Session Scope в Struts 2 нигде не упоминается у вас? Состояние всё в базе хранится? И нет кеша второго уровня...
B>А аутентификация как реализована?
B>Если у вас всё на столько круто, что вся сессия живет на клиенте и в базе, тогда и репликацию можно будет свести к минимуму.

Честно говоря, люди, писавшие систему, включая меня, далеко не специалисты. Писали сами по наитию, и по гуглу, и может чего-то неправильно писали. Но!
Сейчас HttpSession вообще никак не используется. Аутентификация и авторизация сделаны через Spring Security.
К сессии ничего не прикрепляется, SessionAware акшоны не используются. Всё хранится в базе, ну и идентификаторы объектов в формах на клиенте, конечно.
Кеш тоже пока никакой не использовали, вместо этого просто взяли по-быстрее железо. Просто потому что боимся получить проблемы, которые обычно сложно исследовать, нужен опыт и знания в этой области.
Опять же, может что-то неправильно сделали, но пока так

Здравствуйте, StanislavK, Вы писали:

SK>Почему лучшее? Как определить критерий лучшего?
А просто альтернатив нет. Основные opensource JEE реализации —
Glassfish — исходники без слёз смотреть нельзя
Geronimo — самое глючное вообще. Даже Glassfish уделывает.
JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?

SK>Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.
Субъекнивно. Если понимать как оно работает и настраивается, то думаю там не на столько всё плохо.
Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.

SK>Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией.
Одним словом — failover не нужен?

Здравствуйте, Blazkowicz, Вы писали:

B>JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?
Да потому, что нафиг он не нужен. Там нет ничего, что не подлючается отдельно. Начем нужно все сразу и еще через место навязанное jboss-ом.

SK>>Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.
B>Субъекнивно. Если понимать как оно работает и настраивается, то думаю там не на столько всё плохо.
B>Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.
Хорошо сказанно. Продуманный, конечно никогда не лушче

SK>>Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией.
B>Одним словом — failover не нужен?
Смотря где и для чего. Для большинства Web приложений failover в виде релогина 1%-20% (в зависимости от числа нод) пользователей ваще не проблема.

Здравствуйте, ligett, Вы писали:

L>Сейчас HttpSession вообще никак не используется. Аутентификация и авторизация сделаны через Spring Security.
Откуда уверенность что Spring Security в сессии ничего не хранит? Просто вычитайте все атрибуты сессии после обработки запроса и посмотрите что там.

L>К сессии ничего не прикрепляется, SessionAware акшоны не используются. Всё хранится в базе, ну и идентификаторы объектов в формах на клиенте, конечно.
Ну, если так. То хорошо. Можно тогда максимально всё из сессии вынести в формы.

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

Здравствуйте, Blazkowicz, Вы писали:

SK>>А вот этого не надо. Репликация, в данном случае (как, впрочем в большинстве случаев, кроме резервирования) — зло. Можно просто включить кеширование на каждой ноде в отдельности. В большинстве web приложений больше и не надо, т.к. данные не пересекаются.
B>Угу, только в процессе failover это будет выглядеть так.
B>Нода упала, все клиенты пошли на резервную. Кеш пуст. И давай все вместе запросами базу нагибать.
Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить.
Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.

SK>>И сессию тоже не надо реплицировать. Sticky session решит все проблемы.
B>Какие ещё проблемы оно решит? Это просто способ распределения нагрузки.
Да вы что? А мы тут как о scalability и говорим, нет?

Здравствуйте, StanislavK, Вы писали:

SK>Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить.
SK>Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.
Если не использовать кеш, то да, всё может очень быстро упереться в базу.

SK>Да вы что? А мы тут как о scalability и говорим, нет?
Распределение нагрузки не решает всех проблем масштабирования.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, ligett, Вы писали:

L>>Сейчас HttpSession вообще никак не используется. Аутентификация и авторизация сделаны через Spring Security.
B>Откуда уверенность что Spring Security в сессии ничего не хранит? Просто вычитайте все атрибуты сессии после обработки запроса и посмотрите что там.

Такой уверенности нет ) но хотя бы можно предположить что Spring Security должен уметь жить в кластерной конфигурации.


L>>К сессии ничего не прикрепляется, SessionAware акшоны не используются. Всё хранится в базе, ну и идентификаторы объектов в формах на клиенте, конечно.
B>Ну, если так. То хорошо. Можно тогда максимально всё из сессии вынести в формы.

L>>Кеш тоже пока никакой не использовали, вместо этого просто взяли по-быстрее железо.
B>А говорите достигли предела вертикального масштабирования. Кеш может увеличить производительность просто на порядок.

Да, тоже будем изучать. Опять же, тут проблема знаний и опыта, которых немного.
Кстати, может быть подскажите какие-то тулы для определения узких мест производительности в java-приложениях? например вопрос номер 1 у меня, это где задержка дольше всего — в передаче данных клиент-jboss, классы бизнес-логики, классы доступа к данным или сама база данных. Какой-то может быть есть end-to-end профайлер?

Здравствуйте, ligett, Вы писали:

L>Кстати, может быть подскажите какие-то тулы для определения узких мест производительности в java-приложениях? например вопрос номер 1 у меня, это где задержка дольше всего — в передаче данных клиент-jboss, классы бизнес-логики, классы доступа к данным или сама база данных. Какой-то может быть есть end-to-end профайлер?
Если всё написано более-менее разумно без откровенных перегибов, то
Сообщение клиент(браузер)-сервер, естественно, самого продолжительное. Клиент физически расположен далеко от сервера и время тут может идти на секунды.
Но, оно и ресурсов, обычно, много не отнимает (за исключением некоторых атак с долгими запросами). Поэтому к производительности сервера отношения не имеет.
Второе узкое место это работа с базой. Во-первых база и сервер это разные процессы даже на одной машине. А если говорить о кластере, то Java и БД даже физически на разных машинах.
Поэтому SQL запросы отнимают массу времени, и это легко лечится толстым кешированием со стороны Java.
Тулзы — JMeter, любой профайлер (JVisualVM), профайлер SQL запросов (специфичный для каждой базы). Ну, и отдельныо со стороны браузера, например, Firebug .

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, StanislavK, Вы писали:

SK>>Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить.
SK>>Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.
B>Если не использовать кеш, то да, всё может очень быстро упереться в базу.
А я и не говорил, что не надо использовать. Можно пользоваться просто локальным. Не надо его реплицировать.
Кстати, пользователей можно тоже шардить по нодам (уверен апач и это может), тогда репликация становится абсолютно бесполезной.

SK>>Да вы что? А мы тут как о scalability и говорим, нет?
B>Распределение нагрузки не решает всех проблем масштабирования.
Не, не так. Распределение нагрузки решает абсолютно все проблемы маштабирования. Задача же разработчика распределить нагрузку так, чтобы позникало как можно меньше новых проблем, которые надо решать.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, ligett, Вы писали:

B>Сообщение клиент(браузер)-сервер, естественно, самого продолжительное. Клиент физически расположен далеко от сервера и время тут может идти на секунды.

еще раз спасибо за помощь, Blazkowicz!

Здравствуйте, StanislavK, Вы писали:

SK>>>Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить.
SK>>>Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.
B>>Если не использовать кеш, то да, всё может очень быстро упереться в базу.
SK>А я и не говорил, что не надо использовать. Можно пользоваться просто локальным. Не надо его реплицировать.
SK>Кстати, пользователей можно тоже шардить по нодам (уверен апач и это может), тогда репликация становится абсолютно бесполезной.

А как быть с когерентностью кеша если его не реплицировать?

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, StanislavK, Вы писали:

SK>>А я и не говорил, что не надо использовать. Можно пользоваться просто локальным. Не надо его реплицировать.
SK>>Кстати, пользователей можно тоже шардить по нодам (уверен апач и это может), тогда репликация становится абсолютно бесполезной.
GIV>А как быть с когерентностью кеша если его не реплицировать?

Скорее всего — ничего, так как чаще всего нечему быть "когерентным" в том смысле который поддерживает репликация. Репликация — это уже когда других вариантов не осталось. Но чаще всего другие вариантны в изобилии. Например, в веб приложениях очень большая вероятноть, что данные просто не шарятся. Если они все же шарятся, то не редактируются одновременно, так, что какой-нить ленивый таймаут на протухание этих данных вполне работает и достаточно разгружает базу. Если же шаренные данные редактируются, то тогда, возможно, подойдет optimistic-locking. Ну и оставшиеся варианты да, репликация со всеми радостями в виде локов, траффика, конфигурации и ограничений по маштабированию (исходя из предыдущих "радостей"). Ну и если такая штука все же заварилась, то стоит присмотреться на то, чтобы перейти на какую-нить "не совсем реляционную" базу, которая "нормально" горизонтально скалися и вопрос репликации просто отпадет.

B>>JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?
SK>Да потому, что нафиг он не нужен. Там нет ничего, что не подлючается отдельно. Начем нужно все сразу и еще через место навязанное jboss-ом.

ахахаха, Linux from scratch ?


SK>>>Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.
B>>Субъекнивно. Если понимать как оно работает и настраивается, то думаю там не на столько всё плохо.
B>>Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.
SK>Хорошо сказанно. Продуманный, конечно никогда не лушче

гнилой товарищ, а гнилой товарищ если убрать гнилость в башке ), то application server будет рассматриваться просто как сборка тулзов, которая не более гнила, чем сумма тулзов её составляющих.


SK>>>Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией.
B>>Одним словом — failover не нужен?
SK>Смотря где и для чего. Для большинства Web приложений failover в виде релогина 1%-20% (в зависимости от числа нод) пользователей ваще не проблема.

для большинства веб приложений по фиг, что использовать репликацию или sticky session, т.к. нагруженность больше веб приложений небольшая.

On 04.06.2013 15:25, Аноним 348 wrote:
> B>>JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям
> двигается в правильном направлении. Распределенный кеш у них хороший.
> Так почему бы и нет?
> SK>Да потому, что нафиг он не нужен. Там нет ничего, что не подлючается
> отдельно. Начем нужно все сразу и еще через место навязанное jboss-ом.
>
> ахахаха, Linux from scratch ?

Грубовато, но по сути — верно.

--
WBR,
Serge.

Здравствуйте, StanislavK, Вы писали:

SK>>>А я и не говорил, что не надо использовать. Можно пользоваться просто локальным. Не надо его реплицировать.
SK>>>Кстати, пользователей можно тоже шардить по нодам (уверен апач и это может), тогда репликация становится абсолютно бесполезной.
GIV>>А как быть с когерентностью кеша если его не реплицировать?

SK>Скорее всего — ничего, так как чаще всего нечему быть "когерентным" в том смысле который поддерживает репликация. Репликация — это уже когда других вариантов не осталось. Но чаще всего другие вариантны в изобилии. Например, в веб приложениях очень большая вероятноть, что данные просто не шарятся. Если они все же шарятся, то не редактируются одновременно, так, что какой-нить ленивый таймаут на протухание этих данных вполне работает и достаточно разгружает базу.
То есть получается не "Не надо его реплицировать" а "Можно не реплицировать если ..."

SK> Если же шаренные данные редактируются, то тогда, возможно, подойдет optimistic-locking. Ну и оставшиеся варианты да, репликация со всеми радостями в виде локов, траффика, конфигурации и ограничений по маштабированию (исходя из предыдущих "радостей").
Ага, так вот и живем.

Здравствуйте, Аноним, Вы писали:

B>>>JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?
SK>>Да потому, что нафиг он не нужен. Там нет ничего, что не подлючается отдельно. Начем нужно все сразу и еще через место навязанное jboss-ом.
А>ахахаха, Linux from scratch ?
Не, все много проще. Проблемы с таким сборками в том, что запустить легко, но шаг в право или лево — и все равно надо лезть в детали, читать доки, так, что не понятно, что они там упрощают.

B>>>Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.
SK>>Хорошо сказанно. Продуманный, конечно никогда не лушче
А>гнилой товарищ, а гнилой товарищ если убрать гнилость в башке ), то application server будет рассматриваться просто как сборка тулзов, которая не более гнила, чем сумма тулзов её составляющих.
В том и дело, что не нужна эта сборка. Больше половины никто не использует. А те редкие, кто используют уже начинают копаться и плеваться, так как завязанн на те библиотеки, которые влючены в комплект, так как логгирование сделало странным местом, и т.д.

B>>>Одним словом — failover не нужен?
SK>>Смотря где и для чего. Для большинства Web приложений failover в виде релогина 1%-20% (в зависимости от числа нод) пользователей ваще не проблема.
А>для большинства веб приложений по фиг, что использовать репликацию или sticky session, т.к. нагруженность больше веб приложений небольшая.
Ну таким и репликация не нужна.

Здравствуйте, GarryIV, Вы писали:

GIV>То есть получается не "Не надо его реплицировать" а "Можно не реплицировать если ..."
Получается, что "реплицировать, если больше уже ну совсем никак".