Здравствуйте, 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>То есть получается не "Не надо его реплицировать" а "Можно не реплицировать если ..."
Получается, что "реплицировать, если больше уже ну совсем никак".