При работе с файловыми базами 1С через веб-сервер IIS системные администраторы часто сталкиваются с проблемой «зависания» или медленной работы интерфейса, даже если аппаратные ресурсы сервера позволяют выполнять больше задач. Одним из эффективных, хотя и специфических решений, является создание нескольких виртуальных каталогов (публикаций) для одной и той же информационной базы. Рассмотрим подробно, зачем это нужно, как это работает и как правильно настроить такую конфигурацию.
Проанализируем техническую сторону вопроса. Когда 1С работает в файловом режиме через IIS, взаимодействие происходит через модуль расширения веб-сервера wsap64.dll (для 64-битных систем). По умолчанию все пользователи, подключающиеся к одной публикации (например, http://server/trade), обслуживаются в рамках одного рабочего процесса IIS — w3wp.exe.
Внутри этого процесса запросы часто выстраиваются в очередь. Если один пользователь запускает тяжелый отчет или процедуру проведения документов, поток выполнения в рамках данного процесса может быть занят, и остальные пользователи будут ждать ответа от сервера, видя «крутящееся колесико». Разделив пользователей на группы и предоставив им разные адреса (например, /base и /trade), мы заставляем IIS создать разные пулы приложений. Это порождает несколько независимых процессов w3wp.exe. Теперь тяжелый отчет в одном процессе не будет блокировать работу пользователей в другом процессе на уровне веб-сервера.
Разберем процесс настройки, который позволит реализовать схему параллельной работы. Для этого нам потребуется доступ к серверу с правами администратора и запущенный конфигуратор 1С.
C:\inetpub\wwwroot\base и C:\inetpub\wwwroot\trade. Это нужно для того, чтобы у каждой публикации был свой файл настроек default.vrd.base и выберем созданный ранее каталог C:\inetpub\wwwroot\base. Нажмем «Опубликовать».trade и выберем каталог C:\inetpub\wwwroot\trade. Важно, чтобы параметры подключения к базе (путь к файлу 1Cv8.1CD) были абсолютно идентичными. Нажмем «Опубликовать».DefaultAppPool. Чтобы добиться изоляции процессов, выполним следующие действия:
1C_Pool_Base и 1C_Pool_Trade.base и trade).Выясним, что именно управляет соединением. В каждой из папок публикаций лежит файл default.vrd. Это XML-документ, в котором прописана строка соединения. Проанализируем его содержимое:
<?xml version="1.0" encoding="UTF-8"?>
<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="/trade"
ib="File="D:\Bases\TradeBase";">
<standardOdata enable="false"/>
</point>
Обратите внимание на параметр ib. Даже если публикации разные, они должны указывать на один и тот же путь к файлу базы данных. Благодаря разделению процессов на уровне IIS, мы получаем «многопоточность» для доступа к файлу, хотя сам файл 1Cv8.1CD все равно будет использовать внутренние механизмы блокировок (файл 1Cv8.lcl или 1Cv8.ldb).
При использовании такой схемы, особенно с базами большого объема (например, 35 Гб, как упоминалось в обсуждении), стандартных настроек IIS может быть недостаточно. Рассмотрим дополнительные параметры пулов приложений, которые необходимо изменить:
1. Тайм-аут простоя (Idle Time-out). По умолчанию IIS завершает рабочий процесс, если к нему никто не обращался в течение 20 минут. Это приведет к тому, что первый пользователь, зашедший после перерыва, будет долго ждать запуска процесса. Рекомендуем установить значение 0, что означает отсутствие тайм-аута.
2. Режим запуска (Start Mode). В дополнительных параметрах пула приложений установим значение AlwaysRunning. Это гарантирует, что процессы w3wp.exe будут запущены сразу после старта сервера, не дожидаясь первого обращения пользователя.
3. Переработка (Recycling). Файловая 1С при работе через веб-сервер может постепенно накапливать утечки памяти в рабочем процессе. Проанализируем график нагрузки и настроим ежедневную переработку пула в ночное время (например, в 03:00). Это позволит «освежать» процессы без вреда для пользователей.
Важно понимать, что разделение на пулы в IIS — это «терапевтическая» мера. Если база имеет размер 35 Гб, это критический показатель для файлового режима — её размер можно снизить через перенос файлов из базы 1С в тома на диске. Разберем, почему это опасно:
1Cv8.1CD размер одной таблицы не может превышать 4 Гб (в некоторых версиях формата — больше, но риски сохраняются). При достижении этого лимита база просто перестанет записывать данные.Рекомендация: Для баз такого объема и количества пользователей более 5–10 человек единственным стабильным решением является переход на клиент-серверный вариант (MS SQL, PostgreSQL). Публикация на IIS в этом случае также станет работать значительно быстрее и стабильнее, так как нагрузку по обработке данных возьмет на себя СУБД.
Подведем итог: разделение одной базы на две публикации /base и /trade с разными пулами приложений — это грамотный ход для оптимизации работы именно файловой базы. Это позволяет:
Однако помните, что данная настройка не отменяет необходимости регулярного обслуживания базы (сжатие таблиц, обновление индексов) и не заменяет полноценный SQL-сервер при достижении базой больших объемов.