Зависимость от производительности виртуальной машины Java

Регулировка производительности любого Java-приложения в значительной сте­пени зависит от JVM. Следовательно, если задача состоит в том, чтобы разрабо­тать и разместить высокопроизводительное серверное приложение EJB, не обой­тись без планирования ряда операций, связанных с конфигурированием JVM и регулировкой производительности.

Одной из важнейших настроек является емкость кучи JVM. Кучей (heap) на­зывается репозитарий объектов Java и свободной памяти. Когда в куче JVM за­канчивается свободная память, исполнение в ней приостанавливается вплоть до того момента, когда алгоритм сбора мусора освободит невостребованные участки памяти. Блокирование прикладного кода в ходе сбора мусора — это очевидный удар по производительности. Все операции, проводящиеся в приложении EJB на стороне сервера, в эти периоды останавливаются.

Если емкость кучи высока, сбор мусора проводится довольно редко; впрочем, когда он все же случается, то занимает значительное время, в течение которого могут быть нарушены нормальные системные операции. Операция сбора мусора способна снизить скорость (а в отдельных случаях — полностью остановить) об­работки данных на сервере, который в таком случае будет восприниматься как медленный и нереактивный.

Для оптимальной настройки емкости кучи JVM необходимо проследить за проводимыми на серверной машине операциями разбиения на страницы. Разби­ение на страницы существенно снижает производительность, а для того чтобы

избежать проведении подобных операций на серверах приложений, следует уве­личить емкость кучи JVM согласно потребностям конкретного приложения. Дру­гое решение предполагает контроль над сборщиком мусора при помощи настрой­ки компилятора -gcverbose. Если возможен добавочный сбор мусора, его, как правило, лучше включать.

16.5. Заключение

К созданию многозвенной архитектуры J2EE компанию Sun Microsystems под­толкнули ее собственные коммерческие потребности. Они, в свою очередь, фор­мировались под влиянием опыта применения модели CORBA и конкурентного давления со стороны других специальных моделей распределенного программи­рования — в частности, COM+ от Microsoft. В состав J2EE входит серверный компонентный каркас для конструирования серверных Java-приложений корпо­ративного уровня, и называется он системой корпоративных JavaBeans (Enterprise JavaBeans).

Спецификация J2EE/EJB постоянно расширяется. В настоящее время в ней предусмотрены готовые к употреблению службы транзакций, безопасности, ус­тойчивости и управления ресурсами. Все эти службы позволяют прикладным программистам, имеющим дело c J2EE/EJB, не заботясь о низкоуровневых деталях распределения, обращать более серьезное внимание на разработку бизнес-логи­ки. Переносимость в J2EE/EJB реализуется за счет применения общеупотреби­тельного, переносимого языка (Java) и точных контрактов между компонентами. Производительность и масштабируемость производительности достигаются за счет распределения приложений между многочисленными процессорами (горизонталь­ное масштабирование), сеансовых beans без запоминания состояния, организа­ции пула ресурсов и ряда других механизмов.

Несмотря на кажущуюся простоту модели программирования J2ЕЕ/ЕJB, мно­гие архитектурные решения прикладного уровня нужно тщательно продумывать. Для получения проектного решения, оптимального в контексте требований по атрибутам качества, необходимы анализ и сравнение различных компромиссных архитектурных решений.

16.6. Дополнительная литература

Сведения об архитектуре и спецификации J2ЕЕ/ЕJB крайне многочисленны. Стоит зайти на раздел сайта Sun Microsystems, посвященный этой технологии (http:// java.sun.com/j2ee), — на нем предлагается удобное пособие для новичков, заинте­ресовавшихся J2EE, ряд официальных документов и собственно спецификация J2EE/EJB. Существует множество оживленных форумов, посвященных архитек­туре и технологическому пространству J2EE, — в частности, форум, организо­ванный компанией Middleware (http://www.theserverside.com).

16.7. Д искуссионные вопросы

1. В качестве дополнения к компонентной модели EJB версии 2.0 определены «управляемые сообщениями beans». Под этим именем кроются корпора­тивные beans, позволяющие приложениям J2EE проводить асинхронную обработку сообщений. Назовите несколько вариантов применения такого компонента. Какие возможности в контексте корпоративной архитектуры открывают управляемые сообщениями beans?

2. Многие методики в рамках спецификации J2EE/EJB, по существу, лишь реализуют тактику «введение посредника». Попробуйте найти как можно больше подобных случаев.

3. Обратимся к конкретному примеру компании CelsiusTech, изложенному в главе 15. Как вы считаете, подходит ли инфраструктура J2EE/EJB для реализации систем, выпускаемых этой компанией? Аргументируйте ваш ответ.

Глава 17

Дата добавления: 2015-04-25