С появлением Java EE 7 и требованием обрабатывать расширенные функции, такие как API веб-сокетов и обновления HTTP (например, EJB через HTTP), команда разработчиков WildFly приняла важное решение. После долгой приверженности JBoss Web Server (ветвь Apache Tomcat) новый выпуск сервера приложений теперь основан на новом веб-сервере с именем Undertow .
Undertow — это гибкий, быстрый веб-сервер, написанный на Java, который основан на API нового ввода-вывода J2SE. Undertow разработан на основе композиционной архитектуры, которая позволяет создавать полнофункциональный веб-сервер путем объединения небольших отдельных компонентов, называемых обработчиками . Эти обработчики объединяются в цепочку, образуя либо полностью функциональный контейнер сервлета Java EE 3.1, либо более простой обработчик процесса HTTP, встроенный в ваш код.
Как видно из следующего рисунка, цепочка обработчиков состоит из нескольких отдельных обработчиков, которые в итоге выдают либо ответ сервлета, либо ошибку, например, в случае, если запрошенный путь не найден:
Веб-сервер также обладает гибкостью, позволяющей выбирать между неблокирующими асинхронными обработчиками для обработки задач или делегировать запросы блокирующему обработчику, поддерживаемому пулом потоков.
Теперь мы рассмотрим конфигурацию веб-сервера, поэтому просто откройте файл конфигурации (любой автономный файл конфигурации или domain.xml ) и перейдите к подсистеме « undertow », которая по умолчанию выглядит следующим образом:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
<subsystem xmlns="urn:jboss:domain:undertow:1.0"> <buffer-caches> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10" /> </buffer-caches> <server name="default-server"> <http-listener name="default" max-post-size="10485760" socket-binding="http" /> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content" /> </host> </server> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only"> <jsp-config /> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir" /> </servlet-container> <handlers> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true" /> </handlers></subsystem> |
Одним из ключевых элементов конфигурации Undertow являются буферные кэши . Буфер — это, по сути, блок памяти, в который вы можете записывать данные, которые потом сможете снова прочитать. Этот блок памяти обернут в объект NIO Buffer, который предоставляет набор методов, облегчающих работу с блоком памяти. Очевидное преимущество использования буфера состоит в том, что доступ к памяти намного быстрее, чем физический доступ.
Помимо Java NIO, WildFly широко использует XNIO ( http://www.jboss.org/xnio ), который представляет собой низкоуровневый уровень ввода / вывода, который можно использовать где угодно, чтобы упростить использование API NIO. Это решает некоторые сложности использования селекторов и отсутствие поддержки NIO для многоадресных сокетов и не-сокетных входов / выходов, таких как последовательные порты, сохраняя при этом все возможности, имеющиеся в NIO.
Чтобы управлять веб-сервером Undertow, в консоли администрирования выберите вкладку «Профиль» и перейдите на веб- панель. Это содержит набор меток, таких как:
- Веб-службы : используются для указания некоторых основных параметров веб-служб, таких как хост и порт WSDL.
- Сервлеты : Используются для указания использования режима разработки (по умолчанию false), который позволяет перезагружать JSP на лету
- HTTP : используется для настройки HTTP-коннекторов Undertow. Отсюда, например, вы будете связывать свой веб-сервер с пулом ресурсов ввода-вывода
- Undertow Core : используется для привязки обработчиков и фильтров к HTTP-соединению.
Настройка пула веб-серверов
Если вы прибываете из среды JBoss AS 7, это часть вашей конфигурации, которая будет меняться. В более раннем выпуске сервера приложений вы использовали ссылку на Thread Executor для настройки пула потоков вашего веб-сервера. С WildFly 8, с другой стороны, вам нужно ссылаться на элемент Worker, который необходимо создать в подсистеме ввода-вывода. Посмотрим, как это сделать. Разверните опцию Core из левого дерева меню и выберите « IO », как показано на следующем рисунке:
Панель « Рабочий » должна быть выбрана на главной панели. Как видите, рабочий по умолчанию уже существует. Вы можете в любое время создать или удалить новые, нажав на соответствующие кнопки. Однако прямо сейчас мы нажмем на ссылку « Изменить », чтобы настроить количество потоков, которые будут использоваться в нашем рабочем средстве по умолчанию. После нажатия на ссылку мы отредактируем следующие атрибуты:
Первый параметр, размер стека, соответствует размеру стека веб-сервера. При большем размере стека потоков веб-сервер будет потреблять больше ресурсов, и, следовательно, будет поддерживаться меньшее количество пользователей. Функция Keepalive Task (по умолчанию 60) контролирует количество секунд ожидания следующего запроса от того же клиента по тому же соединению. С Keep-Alives браузер избавляется от полного обхода каждого запроса после первого, обычно сокращая время полной загрузки страницы вдвое.
Количество потоков Io соответствует числу доступных потоков веб-сервера. Это важный параметр настройки, который необходимо увеличить для веб-приложений с высоким трафиком. Task Max Threads контролирует максимальное количество одновременных запросов. Нажмите Сохранить, когда вы в порядке с вашей конфигурацией IO Worker.
Теперь, когда мы определили Worker, нам нужно ссылаться на него со стороны веб-сервера. Для этого в левом древовидном меню разверните веб- подсистему и выберите опцию HTTP . Там вы сможете настроить некоторые свойства, которые свойственны HTTP-серверу:
Нажмите на элемент « default », содержащийся в таблице, и убедитесь, что элемент Worker связан с вашим IO Worker. Рабочий также должен быть включен , чтобы его можно было использовать. Далее нам нужно связать прослушиватель HTTP с привязкой сокетов (см. В левом меню «Общая конфигурация» параметр «Связывание сокетов», чтобы проверить доступные привязки сокетов для вашей конфигурации). Наконец, HTTP-сервер также связан с реализацией пула буферов Java NIO, которая обсуждается в следующем разделе.
После того, как вы завершили рабочую конфигурацию HTTP, веб-сервер будет использовать свои рабочие потоки, имена которых соответствуют следующим критериям: [имя работника] — [идентификатор работника]. Как видно из следующего рисунка, пользователь определил работника с именем « custom », который отслеживался в разделе «Потоки» утилиты JConsole (входит в стандартную версию JDK):
Настройка пула буферов веб-сервера
Как мы уже говорили, Undertow основан на Java NIO API и использует пул J2SE.
java.nio.ByteBuffer всякий раз, когда необходима буферизация.
Буфер — это объект, который содержит некоторые данные, которые должны быть записаны или только что прочитаны. Добавление объекта Buffer в NIO отмечает одно из самых значительных отличий между новой библиотекой и исходным вводом / выводом. В потоково-ориентированном вводе-выводе вы использовали для записи данных непосредственно и чтения данных непосредственно из потоковых объектов . В библиотеке NIO все данные обрабатываются с помощью буферов . Когда данные читаются, они читаются непосредственно в буфер. Когда данные записываются, они записываются в буфер. Каждый раз, когда вы получаете доступ к данным в NIO, вы извлекаете их из буфера.
Доступ к конфигурации пула буферов ввода-вывода можно получить, выбрав Core | IO покинул меню и опцию Buffer Pools, как показано на следующем рисунке:
Нажмите на строку «Буферный пул по умолчанию », где вы сможете настроить следующие элементы:
| Буферы на ломтик | Этот параметр определяет, сколько буферов на слайс назначено. Срезы используются для манипулирования частями больших буферов, избегая накладных расходов при обработке всего буфера .
|
| Прямые буферы | Эта опция позволяет вам выбрать, установлены ли буферы как прямые или нет. Характеристика прямых буферов заключается в том, что они размещаются вне кучи Java; следовательно, после выделения их адрес памяти фиксируется на время существования буфера. Наличие фиксированного адреса памяти в свою очередь приводит к тому, что ядро может безопасно обращаться к ним напрямую, и, следовательно, прямые буферы могут более эффективно использоваться в операциях ввода-вывода |
| Размер буфера | Эта опция позволяет вам определить размер java.nio.ByteBuffer . При условии, что используются прямые буферы, буферы по умолчанию в 16 КБ оптимальны, если требуется максимальная производительность (поскольку это соответствует размеру буфера сокетов по умолчанию в Linux). |
Этот отрывок взят из « Книги Wildfly 8 », которая представляет собой практическое и простое для понимания руководство, в котором обсуждается самый популярный сервер приложений Java с открытым исходным кодом: JBoss Wildfily (переименованный из JBoss AS). Эта книга охватывает все детали администрирования и управления этой новой захватывающей версией сервера приложений. Ориентируясь исключительно на инструменты управления сервером приложений, книга знакомит вас со всеми последними изменениями архитектуры и производительности. Вы перейдете от базовой конфигурации сервера к более продвинутым методам кластеризации, подключения JDBC, ведения журналов и многого другого.