Перевод. Оригинальная статья http://in.relation.to/Bloggers/WhyIsJBossAS7SoFast .
Статье почти год, но вопрос по-прежнему актуален.
Вкратце, ответ следующий: потому что вся конструкция JBoss AS 7 основана на законе Мдейла (эффективное распараллеливание задач), а не на законе Мура (ожидание оборудования с более высокой частотой процессора).
Сегодня почти каждый процессор настольных компьютеров, ноутбуков и серверов имеет как минимум два ядра, и эта тенденция быстро растет. Времена гонок за скоростью процессора остались в прошлом.
Итак, программам приходится адаптироваться, чтобы выжимать из железа все, что есть сейчас и будет завтра.
Чтобы достичь этой революционной эволюции, JBoss AS претерпела агрессивную трансформацию.
Создавая AS 7, мы начали с чистого листа и с нуля создали совершенно новую, высокопроизводительную и хорошо управляемую архитектуру ядра.
Благодаря поистине потрясающей инженерной работе мы смогли пройти путь от крошечного прототипа на GitHub до полномасштабной реализации веб-профиля контейнера Java EE всего за год (не говоря уже о том, что за это время мы также выпустили AS 6, который предоставил Пользователи JBoss получают ранний доступ к технологиям EE6).
Прежде чем объяснить, позвольте мне сделать небольшое отступление.
Основная задача сервера приложений — управление сервисами.
Почти все компоненты современных приложений имеют какой-то жизненный цикл, то есть в какой-то момент компонент должен быть запущен, а затем остановлен.
Мы отмечаем все, что имеет жизненный цикл, как услугу.
Еще одним важным свойством услуг является то, что они обычно имеют отношения, которые соответствующим образом влияют на их жизненные циклы.
Например, можно сказать, что работа сервлета зависит от веб-сервера.
Кроме того, можно предположить, что если сервлет использует какой-то другой ресурс, скажем, соединение с базой данных или EJB, то это также зависит от их доступности.
Когда сервер приложений запускает или развертывает приложение, он должен гарантировать, что различные службы запускаются в правильной последовательности.
Далее, если какая-либо из этих служб каким-либо образом остановлена, он должен сначала остановить все, что зависит от этой службы (по сути, в обратном порядке).
Это довольно простая задача, если выполнять ее в одном потоке.
С другой стороны, JBoss AS 7 запускает и развертывает все службы параллельно.
Эту непростую задачу решает наш новый модульный сервисный контейнер — JBoss Modular Service Container. MSC, по сути, представляет собой усовершенствованную параллельную машину.
Он анализирует зависимости между всеми службами на лету и пытается запустить как можно больше служб одновременно, соблюдая при этом требования к зависимостям.
Это дает нам не только быстрый старт, но и возможность параллельного развертывания нескольких приложений.
Помимо параллельных сервисов, JBoss AS 7 также отличается модульностью и параллельной загрузкой классов.
Разлагая классы на соответствующие модули, сервер приложений может естественным образом оптимизировать доступ к классам и просматривать только то место, где этот класс фактически находится.
Поскольку видимость между модулями намеренно ограничена, операция поиска обходится дешево.
В случае модулей JBoss разрешение модулей и поиск классов происходят за O(1).
Все это выполняется на очень высоком уровне параллелизма, включая значительную часть анализа структуры классов.
Обработка развертывания также очень эффективна.
Самая важная оптимизация заключается в том, что мы индексируем информацию аннотаций, быстро сканируя часть данных класса.
Для еще большей эффективности мы позволяем модулям предварительно генерировать компактный индекс, предназначенный для быстрой загрузки.
Еще одна оптимизация развертывания заключается в том, что мы тщательно кэшируем и повторно используем данные структуры классов.
В заключение, последняя оптимизация, которую я хотел бы подчеркнуть, заключается в том, что мы были и будем очень строго относиться к нагрузке на ЦП и память во время запуска и развертывания.
Все это происходит благодаря выбору правильных решений на этапе проектирования.
.
Интересным примером таких решений является наш мораторий на использование JAXB (и любого другого строителя, основанного на самоанализ [1]) для анализа конфигурации, которая читается только один раз.
Прежде чем приступить непосредственно к разбору конфигурации, JAXB тратит столько же, если не больше времени, на понимание того, как этот анализ проводить.
И так везде.
Фактически, простой анализ XML в AS 5 и 6 занял больше времени, чем запуск всей AS 7. Я надеюсь, что это дает более четкое представление о том, как мы добились такого прироста производительности и почему некоторые вещи в AS 7 настолько отличаются от предыдущих версий.
Однако это только начало.
Следите за обновлениями в моем следующем блоге, где мы поговорим о будущих планах развития AS 7. Спасибо! [1] Мне не удалось найти приемлемый перевод, в оригинале: introspection Driven Binder — я думаю, это означает XML-десериализатор, который сначала парсит XMLSchema документа, чтобы понять типы данных, и только потом начинает саму десериализацию.
Теги: #jboss as 7 #javaee #с открытым исходным кодом #с открытым исходным кодом #java
-
Обзор Ноутбука Sony Vaio Vpcf11M1E/H
19 Oct, 24 -
Сумки Со Встроенной Розеткой
19 Oct, 24 -
Agiledays 2019
19 Oct, 24 -
Prfrl — Как Работает Интерфейс Аналитики
19 Oct, 24 -
Видеокурс По Javascript На Русском Языке
19 Oct, 24
