При интеграции систем часто возникает классический сценарий: внешнее приложение (например, интернет-магазин, мобильный клиент или сторонний микросервис) обращается к опубликованному веб-сервису 1С. Представим ситуацию, когда к методу СоздатьНоменклатуру одновременно обращаются десять вызывающих систем. Как поведет себя платформа 1С? Выделятся ли под это отдельные потоки, выстроятся ли запросы в очередь или система вернет ошибку перегрузки? Разберем подробно внутреннюю кухню работы веб-сервисов 1С:Предприятие.
Поведение системы при параллельных запросах напрямую зависит от варианта работы информационной базы:
Для понимания того, как именно происходит это «параллельное чудо» без катастрофической потери производительности, нам необходимо разобраться в механизмах пулирования.
Часто разработчики путают пул низкоуровневых соединений и пул сеансов 1С. Однако это два совершенно разных уровня абстракции:
Пул соединений (Connection Pool). Это физические соединения между модулем расширения веб-сервера (который установлен на Apache или IIS) и кластером серверов 1С (процессами rphost). Эти соединения удерживаются открытыми, чтобы не тратить время на установление сетевого контакта при каждом запросе.
Пул сеансов (Session Pool / Повторное использование сеансов). Это логические сеансы пользователей внутри самой 1С. Инициализация полноценного сеанса (запуск модуля управляемого приложения, чтение параметров сеанса, проверка прав) — крайне ресурсоемкая операция, занимающая от 1 до 3 секунд. Если бы на каждый HTTP- или веб-запрос создавался новый сеанс с нуля, высоконагруженная интеграция была бы невозможна.
Для решения этой проблемы в платформе реализован механизм Повторного использования сеансов (Session Reuse). Платформа держит в памяти «спящие» сеансы, которые уже прошли авторизацию и инициализацию. При поступлении запроса веб-сервер мгновенно «будит» готовый сеанс, передает ему управление для выполнения метода СоздатьНоменклатуру, забирает результат и отправляет сеанс обратно «спать» в пул.
Все параметры параллельной работы веб-сервисов настраиваются в файле публикации default.vrd, который находится в каталоге публикации на веб-сервере. Настройки пула сеансов имеют наивысший приоритет именно здесь.
Рассмотрим структуру описания параметров повторного использования сеансов в файле конфигурации публикации:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyDatabase">
<ws>
<point name="ExchangeService"
alias="exchange.1cws"
reuseSessions="autouse"
sessionMaxAge="20"
poolSize="20"
poolTimeout="5"/>
</ws>
</point>
Разберем ключевые атрибуты этой настройки подробнее:
reuseSessions — определяет режим повторного использования сеансов. Может принимать три значения:
autouse — платформа автоматически управляет пулом «спящих» сеансов. Самый эффективный и рекомендуемый режим для большинства интеграций.use — сеансами управляет вызывающий клиент, передавая в заголовках запроса идентификатор сессии (например, IBSC-Session-ID). Это позволяет сохранять состояние между запросами.dontuse — повторное использование отключено. На каждый вызов создается и уничтожается полноценный сеанс. Крайне медленный режим, использовать который не рекомендуется.poolSize — максимальное количество готовых сеансов, удерживаемых в пуле для данного сервиса (по умолчанию равно 10). Если у вас планируется высокая нагрузка, это значение можно и нужно увеличивать (например, до 30-50), сопоставляя это с аппаратными возможностями сервера.poolTimeout — время (в секундах), которое входящий запрос будет послушно ждать в очереди, если все сеансы из poolSize заняты. По умолчанию составляет 5 секунд. Если за это время ни один сеанс не освободится, клиент получит ошибку HTTP 504 (Gateway Timeout) или внутренний сбой соединения.sessionMaxAge — время жизни «спящего» сеанса в секундах. Если к веб-сервису долго нет обращений, платформа уничтожит сеансы из пула, чтобы освободить оперативную память сервера.Один из важнейших практических вопросов: сколько клиентских лицензий 1С расходуется при работе веб-сервисов? Здесь нужно разделять техническую сторону вопроса и юридическую политику лицензирования фирмы «1С».
Технический аспект. Если все вызовы веб-сервиса выполняются под одной системной учетной записью (например, WebIntegration), лицензии расходуются по принципу: один активный сеанс в пуле — одна лицензия. Если в пиковый момент времени для обработки параллельных запросов платформа задействовала 10 сеансов из пула, сервер 1С заберет из общего пула доступных лицензий ровно 10 штук. Когда нагрузка спадет и сеансы будут уничтожены по истечении времени sessionMaxAge, лицензии вернутся в общий пул.
Юридический аспект (Мультиплексирование). Согласно Лицензионному соглашению «1С», использование программных средств, уменьшающих количество пользователей, непосредственно обращающихся к серверу 1С (мультиплексоров), не уменьшает количество необходимых клиентских лицензий. Если 100 внешних пользователей работают с базой 1С через веб-сайт, который в свою очередь держит пул из 10 сеансов веб-сервиса, технически будет расходоваться 10 лицензий. Однако с юридической точки зрения у компании должно быть приобретено 100 клиентских лицензий по количеству фактически работающих людей/устройств.
Когда количество одновременных запросов исчисляется сотнями или тысячами, начинают проявляться «детские болезни» интеграционных модулей расширения веб-серверов:
Apache на Linux. При использовании Apache критически важно обратить внимание на режим работы MPM (Multi-Processing Module). Крайне не рекомендуется использовать стандартный модуль prefork, который создает под каждое подключение отдельный тяжелый процесс операционной системы. При высокой нагрузке это приводит к моментальному исчерпанию оперативной памяти и аварийному завершению рабочих процессов 1С. Рассмотрите перевод Apache на многопоточные режимы работы — worker или event.
IIS на Windows. Работает через ISAPI-расширение wsisapi.dll. Под высокой нагрузкой могут происходить зависания сеансов или падения рабочих процессов 1С (rphost). В этом случае потребуется тонкая настройка пула приложений IIS (DefaultAppPool): ограничение по использованию оперативной памяти, настройка интервалов автоматической перезагрузки рабочих процессов w3wp и лимитов на максимальное количество подключений.
Начиная с современных версий платформы 1С:Предприятие 8.3, разработчикам доступен инструмент под названием Автономный сервер 1С (ibsrv). Он позволяет публиковать HTTP- и веб-сервисы напрямую, полностью исключая из цепочки сторонние веб-серверы вроде Apache или IIS.
Вся конфигурация публикации в автономном сервере описывается в единственном конфигурационном файле publication.yaml (аналог default.vrd). Пример настройки пулов в нем выглядит следующим образом:
VirtualDirectory:
Path: "/MyService"
Pool:
Size: 20
WaitTimeout: 10
Автономный сервер работает значительно быстрее традиционной связки с Apache/IIS, гораздо стабильнее держит высокие параллельные нагрузки и идеально подходит для развертывания в Docker-контейнерах в рамках микросервисной архитектуры.