Советы по производительности/памяти JSP Struts

Я работаю над базовым приложением на основе Struts, которое испытывает большие всплески памяти. У нас есть инструмент мониторинга, который заметит один запрос на пользователя, добавляющий 3 МБ памяти кучи JVM. Есть ли какие-нибудь советы по поощрению более ранней сборки мусора, освобождению памяти или повышению производительности?

Приложение представляет собой базовое приложение Struts, но в отчете JSP много строк, поэтому может быть создано много объектов. Но это не вещи, которые вы не видели раньше.

  1. Выполнить набор запросов к базе данных.
  2. Создайте сериализованный объектный компонент POJO. Это представляет строку.
  3. Добавить строку в список массивов.
  4. Установите список массивов в объект формы при вызове действия.
  5. Логика JSP будет перебирать список из ActionForm, и данные отображаются пользователю.

Примечания:
1. Форма находится в области сеанса и, возможно, в том списке массивов данных (возможно, это проблема).
2. Компонент POJO содержит примерно 20 полей, смесь String или BigDecimal данных.

В отчете может быть от 300 до 1200 или около того строк. Таким образом, создано как минимум столько же объектов.


performance jsp jakarta-ee struts
person Berlin Brown    schedule 04.12.2008    source источник

Ответы (3)


arrow_upward
0
arrow_downward

  1. Пункт списка

При проектировании отчетов для отображения в веб-приложении учитывайте количество записей, извлеченных из базы данных.

Если количество записей велико и общий набор записей занимает много памяти, рассмотрите возможность разбиения отчета на страницы.

Насколько это возможно, не вызывайте сборщик мусора явно. Это так по двум причинам:

  1. Сборка мусора является дорогостоящим процессом, так как сканирует всю память.

  2. Большинство производственных серверов будут настроены на уровне JVM, чтобы избежать явного сбора мусора.

person Community    schedule 26.12.2008
comment
Кроме того, если я скажу сборщику мусора запуститься, нет никакой гарантии, что он запустится. - person tom; 19.07.2013

arrow_upward
2
arrow_downward

Учитывая предоставленную вами информацию, я полагаю, что вы обычно загружаете от 1 до 2 мегабайт данных для результата: 750 строк * 20 полей * 100 байт на поле = 1,4 МБ. Теперь рассмотрим все временные объекты, необходимые между базой данных и окончательной разметкой. 3 Мб не удивительно.

Я был бы обеспокоен только тем, если бы эта память, кажется, просочилась; то есть следующая сборка мусора пространства молодого поколения не собирает все эти объекты.

person erickson    schedule 04.12.2008

arrow_upward
0
arrow_downward

Я считаю, что проблема заключается в массиве в ActionForm, которому необходимо выделить огромный кусок памяти. Я бы написал результаты запроса прямо в ответ: прочитал строку из набора результатов, написал в ответ, прочитал следующую строку, написал и т. д. Может быть, это не MVC, но для вашей кучи было бы лучше :-)

ActionForms хороши для операций CRUD, но для отчетов... я так не думаю.

Примечание: если ActionForm имеет scope=session, экземпляр будет активен (вместе с огромным arraylist) до истечения срока действия сеанса. Если scope=request, экземпляр будет доступен для GC.

person Lluis Martinez    schedule 27.04.2009