Производительность сервера приложений 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-сервера приложения, но на том же поле был быстрым, что бы вы исследовали?

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

Разъяснение редактирует:

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, который обслуживает статический контент.