Проблемы с производительностью Java Webapp

Question

У меня есть веб-приложение, полностью выполненное с Java. Webapp не использует графическую/модельную структуру, вместо этого webapp использует The Model-View Controller. Он выполняется только с помощью спецификации сервлета (сервлет версии 2.4). Webapp разработан с 2001 года, и он очень сложный. Первоначально был построен для работы с Tomcat 4.x/5.x. На самом деле, работает на Tomcat 6.x. Но у нас все еще есть утечки памяти.

В Depth, спецификация The Webapp может возобновлено:

• Использование Servlet версии 2.4 Спецификации..
• Он не использует никаких рамок
• Он не использует JavaEE (не EJB)
• Он основан на JavaSE (с сервлетов)
• работает только на IE 6+ (из-за его возраст)

Инфраструктура Спецификация

на самом деле, веб-приложение работает в трех средах:

Первый

• IBM сервер (я не помню точно модель)
• Intel Xeon 2,4 ГГц
• 32GB RAM
• 1TB HDD
• Tomcat (Version 6) выполнен для использования 8 ГБ ОЗУ

Второй

• Dell Сервер
• Intel Xeon 2.0Ghz
• 4GB RAM
• 500GB HDD
• Tomcat (Version 5.5) настроен на использование 1.5GB оперативной памяти

Третий

• Dell Сервер
• Amd Opteron 1214 2.20Ghz
• 4GB RAM
• 320GB HDD
• Tomcat (Version 6) настроен на использование 1.5GB ОЗУ

спецификации базы данных

Webapp использует SQL Server 2008 R2 Express Edition в качестве СУБД, за исключением пользователя первой спецификации сервера, которая использует SQ L Server 2008 R2 Standard Edition.Для пулов соединений приложение использует APCP DBCP.

Проблема

Ну, это имеет очень серьезные проблемы с производительностью. Webapp замедляется постоянно и много раз отказывает в обслуживании. Единственный способ восстановить приложение - перезапустить службу Apache Tomcat. Во время аудита производительности я обнаружил несколько проблем программирования (Подобно подключению к базе данных, которое никогда не закрывается, excesive использование коллекции Vector [вместо ArrayList]).

Я хочу знать, как повысить производительность приложения, какие приложения могут помочь мне контролировать производительность Tomcat и использование памяти Webapp.

Все предложения с радостью приняты.

Answer 1

Я бы начал с некоторых инструментов, которые могут помочь вам профилировать приложение. Поскольку вы разрабатываете webapp, начинайте с Lambda Probe и Java melody.

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

1. Проблемы с производительностью возникают сразу после запуска приложений или сверхурочных?
2. Проблемы с производительностью связаны с количеством запросов клиентов?
3. Какова реальная проблема с производительностью - высокая загрузка на сервере или нехватка памяти (обратите внимание, что они связаны, поэтому проверьте, какой из них начинается первым)
4. Есть ли какие-либо фоновые процессы, которые выполняют некоторые массивные операции? Должны ли они планироваться в определенный период времени?

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

Как сказал Джошуа Блох в своей книге под названием «Эффективная Java», проблемы с производительностью редко являются следствием некоторых незначительных ошибок в исходном коде (хотя, конечно, неправильное использование конструкций Java может привести к катастрофе). Обычно причиной является плохая система (API).

Последнее предложение, основанное на моем опыте - постарайтесь не думать, что потребление высокой памяти - это что-то плохое. Tomcat будет использовать столько же памяти, что и операционная система, и JVM позволит ему (не более макс. Настроек) и просто, когда ему нужно больше - Tomcat будет выполнять сборку мусора. Таким образом, типичный (правильный!) График потребления памяти выглядит как пила. Если вы имеете дело с утечкой памяти, то график будет постоянно увеличиваться, но бесконечно. Это чаще всего неправильно понимается утечка памяти, поэтому имейте это в виду.

Если быть честным - мы не можем больше вам помочь. Это всего лишь указатели, теперь вам придется провести обширные исследования, чтобы выяснить причину:

Answer 2

Ok. Поэтому я видел, что огромные Java-приложения используют меньшие конфигурации. Вы должны попытаться сделать следующее:

1. Сначала подключите Profiler к вашему приложению и посмотрите, какая часть приложения занимает больше всего времени. Вы можете использовать JProfiler или Eclipse MAT (я лично предпочитаю JProfiler). Также попробуйте взглянуть на объекты, занимающие большую часть памяти. Это поможет вам сузить детали, которые вам нужно переписать, чтобы улучшить производительность.

2. После того, как вы взглянули на утечки памяти обновить приложение для использования 64-битной JDK (предполагая, что это уже не делает этого)

3. Посмотрите на ваши аргументы виртуальной машины Java и оптимизировать их.

Answer 3

Общее решение заключается в использовании профайлера, например. YourKit, с реалистичной рабочей нагрузкой, которая воспроизводит проблему.

Что я делаю первый является процессор только профиль, память только профиль и, наконец, профиль CPU & памяти на один раз (я тогда посмотрим на результаты профиля CPU)

YourKit может также отслеживать операции на высоком уровне таких ресурсов Java EE и JDBC-соединений. Я не пробовал, потому что я их не использую. ;)

Это может быть хорошей идеей для повышения эффективности, даже если это не причина проблемы, так как это уменьшит количество «шума» в этих профилях и сделает ваши проблемы более очевидными.

Вы можете попытаться увеличить объем доступной памяти, но подозреваемый это просто задержит проблему.

Answer 4

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

Вы должны сначала добавить фильтр в веб-приложение (as explained here) для записи показателей, а затем импортировать журналы в WAW Analyzer инструмента и следовать инструкциям described in the doc знать, где потенциальная проблема производительности в коде.

Answer 5

Вы также можете попробовать stagemonitor. Это библиотека мониторинга производительности с открытым исходным кодом. Он регистрирует время ответа на запрос, метрики JVM, данные запроса, включая стек вызовов (профиль) вызываемых методов во время запроса и т. Д. Из-за низких накладных расходов вы также можете использовать его в производстве.

Процедура настройки будет следующей.

• Определить медленные запросы с помощью запроса Dashboard
• Анализ трассировки стека запроса с Request Detail Dashboard, чтобы узнать о медленных методов
• Погружение в код и попытаться оптимизировать эти медленные методы
• Вы также можете сопоставить некоторые показатели, такие как пропускная способность или количество сеансов с временем отклика или использованием процессора
• Анализ кучи с помощью JVM Memory Dashboard

Примечание: Я разработчик stagemonitor.