2013-04-09 3 views
3

В настоящее время я пытаюсь устранить узкие места в моем веб-приложении JSF/PrimeFaces. Для этого я установил VisualVM и его плагин GlassFish.VisualVM и GlassFish

Я не могу явно «профиль» над JMX, но я могу сгенерировать «выборку» вывода. Однако этот вывод показывает почти всю нагрузку в операции под названием $Proxy245.invoke().

VisualVM sampling output

Мои собственные операции (ch.diction. *) И логика взаимодействия SQL (com.mysql.jdbc. *), Который подозревался в качестве узких мест в первую очередь, кажется, не способствуют ужасная участь в этом недостатке производительности.

Отображаемая страница является типом PrimeFaces с несколькими сотнями разбитых на страницы записей. Количество записей существенно влияет на производительность, если не исключительно.

Так что мой вопрос: как я могу узнать, что лежит за $Proxy245.invoke(), чтобы определить реальное узкое место в этом сценарии?

Заранее спасибо за ваши советы и наилучшими пожеланиями

Паскаль

ответ

1

в $ Proxy245 является сгенерированный прокси-класс некоторыми AOP рамок в вашем случае это не ясно, какой из них. Он используется для перехвата вызовов метода. Поскольку он создан, вы не найдете реальных источников, потому что их нет. Я предлагаю вам создать дамп потока с VisualVM (вкладка «Темы») и проверить трассировки стека. Я уверен, что вы найдете этот метод (возможно, не для первой попытки, а несколько дампов). С помощью этого вы можете найти цепочку методов, которые в конце называют этот (прокси) метод.

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

+0

Спасибо, что на самом деле помогли! Дампп потока показал, что один из моих авторизаторов безопасности (Seam framework) напрямую обращался к базе данных при каждой проверке авторизации, а не к кешированному bean-компоненту. –

 Смежные вопросы

  • Нет связанных вопросов^_^