Производительность сервера приложений Java

Question

У меня несколько устаревшее приложение Java EE, работающее на Sun Application Server 8.1 (он же SJSAS, предшественник Glassfish). С более чем 500 пользователями одновременно приложение становится неприемлемо медленным, и я пытаюсь помочь определить, на что тратится большая часть времени выполнения и что можно сделать, чтобы ускорить его. До сих пор мы экспериментировали и измеряли LoadRunner, логи сервера приложений, Oracle statpack, snoop, настраивали потоки акцептора и сеанса (рабочий) сервера приложений, настраивали размер пакета Hibernate и использование выборки соединения и т. Д., Но после некоторого начального выигрыша мы изо всех сил пытаемся улучшить ситуацию.

Хорошо, с этим введением в проблему, вот реальный вопрос: если у вас было медленное приложение Java EE, работающее на коробке, использование ЦП и памяти которой никогда не превышало 20%, и при работе с 500+ пользователями вы показали две вещи : 1) что запрос даже статических файлов в том же процессе JVM сервера приложений был чрезвычайно медленным, и 2) что запрос статического файла вне процесса JVM сервера приложений, но в том же окне был быстрым, что бы вы исследовали?

Сначала мои мысли переместились на потоки сервера приложений, как на принимающий, так и на сеансовый, и я подумал, что даже запросы на статические файлы были поставлены в очередь, ожидая доступного потока, и если ЦП / память действительно не облагались налогом, тогда больше потоков были в порядке. Но затем мы существенно увеличили потоки как акцептора, так и сеанса, и улучшения не было.

Исправления:

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

2) Я не думаю, что между запрашивающими и сервером приложений есть прокси, но даже если бы он существовал, он не перегружен, потому что статические файлы запрашиваются с того же компьютера сервера приложений, но за пределами JVM приложения экземпляр возвращается немедленно.

3) Размер кучи JVM (Xmx) установлен на 1 ГБ.

Спасибо за любую помощь!

Answer 1

После использования инструмента мониторинга производительности Sun мы обнаружили, что сборщик мусора работает каждые пару секунд и что используется только около 100 МБ из 1 ГБ кучи. Поэтому мы попытались добавить следующие параметры JVM и пока что эта новая конфигурация как значительно улучшила производительность.

-XX: + DisableExplicitGC -XX: + AggressiveHeap

См. http://java.sun.com/docs/performance/appserver/AppServerPerfFaq.html

Наш урок: не оставляйте настройки параметров JVM и настройки сборки мусора до конца. Если у вас проблемы с производительностью, обратите внимание на эти параметры в начале процесса устранения неполадок.

Answer 2

Сам SunONE - это боль в заднице. У меня такая же проблема, и знаете что? Простое повторное развертывание того же приложения в Weblogic уменьшило потребление памяти и ЦП примерно на 30%.

SunONE является эталонным сервером реализации и не должен использоваться для производства (не знаю о Glassfish).

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

Может быть, попытка развернуть JBoss или Weblogic на одной машине даст вам подсказку?

P.S. Вы не должны обслуживать статический контент из-под сервера приложений (хотя я делаю это иногда, когда процессор загружен).

P.P.S. 500 одновременных пользователей - довольно высокая нагрузка, я бы определенно поставил SunONE за кеширующий прокси или Apache, который обслуживает статический контент.