У меня работает приложение на одном выделенном сервере: 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-овскую кластеризацию лучше забить.
Re[2]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, 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 была проблема с репликацией на все ноды. Но сейчас, вроде, это решили. Умеет только одну запасную ноду держать.
Re[2]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, ligett, Вы писали:
L>>Добрый всем день
L>>У меня работает приложение на одном выделенном сервере: Jboss7, Java, struts2 (очень, говорят, похож на struts mvc), hibernate. Отдаленно встал вопрос о расширении серверной мощности для обслуживания большего количества пользователей. Расширение видимо имеет смысл производить горизонтально, потому что в вертикальном расширении быстро наступит предел.
SK>Поставте перед серваками апач (или что-то похожее) со sticky sessions. Если у пользователей только свои данные, то будет скалиться без проблем. SK>На Jboss-овскую кластеризацию лучше забить.
Спасибо! посмотрю на стики сешшонс.
Re[3]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, StanislavK, Вы писали:
SK>>На Jboss-овскую кластеризацию лучше забить. B>Почему?
А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже.
Re[2]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, 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, спасибо большое за подробный ответ!
Re[2]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, 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 решит все проблемы.
Re[4]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже.
JBoss, вроде лучшее что есть в opensource. И в случае чего, всегда можно подебажить и допилить до желаемого. В чем проблема-то?
Re[4]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>А зачем?
А ещё затем что у автора темы вообще опыт в данной области нулевой и пилить кластеризацию руками с нуля, ИМХО, будет ошибочным решением, пока нет достаточно широкого понимания всех процессов.
Re[3]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>А вот этого не надо. Репликация, в данном случае (как, впрочем в большинстве случаев, кроме резервирования) — зло. Можно просто включить кеширование на каждой ноде в отдельности. В большинстве web приложений больше и не надо, т.к. данные не пересекаются.
Угу, только в процессе failover это будет выглядеть так.
Нода упала, все клиенты пошли на резервную. Кеш пуст. И давай все вместе запросами базу нагибать.
SK>И сессию тоже не надо реплицировать. Sticky session решит все проблемы.
Какие ещё проблемы оно решит? Это просто способ распределения нагрузки.
Re[3]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, ligett, Вы писали:
L>Спасибо, тоже буду изучать. Кстати как-то так получилось, что HttpSession вообще никак не использовали в коде, так что надеюсь что проблемы с ним не будет.
Напрямую не использовали, или вообще Session Scope в Struts 2 нигде не упоминается у вас? Состояние всё в базе хранится? И нет кеша второго уровня...
А аутентификация как реализована?
Если у вас всё на столько круто, что вся сессия живет на клиенте и в базе, тогда и репликацию можно будет свести к минимуму.
Re[5]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, Blazkowicz, Вы писали:
SK>>А зачем? Сколько раз бравые парни, всесто того, что бы сделать все просто и быстро, делали все модно и медленно. Все эти аппликейшин сервера — от лукавого и их тулы тоже. B>JBoss, вроде лучшее что есть в opensource. И в случае чего, всегда можно подебажить и допилить до желаемого. В чем проблема-то?
Почему лучшее? Как определить критерий лучшего? Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.
Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией.
Re[5]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, Blazkowicz, Вы писали:
SK>>А зачем? B>А ещё затем что у автора темы вообще опыт в данной области нулевой и пилить кластеризацию руками с нуля, ИМХО, будет ошибочным решением, пока нет достаточно широкого понимания всех процессов.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, ligett, Вы писали:
L>>Спасибо, тоже буду изучать. Кстати как-то так получилось, что HttpSession вообще никак не использовали в коде, так что надеюсь что проблемы с ним не будет. B>Напрямую не использовали, или вообще Session Scope в Struts 2 нигде не упоминается у вас? Состояние всё в базе хранится? И нет кеша второго уровня... B>А аутентификация как реализована? B>Если у вас всё на столько круто, что вся сессия живет на клиенте и в базе, тогда и репликацию можно будет свести к минимуму.
Честно говоря, люди, писавшие систему, включая меня, далеко не специалисты. Писали сами по наитию, и по гуглу, и может чего-то неправильно писали. Но!
Сейчас HttpSession вообще никак не используется. Аутентификация и авторизация сделаны через Spring Security.
К сессии ничего не прикрепляется, SessionAware акшоны не используются. Всё хранится в базе, ну и идентификаторы объектов в формах на клиенте, конечно.
Кеш тоже пока никакой не использовали, вместо этого просто взяли по-быстрее железо. Просто потому что боимся получить проблемы, которые обычно сложно исследовать, нужен опыт и знания в этой области.
Опять же, может что-то неправильно сделали, но пока так
Re[6]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>Почему лучшее? Как определить критерий лучшего?
А просто альтернатив нет. Основные opensource JEE реализации —
Glassfish — исходники без слёз смотреть нельзя
Geronimo — самое глючное вообще. Даже Glassfish уделывает.
JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?
SK>Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего.
Субъекнивно. Если понимать как оно работает и настраивается, то думаю там не на столько всё плохо.
Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.
SK>Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией.
Одним словом — failover не нужен?
Re[7]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, Blazkowicz, Вы писали:
B>JBoss — быстрый, хорошо конфигуряемый. Судя по статьям\новостям двигается в правильном направлении. Распределенный кеш у них хороший. Так почему бы и нет?
Да потому, что нафиг он не нужен. Там нет ничего, что не подлючается отдельно. Начем нужно все сразу и еще через место навязанное jboss-ом.
SK>>Application server, сам по себе гнилая идея и решения, которые он предлагает (я бы сказал — навязывает), тоже гнилые. Так, что пользоваться чем-то гнилым по-причине того, что оно самое лучшее из всего гнилого — ничего хорошего. B>Субъекнивно. Если понимать как оно работает и настраивается, то думаю там не на столько всё плохо. B>Не могу не согласится, что свой продуманый механизм кластеризации зачастую лучше. Но в данном случае, сильно в этом сомневаюсь.
Хорошо сказанно. Продуманный, конечно никогда не лушче
SK>>Данный топик, как раз хороший пример. Вместе того, чтобы прото поставать апач перед коробками и наслаждаться практически неограниченным горизонтальным маштабированием (не привязанным ни к jboss ни к чему либо еще), человеку предлагается включить репликацию и зафлудить сеть и серваки никому не нужной реплицией. B>Одним словом — failover не нужен?
Смотря где и для чего. Для большинства Web приложений failover в виде релогина 1%-20% (в зависимости от числа нод) пользователей ваще не проблема.
Re[5]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, ligett, Вы писали:
L>Сейчас HttpSession вообще никак не используется. Аутентификация и авторизация сделаны через Spring Security.
Откуда уверенность что Spring Security в сессии ничего не хранит? Просто вычитайте все атрибуты сессии после обработки запроса и посмотрите что там.
L>К сессии ничего не прикрепляется, SessionAware акшоны не используются. Всё хранится в базе, ну и идентификаторы объектов в формах на клиенте, конечно.
Ну, если так. То хорошо. Можно тогда максимально всё из сессии вынести в формы.
L>Кеш тоже пока никакой не использовали, вместо этого просто взяли по-быстрее железо.
А говорите достигли предела вертикального масштабирования. Кеш может увеличить производительность просто на порядок.
Re[4]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, Blazkowicz, Вы писали:
SK>>А вот этого не надо. Репликация, в данном случае (как, впрочем в большинстве случаев, кроме резервирования) — зло. Можно просто включить кеширование на каждой ноде в отдельности. В большинстве web приложений больше и не надо, т.к. данные не пересекаются. B>Угу, только в процессе failover это будет выглядеть так. B>Нода упала, все клиенты пошли на резервную. Кеш пуст. И давай все вместе запросами базу нагибать.
Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить.
Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.
SK>>И сессию тоже не надо реплицировать. Sticky session решит все проблемы. B>Какие ещё проблемы оно решит? Это просто способ распределения нагрузки.
Да вы что? А мы тут как о scalability и говорим, нет?
Re[5]: горизонт. scalability в веб-приложениях Java (jboss7, struts2, hibernate,
Здравствуйте, StanislavK, Вы писали:
SK>Не все вместе, а какой-то процент. Кстати, базу тоже не помешало бы расшардить. SK>Ваще когда нода упала, все равно что-то, где-то всегда будет нагибаться и это отдельная тема как избежать проблем.
Если не использовать кеш, то да, всё может очень быстро упереться в базу.
SK>Да вы что? А мы тут как о scalability и говорим, нет?
Распределение нагрузки не решает всех проблем масштабирования.
