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

У меня есть несколько устаревшее приложение 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 ГБ.

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


person Community    schedule 14.11.2008    source источник
comment
Проксируются ли запросы (через Apache и т. д.) до того, как они поступят в SJSAS?   -  person digitalsanctum    schedule 14.11.2008
comment
Насколько мне известно, запросы не передаются через прокси. Запросы поступают непосредственно с машин LoadRunner в процесс сервера приложений. Но это очень хорошее предложение для подтверждения, так что у меня нет сомнений. Я опубликую обновление, когда я подтвержу. Спасибо!.   -  person jlpp    schedule 14.11.2008
comment
Вы смотрели на размер кучи JVM?   -  person matt b    schedule 14.11.2008
comment
digitalsanctum и Мэтт Б, я ответил на ваши вопросы в разделе «Редактирование разъяснений» исходного вопроса. Спасибо!   -  person jlpp    schedule 14.11.2008
comment
Ваше приложение использует EJB? проверьте размеры пула/кэша, увеличьте при необходимости   -  person Vladimir Dyuzhev    schedule 14.11.2008
comment
В приложении нет EJB.   -  person jlpp    schedule 14.11.2008


Ответы (2)


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

SunONE — это эталонный сервер реализации, и его не следует использовать для производства (не знаю о Glassfish).

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

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

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

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

person Vladimir Dyuzhev    schedule 14.11.2008

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

-XX:+DisableExplicitGC -XX:+AggressiveHeap

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

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

person jlpp    schedule 15.11.2008
comment
GC, работающий раз в 2 секунды на почти пустой куче, влияет на производительность? О_О сколько именно было? - person Vladimir Dyuzhev; 22.11.2008