JSF Tuning

Question

Встреча с проблемой, когда JSF заполняет наши сессии. У нас был сбой системы на днях. Отправил кучу в IBM для проверки и обнаружил, что у нас было несколько сеансов размером до 50 миллионов. Они нашли компоненты JSF в сессии и некоторые очень большие.

Итак, есть ли настройка, которая может быть выполнена? Элементы конфигурации, чтобы посмотреть? Или другое направление.

Наша система построена с использованием JSF и Spring для уровня представления, серверная часть - EJB, Spring и Hibernate, все работают в WebSphere 6.1.

Answer 1

JSF - полезная технология, но вы, безусловно, можете повеситься с ней.

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

Низко висящим плодом является проверка управляемых bean-компонентов, настроенных для области сеанса, в face-config.xml .

JSF сохраняет две вещи между запросами:

• просмотр (все элементы управления на странице)
• состояние просмотра (состояние элементов управления)

Они разделены, потому что некоторые элементы управления, такие как дочерние элементы таблицы данных, могут иметь несколько состояний (по одному для каждой строки). Состояние может быть сохранено либо в скрытом поле формы (которое, если оно не зашифровано, может представлять серьезную угрозу безопасности), либо в сеансе. Чтобы разместить несколько окон браузера, совместно использующих один и тот же сеанс (и, в некоторых реализациях, поддержку кнопки «Назад»), сохраняется несколько представлений.

• Должна быть опция конфигурации для установки количества состояний просмотра, которые приложение будет хранить в сеансе для данного пользователя в любой момент времени.
• Вы можете измерить размер состояния представления, предоставив StateManager , который измеряет размер сохраненного представления / состояния (настройте StateManager вface-config.xml с помощью открытого конструктора, который принимает StateManager - см. JSF spec PDF для получения дополнительной информации; состояние сериализуемо, и вы можете проверить его размер, выгрузив его в поток).

Большинство встроенных в IDE JSF-приложений имеют резервные компоненты. Возможно, с помощью области действия сессионного компонента удерживать состояние дольше, чем вы хотите, создавая нагрузку на сессию. Поскольку на страницу обычно приходится один компонент поддержки, чем больше у вас страниц, тем больше будет проблема. Проверьте Face-config.xml , чтобы увидеть, если это потенциальный источник проблем.

Что еще можно сделать, это настроить HttpSessionAttributeListener в вашем web.xml . Вы можете получить трассировку стека , чтобы помочь определить проблемные области в вашем приложении.

Answer 2

Я работал над проектом JSF и обнаружил, что у нас была ошибка, когда мы добавляли несколько элементов JSF h: form. В результате копия всей viewstate включена в каждую форму. Сокращение до 1 формы на страницу сбрило страницы от ~ 2M до ~ 300K.

Answer 3

Это вторая система, о которой я слышал, которая умерла из-за JSF и чрезмерного создания объекта. Другой также использовал Spring и Hibernate в конце. Профилирование с помощью OptimizeIt показало, что ответ бэкэнда был порядка миллисекунд для всех запросов, но вы можете снова рассчитать время рендеринга браузера с помощью секундомера, потому что это заняло так много времени - от 30 секунд до нескольких минут. Память, использованная клиентом, была нелепой.

Я был только наблюдателем, а не членом этой команды проекта. Я должен спросить, была ли когда-нибудь решена проблема и, если да, каким могло быть решение.

Но если две точки имеют тенденцию, я бы сказал, что JSF может быть смертельно ошибочным. Лично я держусь от этого подальше.

Почему бы не попробовать веб-интерфейс Spring и посмотреть, поможет ли это? Если вы следуете идиоме Spring, замена JSF на JSTL-контроллеры и Spring-контроллеры должна быть относительно простой.

Answer 4

Советы по настройке JSF для производственной среды:
- Использование ресурсов изображений, CSS и JavaScript должно выполняться стандартными тегами HTML (img,link,script), а не на стороне сервера, и обязательно указывать #{request.contextPath} перед URL, чтобы избежать проблем с относительными путями.
- Кэшировать статические разделы страницы (menu,header,footer), используя omnifaces cache
- Установите refresh-period переменную на -1
- установить project-stage на Производство
- Просмотрите ваши фильтры кода, если таковые имеются

Кроме того, посмотрите мою статью « Java Server Faces в реальных приложениях » на DZone, она даст вам полную картину о JSF в средах разработки, тестирования и производства.

Answer 5

Немного о старой теме, но сталкивался с этим недавно. Часто представление и состояние просмотра сохраняются (как упоминалось ранее) и заполняют сеанс, чтобы позволить кнопке «Назад» работать. В ваших дескрипторах развертывания (web.xml) есть параметры, которые нужно установить.

Для нескольких экземпляров определенных библиотек может потребоваться более одного параметра, например, при использовании MyFaces и JSF RI. По умолчанию они могут быть установлены на довольно высокие значения (соответственно, 20 и 16). Это означает, что вы можете использовать в 20 раз больше места, чем должны быть (части?) Сеанса.

Answer 6

Сконфигурируйте сохранение сеанса в базе данных, и он будет использовать наименее используемый алгоритм для удаления наименее используемых сеансов из памяти. Он имеет высокую производительность (при правильной настройке) и поможет вам конкретно и быстро.

Answer 7

Если вы используете MyFaces <1.1.6, существует огромная утечка памяти в том, что она кэширует старые сериализованные представления в сеансе, фактически не позволяя им освободиться, чтобы их можно было собрать мусором. У меня была серьезная проблема с этим, и у меня было 50 Мб сеансов. Быстрое обновление MyFaces исправило проблему без проблем. </p>

Answer 8

JSF сохраняет представления в сеансе, чтобы поддерживать его богатую компонентную архитектуру (необходимо поддерживать его состояние просмотра) и может заполнить кучу, если не используется должным образом. Если у вас нет больших рабочих потоков, всегда используйте небольшое количество просмотров за сеанс. Также старайтесь не держать бэк-бин в сессии как можно дольше. Используйте пользовательский тег для создания объекта данных только для следующего цикла запроса. Мы также можем использовать Spring Web Flow с JSF, который вводит область представления и область потока, если у нас есть длинные рабочие процессы в приложении, чтобы уменьшить количество представлений, настроенных в сеансе. JSF можно использовать для простого создания многофункционального пользовательского интерфейса, который помогает создавать веб-приложения, аналогичные настольным приложениям. Выделите определенную кучу для JSF-каркаса, чтобы выполнить свою работу. Но используйте память эффективно на стороне приложения и убедитесь, что нет утечки памяти. Все утечки памяти должны быть исследованы и исправлены во время самой разработки. Всегда используйте профилировщик, чтобы найти утечки памяти и узкие места производительности, которые существуют в приложении.

Mat.

Answer 9

У вас могут возникнуть проблемы с большим количеством компонентов поддержки в качестве области сеанса.

Вы можете попробовать заглянуть в MyFaces Orchestra . Это библиотека, которая предоставляет область диалога, поэтому, как только пользователь завершит работу с определенным набором компонентов, они будут удалены из сеанса.

Я понимаю, что Spring WebFlow имеет схожие функции, но я на самом деле не изучал его!