Вопрос

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

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

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

Это было полезно?

Решение

JSF — полезная технология, но на ней, конечно, можно повеситься.

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

Легко висящий плод — проверить управляемые компоненты, настроенные для области сеанса в лица-config.xml.

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

Мат.

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

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

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

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

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

Кроме того, проверьте мою статью " Java Server Лица в реальных приложениях & Quot; на DZone он даст вам полную картину о JSF в средах разработки, тестирования и производства.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top