как уменьшить использование HttpSession

В моем приложении есть много объектов в сеансе. Поэтому размер HttpSession высок для каждого пользователя, который получает доступ к моему приложению (это система управления информацией о сотрудниках). Я попытался уменьшить объекты в сеансе и некоторое время использовал метод HttpRequest. Как бы то ни было, сеанс переносит много объектов, что приводит к высокому использованию памяти JVM и замедлению работы сервера. Поэтому мне нужно уменьшить размер сеанса.

Любое решение для этого? Должен ли я добавить еще один сервер и сбалансировать нагрузку или увеличить размер ОЗУ ПК или обновить память JVM (если я обновлю так, что произойдет в будущем, когда больше пользователей, чем сейчас, будет использовать систему, тогда снова мне придется обновить память ?) ? Мое предполагаемое решение состоит в том, чтобы добавить этот объект на сервер кэширования, который работает на отдельном сервере (отдельный компьютер) вместо сеанса.
Пожалуйста, дайте мне знать ваши идеи.


person Débora    schedule 01.05.2014    source источник
comment
Сколько памяти вам в настоящее время нужно для сеанса? Сколько клиентов у приложения? Сначала вы должны определить свою проблему. Разве вы не можете сначала попытаться уменьшить данные, которые вы загружаете в сеанс? После доработки приложение полностью зависит от окружения. Сначала можно увеличить память, после чего можно передать хранилище сеансов на сервер базы данных. (Redis (самый быстрый), MongoDB, Postgres, MySQL)   -  person Marc Bachmann    schedule 01.05.2014
comment
Спасибо за быстрый ответ. Мне нужен размер сеанса от 500 КБ до 1 МБ и 100 одновременных пользователей. Все, что можно было сделать, насколько мне известно, уже сделано. Если я использую сервер базы данных, не может ли это быть проблемой производительности?   -  person Débora    schedule 01.05.2014


Ответы (1)


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

Если вы все еще считаете, что все это сделано, а значительных улучшений не наблюдается, то, как предложил Марк, вы можете попробовать уменьшить или увеличить масштаб в зависимости от ваших потребностей и ограничений. В качестве альтернативы вы можете использовать Memcached или еще раз, как Марк предложил Redis или Mongo, если вы согласны с сохранением сеансов и готовы немного снизить производительность. Я говорю немного, потому что эти вещи действуют очень быстро.

person Praba    schedule 01.05.2014