При организации работы слабомощных клиентских компьютеров с платформами 1С часто выбирают публикацию информационных баз на веб-сервере (Apache или IIS). В такой архитектуре клиентские ПК работают через тонкий клиент по протоколу HTTP/HTTPS или через веб-браузер, перекладывая всю тяжелую работу по формированию отчетов и вычислениям на веб-сервер. Однако системные администраторы часто сталкиваются с вопросом выбора топологии сети: выносить ли файлы базы данных .1CD на отдельное хранилище или размещать их локально на одной машине с веб-сервером.
Рассмотрим подробно варианты развертывания веб-сервера для файлового варианта 1С 8.3, разберем причины возникновения задержек и выясним, как правильно настроить систему для комфортной работы пользователей.
Проанализируем три основных сценария размещения компонентов информационной базы и веб-сервера:
.1CD расположены локально на одном физическом сервере.Выясним причину, почему первые два варианта показывают неудовлетворительную производительность. При публикации файловой базы модуль расширения 1С загружается непосредственно в адресное пространство процесса веб-сервера (например, w3wp.exe для IIS или httpd.exe для Apache). Веб-сервер берет на себя роль сервера приложений. Если файлы базы находятся на другом узле, модуль веб-сервера вынужден обращаться к файлу .1CD по сетевому протоколу SMB (через расшаренную сетевую папку).
В этом случае пропускная способность сети (100 Мбит/с или 1 Гбит/с) перестает быть главным фактором. Бутылочным горлышком становятся задержки (latency) межпроцессного взаимодействия и постоянная установка сетевых файловых блокировок. При каждом обращении пользователей веб-сервер генерирует множество мелких операций чтения и записи по сети, что приводит к сильному проседанию скорости работы.
Вывод: Вариант 3 (совместное локальное размещение веб-сервера и файлов базы) является единственным технически верным решением среди файловых топологий. Разносить веб-сервер и файлы .1CD по разным машинам категорически не рекомендуется.
Разберем особенность работы веб-сервера с файловыми базами 1С, указанную в документации платформы: при публикации файловой базы запросы пользователей выстраиваются в единую очередь. Почему это происходит?
Файловый движок 1С не является полноценной СУБД. Контроль целостности данных осуществляется путем наложения файловых и табличных блокировок на файл базы. Модуль расширения платформы на веб-сервере вынужден последовательно обрабатывать транзакции на запись, чтобы предотвратить повреждение структуры файла .1CD.
Иногда возникают идеи развернуть несколько независимых процессов веб-сервера (или отдельных пулов приложений) под каждого пользователя. Однако это не решает проблему блокировок: даже если разные процессы веб-сервера обрабатывают HTTP-запросы параллельно, на уровне доступа к файлу .1CD они всё равно упираются в единую блокировку файлового движка 1С. Создавать отдельный веб-сервер под каждого пользователя избыточно и неэффективно.
Чтобы обеспечить максимальное быстродействие 5–6 пользователей, работающих с 2–3 файловыми базами по 1–2 Гб, разберем по шагам следующие технические решения:
.1CD и сам веб-сервер должны размещаться строго на локальном SSD или NVMe-накопителе. Это существенно снижает время ожидания при файловых блокировках.ОбновлениеИндексаППД или автоматические обмены) выполняются в том же процессе веб-сервера, блокируя работу пользователей. Их следует отключить или перенести на ночное время.Если блокировки файлового режима продолжают вызывать задержки при работе нескольких бухгалтеров, проанализируем варианты перехода на клиент-серверную архитектуру: