#java #performance #jsf #memory-leaks #ajax4jsf
#java #Производительность #jsf #утечки памяти #ajax4jsf
Вопрос:
Я работаю над настройкой производительности корпоративного веб-приложения с примерно 300 одновременными пользователями. Я заметил из журнала GC, что куча приложений всегда растет, а объекты всегда накапливаются даже после полной сборки. Я получил дамп рабочей кучи и был удивлен, что объекты сеанса занимают более 90% размера кучи! Это все из-за AjaxStateHolderObject .
Приложение выполняется на JSF 1.X и RichFaces 3.3.0.
Перед началом этого обсуждения я попробовал следующее:
- Добавлен следующий код для web.xml
<context-param>
<param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name>
<param-value>1</param-value>
</context-param>
- Добавлен следующий код для web.xml
<context-param>
<param-name>com.sun.faces.numberOfViewsInSession</param-name>
<param-value>1</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>1</param-value>
</context-param>
- Обновлено с RichFaces 3.3.0 до 3.3.3
Все вышеуказанные попытки не смогли решить проблему утечки памяти.
Обновления
* Один сеанс пользователя может занимать до 25 МБ из-за огромного размера AjaxStateHolder.
* Большинство управляемых компонентов приложения являются областью запроса, и в сеансе нет неиспользуемых объектов, на которые ссылаются, единственная проблема, связанная с памятью, — это ajaxStateHolder.
Заранее спасибо за любые рекомендации.
Любая помощь будет оценена, потому что я ничего не нашел по этой проблеме в Интернете.
Комментарии:
1. Вы действительно не даете достаточно подробностей, чтобы мы могли вам помочь. Сеанс может быть большим, но, возможно, это связано с тем, что ваш сервер приложений обслуживает 3 тыс. одновременных пользователей, а это МНОГО. Сколько памяти обычно потребляется одним сеансом пользователя? Хранятся ли в сеансе объекты, которые на самом деле могут быть без состояния? Можете ли вы использовать view scoped для некоторых ваших управляемых компонентов, чтобы ограничить область с отслеживанием состояния одной страницей? Ссылаются ли на их неиспользуемые объекты в управляемых сеансом компонентах, которые больше не читаются или не используются? Простые настройки конфигурации могут здесь ничего не изменить.
2. @maple_shaft Извините, это только опечатка, я имел в виду только 300 пользователей. 🙂 Один сеанс пользователя может занимать до 25 МБ. Большая часть управляемых компонентов относится к области запроса. В сеансе нет неиспользуемых ссылочных объектов, единственной проблемой, связанной с памятью, является ajaxStateHolder.
Ответ №1:
Похоже, вы столкнулись с дефектом утечки памяти сеанса JSF / a4j. Смотрите Ссылку ниже для получения более подробного описания по этому вопросу:
https://issues.jboss.org/browse/RF-3878
Похоже, что состояние представления кэшируется в сеансе и не очищается. Это ошибка с a4j, и ее нельзя исправить, просто обойти. Конфигурации, которые вы добавили web.xml , являются единственным предлагаемым обходным путем, но, по-видимому, это не слишком помогает.
Кажется, что a4j не очень масштабируемый, поэтому, возможно, лучшим долгосрочным решением является медленный рефакторинг компонентов a4j из приложения и замена их другой компонентной структурой? Извините, я не смог больше помочь, и я желаю вам удачи.
Комментарии:
1. Спасибо за ваш ответ. 🙂 Не могли бы вы рассказать мне, как реорганизовать / заменить компоненты a4j?
2. @M.ES Это слишком сложно и специфично для вашей ситуации, чтобы дать вам хороший ответ. Существует ряд различных компонентных фреймворков, которые могут эффективно заменить a4j: ICEfaces, PrettyFaces, Primefaces и многие другие, однако у них также могут быть похожие проблемы с управлением памятью. Мой совет — создать прототип и попытаться удалить a4j с одной страницы и заменить его компонентами из другого фреймворка. Поместите код инструментария в свой прототип и выполните нагрузочный тест. Отслеживайте использование памяти и сравнивайте с a4j. Было бы интересно узнать, у кого лучшее управление памятью.
3. продолжение… Похоже, это распространенная проблема с JSF, и, по крайней мере, я могу найти не так много хороших блогов по настройке производительности JSF.