
Как настроить maxConnectionsPerAgent и maxABLSessionsPerAgent для экземпляра PASOE
Параметры задаются в файле {CATALINA_BASE}\config\openedge.properties. Их можно указать:
- Глобально — в секции
[AppServer.Agent]. Тогда настройки применятся ко всем агентам. - Для конкретного экземпляра — в отдельной секции, например
[AppServer.SessMgr.oepas1]. Это приоритетнее глобальных настроек.
Пример фрагмента openedge.properties:
[AppServer.Agent]
maxConnectionsPerAgent=20
maxABLSessionsPerAgent=100
# Либо для конкретного агента:
[AppServer.SessMgr.oepas1]
maxConnectionsPerAgent=30
maxABLSessionsPerAgent=90
Как работают эти параметры
maxConnectionsPerAgent
Это лимит одновременных запросов (сессий-подключений), которые MS-Agent может обрабатывать в конкретный момент. Он ограничивает нагрузку на CPU для одного агента: если лимит достигнут, новые запросы встают в очередь либо (в зависимости от конфигурации и клиента) получают отказ. Когда нагрузка превышает этот порог, PAS может запускать дополнительные MS-Agents.
maxABLSessionsPerAgent
Это размер пула ABL‑сессий, которые агент держит в памяти. Эти сессии хранят контекст (переменные, состояние, курсоры и т. п.) для пользователей. Даже если пользователь сейчас не делает запрос, его сессия может оставаться активной в пуле, чтобы при следующем запросе быстро подхватить состояние.
Разница в поведении для разных типов приложений
Stateless (Session Free) приложения
В таких приложениях состояние не хранится между запросами: каждый HTTP‑запрос самодостаточен. В этом случае:
- Контекст между запросами не нужен.
- Оптимально ставить
maxABLSessionsPerAgent = maxConnectionsPerAgent. - Лишние ABL‑сессии не дают пользы, но тратят память.
Пример: оба параметра = 20. Агент держит ровно столько ABL‑сессий, сколько может обрабатывать одновременных запросов.
Session Managed приложения
Здесь состояние между запросами важно: пользователь «залогинен», у него есть контекст, который должен сохраняться, даже когда он не делает активных запросов. В этом случае:
maxABLSessionsPerAgent > maxConnectionsPerAgent.- Агент держит больше сессий, чем одновременно обрабатываемых запросов: это позволяет сохранять контекст для большего числа пользователей, при этом ограничивая пиковую нагрузку на CPU.
- Память расходуется активнее, потому что сессии живут дольше, чем активные запросы.
Ваш пример:
maxABLSessionsPerAgent = 100,maxConnectionsPerAgent = 20.- До 100 пользователей могут иметь активные сессии (контекст хранится в Session Manager и в пуле агента).
- Одновременно агент будет выполнять не более 20 запросов — это защищает CPU от перегрузки.
- Когда один из 20 активных запросов завершается, освобождается слот для следующего запроса от любого из 100 пользователей; сессия уже готова, контекст подгружается быстро.
- Если нагрузка растёт и требуется больше одновременных запросов, PAS запустит ещё один MS‑Agent (если конфигурация и ресурсы позволяют).
Практические рекомендации
- Начинайте с консервативных значений и масштабируйте по результатам нагрузочного тестирования.
- Следите за метриками:
- Очереди запросов (request queue length).
- Время отклика.
- Использование CPU и памяти агентами.
- Количество запущенных MS‑Agents.
- Учитывайте архитектуру приложения: если приложение stateless — не держите избыточный пул сессий. Если session managed — подбирайте соотношение так, чтобы покрыть пиковое число пользователей с учётом их «спорадической» активности.
- Не забывайте про Session Manager: лимиты на уровне агента — это только часть картины; общая ёмкость системы также зависит от настроек Session Manager и от того, как долго сессии могут оставаться активными.

