Веб-приложение OpenEdge ABL
Веб-приложения OpenEdge (oeabl.war), функционирующие в PAS, представляют собой стандартные веб-приложения Java, выполняющиеся в контексте HTTP-запроса, инициирующего поток PAS. Эти приложения обеспечивают интеграцию между HTTP-запросами и запросами ABL. Как и в случае с любыми другими веб-приложениями, каждый клиентский HTTP-запрос обрабатывается в отдельном потоке из пула потоков PAS. Веб-приложения ABL конфигурируются для использования процессорных ресурсов, памяти (кучи) и постоянного поколения (permgen), в зависимости от уровня активности клиентских запросов и объема передаваемых данных.
Каждое приложение ABL, установленное в PAS для OpenEdge, включает пул сеансов ABL, который совместно используется одним или несколькими веб-приложениями для обработки клиентских запросов. Веб-приложения oeabl оптимизированы таким образом, что в любой момент времени в памяти permgen загружается только один экземпляр класса. Это означает, что независимо от количества приложений ABL и связанных с ними веб-приложений, распределение памяти permgen остается аналогичным тому, как если бы было развернуто единственное веб-приложение.
Каждое веб-приложение oeabl поддерживает один или несколько транспортных протоколов, которые могут быть независимо активированы или деактивированы:
- APSV HTTP туннелирование проводного протокола сервера приложений OpenEdge (предоставляется через AIA в классической архитектуре сервера приложений OpenEdge).
- SOAP транспорт (предоставляется через WSA в классической архитектуре сервера приложений OpenEdge).
- REST транспорт (предоставляется через REST-адаптер в классической архитектуре сервера приложений OpenEdge).
- WEB транспорт (предоставляется через WebSpeed в классической архитектуре сервера приложений OpenEdge).
Выбор транспортных протоколов влияет на потребление процессорных ресурсов и оперативной памяти. Некоторые протоколы, такие как SOAP, требуют значительных ресурсов процессора и памяти для обработки каждого клиентского HTTP-запроса, в то время как другие, например APSV, потребляют меньше ресурсов. Остальные протоколы занимают промежуточное положение между APSV и SOAP по уровню потребления ресурсов. Уровень активности транспортировки, а также архитектура и реализация приложения ABL определяют общий объем потребляемых ресурсов. Не существует универсальной формулы для предсказания объема необходимых ресурсов; рекомендуется провести тестирование приложения ABL в среде PAS for OpenEdge и оценить его влияние на систему.
Каждое веб-приложение использует общий диспетчер сеансов ABL (ABL Session Manager) для управления пулом сеансов ABL. Пул сеансов ABL действует как механизм буферизации и диспетчеризации для обработки клиентских запросов. Размер пула динамически увеличивается или уменьшается в зависимости от нагрузки и настроек конфигурации, что также влияет на объем используемой памяти кучи. В случае превышения входящей нагрузки над возможностями пула сеансов, запросы ставятся в очередь на определенный период времени. Если запрос остается в очереди слишком долго, он отменяется, и клиенту возвращается сообщение об ошибке. Когда пул сеансов достигает максимального размера и очередь заполнена, клиенту немедленно возвращается сообщение об ошибке.
Управление пулом сеансов приложений ABL
Пул сеансов приложений ABL обеспечивает управление пулом мультисессионных агентов (MS-Agent) операционной системы, которые поддерживают физические сеансы ABL для обработки клиентских запросов. При запуске PAS for OpenEdge автоматически создается один процесс MS-Agent. Дополнительные процессы MS-Agent добавляются при необходимости для удовлетворения спроса на клиентские запросы. Рекомендуется использовать один MS-Agent максимально эффективно и добавлять дополнительные процессы только в случае крайней необходимости.
Пул сеансов ABL поддерживает настройку количества подключений к локальным сокетам для каждого процесса MS-Agent. Это значение определяет максимальное количество запросов ABL, которые могут быть обработаны одновременно одним MS-Agent.
Для управления параметрами пула сеансов ABL можно настроить его общий размер, количество клиентских запросов в очереди и количество одновременных клиентских запросов, которые могут быть обработаны.
Влияние на производительность
Существует потенциальный побочный эффект, связанный с постановкой клиентских запросов в очередь диспетчером сеансов и временем их выполнения. Этот эффект может привести к исчерпанию пула потоков PAS и отклонению клиентских запросов. Увеличение продолжительности выполнения клиентских запросов также может быть вызвано тем, что поток PAS дольше привязан к клиентскому запросу и не может быть повторно использован для обработки других запросов.
Для оптимизации работы системы необходимо обеспечить баланс между управлением пулом потоков PAS, пулом сеансов ABL и разработкой и внедрением приложения ABL.
Выполнение бизнес-логики OpenEdge в MS-Agent
Поскольку язык ABL не может быть выполнен в процессе PAS JVM, физические сеансы ABL, обрабатывающие клиентские запросы, размещаются во внешних MS-Agent. Каждый процесс MS-Agent предназначен для размещения нескольких сеансов ABL, использующих многопоточную архитектуру для параллельного выполнения клиентских запросов.
Количество клиентских запросов, которые может обрабатывать MS-Agent одновременно, не зависит от количества сеансов ABL. Каждый сеанс ABL использует небольшой объем памяти для состояния языкового ядра и хранения данных. Максимальный объем памяти, занимаемый одним сеансом ABL, определяется суммой локальных переменных ABL, глобальных переменных, временных таблиц, количества подключений к базе данных и объема загруженного R-кода.
Максимальное количество одновременно выполняемых клиентских запросов определяется меньшим из следующих значений:
- Максимальное количество подключений к локальным сокетам, настроенных между диспетчером сеансов ABL и MS-Agent.
- Количество свободных (неактивных) сеансов ABL, доступных для обработки клиентских запросов.
Соотношение между сетевыми подключениями Session Manager и количеством физических сеансов ABL в MS-Agent зависит от реализации приложения ABL. Если приложение использует клиентские подключения с привязкой к состоянию [stateful], соотношение сеансов ABL к локальным сокетам составляет n:1. При использовании несвязанных клиентских подключений без сохранения состояния [stateless] соотношение приближается к 1:1.
Мониторинг веб-приложений OpenEdge и MS-Agent
Мониторинг PAS for OpenEdge осуществляется с использованием набора операций по сбору метрик и запросов, доступных через консоль PAS JMX и веб-приложение удаленного администрирования OpenEdge (например, OpenEdge Explorer/Management). PAS for OpenEdge использует службы метрик с меньшими накладными расходами вместо громоздкого ведения журнала, используемого классическим сервером приложений OpenEdge. В большинстве случаев файлы журналов PAS for OpenEdge могут содержать не те же сообщения, что и классический OpenEdge AppServer.
Этот документ не содержит инструкций по использованию PAS for OpenEdge для сбора метрик. Подробная информация о метриках и запросах доступна в документации по продукту OpenEdge. В данном документе представлены общие сведения о метриках, которые можно собирать и запрашивать:
- Список сеансов, клиентов и подключений MS-Agent.
- Список зависших клиентов (время жизни которых превысило заданный промежуток).
- Список текущих клиентских запросов ABL.
- Сброс значений счетчиков метрик.
- Метрики диспетчера сеансов во время выполнения:
– Количество одновременных клиентов.
– Время ожидания соединения.
– Количество запросов в очереди.
– Общее количество запросов.
– Количество операций чтения и записи. - Метрики для каждого сеанса ABL:
– Время начала и окончания. - Метрики передачи данных APSV, REST, WEB и SOAP:
– Количество запросов.
– Количество успешных и неудачных попыток.