Работа с веб-сервисами в платформе 1С:Предприятие 8.2 существенно отличается от современных версий 8.3. Основные сложности возникают при попытке высоконагруженной эксплуатации системы, когда количество одновременных запросов исчисляется десятками или сотнями. Рассмотрим подробнее внутренние механизмы взаимодействия платформы с веб-сервером IIS, разберем причины возникновения очередей и проанализируем возможности аппаратной части сервера.
Первый и самый важный вопрос касается управления сеансами. Проанализируем, как 1С 8.2 обрабатывает входящий запрос. В данной версии платформы по умолчанию на каждое входящее соединение к веб-сервису создается отдельный новый сеанс. Это критически важный момент, так как инициализация сеанса в 1С — это «дорогая» операция.
Когда веб-сервер IIS получает запрос и передает его расширению wsisapi.dll, происходят следующие действия:
Если к вашей системе одновременно обращаются 100 пользователей, сервер попытается поднять 100 независимых сеансов. В условиях 1С 8.2 это практически гарантированно приведет к исчерпанию ресурсов CPU и RAM еще на этапе загрузки конфигурации. Выясним причину, почему это происходит именно в 8.2: механизм пула соединений (connection pooling) в этой версии реализован крайне нестабильно. Хотя в файле default.vrd можно указать параметры пула, на практике в версии 8.2.19 сессии часто не возвращаются в пул корректно, что приводит к постоянным пересозданиям объектов.
Разберем техническую особенность компоненты wsisapi.dll, которая используется для публикации баз на IIS. В версии 8.2 это расширение долгое время оставалось фактически однопоточным. Это означает, что пока один запрос обрабатывается внутри 1С, остальные запросы выстраиваются в очередь на уровне веб-сервера. Даже если у вас мощный многоядерный процессор, 1С может обрабатывать запросы последовательно, «по одному».
Для обхода этой ситуации на IIS 7.5 можно рассмотреть использование режима Web Garden. Это настройка пула приложений, позволяющая запускать несколько рабочих процессов w3wp.exe. Однако помните: каждый такой процесс будет потреблять колоссальное количество памяти, дублируя загруженные библиотеки платформы 1С.
Посмотрим на структуру файла default.vrd, который управляет поведением публикации. Даже в 8.2 мы можем попытаться оптимизировать работу сессий, добавив параметры пула. Разберем пример настройки:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/MyBase"
ib="Srvr=MyServer;Ref=MyBase;">
<ws>
<point name="MyWebService" alias="ws1.1cws" enable="true" reuseSessions="autouse" poolSize="10" poolTimeout="60"/>
</ws>
</point>
В этом примере мы используем параметры:
reuseSessions="autouse" — попытка заставить платформу использовать существующие сеансы.poolSize — количество удерживаемых в памяти готовых сеансов.poolTimeout — время (в секундах), в течение которого сеанс считается живым в пуле.Важно: В платформе 8.2.19 эти параметры часто игнорируются или работают некорректно, особенно при высокой интенсивности запросов. В отличие от 8.3, где пул соединений был фундаментально переработан, здесь вы можете столкнуться с тем, что система всё равно будет создавать новые сеансы при малейшей задержке.
Проанализируем ситуацию с точки зрения «железа». Указанная конфигурация (Intel i5-6400 2.7 Ghz, RAM 16gb) для 100 одновременных пользователей веб-сервиса является крайне недостаточной. Выясним почему:
504 Gateway Timeout или 500 Internal Server Error.Чтобы хоть как-то облегчить жизнь серверу на платформе 8.2, мы должны минимизировать нагрузку при старте системы. Рассмотрим, как это сделать программно. Основная задача — исключить выполнение лишнего кода в модуле управляемого приложения и модуле внешнего соединения при обращении через веб-сервис.
Разберем пример кода в модуле:
Процедура ПриНачалеРаботыСистемы()
// Если это подключение через веб-сервис или внешнее соединение,
// прерываем выполнение тяжелых процедур
#Если Не ВнешнееСоединение И Не ВебСервер Тогда
// Здесь выполняем инициализацию интерфейса, проверку обновлений и т.д.
ИнициализироватьИнтерфейсПользователя();
ПроверитьОбновленияКонфигурации();
#КонецЕсли
КонецПроцедуры
Использование директив препроцессора #Если Не ВебСервер позволяет сократить время инициализации сеанса в несколько раз, что критически важно, когда пул соединений работает нестабильно.
Часто возникает вопрос: станет ли работа стабильнее на Apache 2.2? Рассмотрим этот вариант. Apache использует иную модель процессов и потоков по сравнению с IIS. Однако для 1С 8.2 это не дает значительного преимущества. Основная проблема — внутри платформы 1С и её взаимодействия с mod_1c. Apache может чуть лучше справляться с удержанием соединений (Keep-Alive), но нагрузка на RAM и CPU при создании сеансов 1С останется идентичной. Исторически связка 1С + IIS на Windows считается более предсказуемой и проще поддается мониторингу через стандартные средства Performance Monitor.
Подводя итог, можно сказать, что стек 1С 8.2 + IIS 7.5 на десктопном железе не предназначен для обслуживания 100 одновременных пользователей через веб-сервисы. Для стабильной работы рекомендуем рассмотреть следующие шаги:
Проанализировав ситуацию, становится ясно: в текущих условиях вы столкнетесь с серьезными задержками. Оптимизируйте код инициализации и старайтесь не допускать одновременного пика запросов, распределяя нагрузку во времени.