Каждый раз, когда перед архитектором или разработчиком высоконагруженных систем встает задача автоматизации крупного предприятия с числом одновременно работающих пользователей свыше 1000 человек, возникает закономерный вопрос: справится ли выбранная платформа? Ситуация усложняется, когда в качестве основного интерфейса планируется использовать веб-клиент 1С, а сама конфигурация является полностью самописной. В рамках данной статьи мы подробно разберем, какие технологические вызовы стоят перед такой системой, развеем популярные мифы о блокировках СУБД, детально рассмотрим вопросы лицензирования, а также дадим практические рекомендации по проектированию серверной инфраструктуры и оптимизации кода 1С.
Для начала разберем главный вопрос: способна ли в принципе платформа «1С:Предприятие 8.3» выдержать нагрузку в 1000–1500 одновременно работающих пользователей? Практика крупных внедрений и официальные нагрузочные тесты фирмы «1С» доказывают, что этот рубеж давно пройден.
Рассмотрим конкретные цифры. Современная платформа регулярно проходит корпоративные испытания на сверхнагрузки:
Таким образом, сама платформа обладает колоссальным запасом масштабируемости. Однако важно понимать, что при такой нагрузке на первый план выходит не поведение самой платформы «из коробки», а качество архитектуры вашего прикладного решения и глубина оптимизации кода. Если конфигурация написана без учета стандартов разработки высоконагруженных систем, база начнет зависать даже при 50 пользователях.
Среди разработчиков, не имеющих опыта работы с высоконагруженными базами данных, бытует мнение, что при одновременной записи множества элементов в один справочник или документ СУБД (например, MS SQL Server) неминуемо заблокирует всю таблицу целиком. Выясним причину этого заблуждения и разберем реальные механизмы работы современных СУБД под управлением 1С.
Рассмотрим, почему при массовом создании новых записей (операция INSERT) в современных базах 1С табличные блокировки отсутствуют:
IDENTITY в MS SQL), где СУБД вынуждена блокировать индекс для вычисления следующего порядкового номера.Проанализируем ситуации, когда блокировка всей таблицы (Table Lock) все же может произойти:
Рассмотрим пример правильного наложения управляемой блокировки в коде 1С при записи критически важных данных:
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.Взаиморасчеты");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Организация", ВыбОрганизация);
Блокировка.Заблокировать();
Использование такого подхода гарантирует, что параллельные транзакции по другим организациям будут выполняться СУБД абсолютно независимо и одновременно.
При проектировании системы на 1000+ пользователей критически важным становится вопрос бюджета на лицензии 1С. Нередко возникает идея сэкономить: создать промежуточную базу или веб-сайт (например, на PHP/MySQL), через который пользователи будут вводить данные, а специальный робот под одной сессией будет переносить их в 1С. Разберем, почему такая схема является нарушением лицензионной политики.
Согласно официальному регламенту фирмы «1С», в отношении клиентских лицензий действует **правило мультиплексирования**. Оно гласит: использование технических средств (включая веб-серверы, серверы приложений, пулы соединений и СУБД), которые уменьшают количество пользователей, напрямую или косвенно обращающихся к данным 1С, не уменьшает потребность в лицензиях.
Рассмотрим две схемы интеграции с внешними системами:
Использование веб-клиента 1С в качестве основного рабочего интерфейса для 1500 пользователей накладывает жесткие требования к архитектуре публикации базы данных. Посмотрим, с какими неочевидными проблемами мы можем столкнуться при эксплуатации такой системы.
Первая серьезная проблема веб-клиента — это поведение пользователей в браузере. Если пользователь сталкивается с задержкой интерфейса, его первой реакцией будет нажатие клавиши обновления страницы (F5) или закрытие вкладки браузера. Разберем, к чему это приводит на сервере:
Для минимизации этого эффекта проанализируем настройки параметров кластера серверов 1С. В консоли администрирования кластера необходимо установить жесткие лимиты для спящих сеансов:
ВремяЖизниСпящегоСеанса рекомендуется сократить до 120–300 секунд (2–5 минут).ВремяЗавершенияСпящегоСеанса установить на аналогичный минимальный интервал.Вторая технологическая задача — это правильное построение веб-фермы. Никогда не публикуйте базу для 1000+ пользователей на одном стандартном веб-сервере Apache или IIS под управлением Windows. Рассмотрим рекомендуемую отказоустойчивую архитектуру публикации:
Обсуждая аппаратные требования для 1000+ пользователей, особое внимание уделим дисковой подсистеме сервера СУБД. В исходном обсуждении упоминался выбор между RAID 0+1 и другими конфигурациями. Разберем этот вопрос с точки зрения надежности и производительности транзакционных баз данных (OLTP).
Для систем с интенсивной записью критически важна скорость работы дисков на случайные операции записи (IOPS). Использование обычных жестких дисков (HDD) полностью исключено. Нам понадобятся только твердотельные накопители класса Enterprise SSD (NVMe или SAS).
Рассмотрим особенности выбора RAID-массива под СУБД:
Важное примечание: При выборе SSD дисков для СУБД обращайте внимание на показатель износостойкости DWPD (Drive Writes Per Day) и наличие аппаратной защиты от потери питания (PLP - Power Loss Protection). Обычные пользовательские SSD быстро выйдут из строя из-за выработки ресурса ячеек памяти и могут потерять кэш данных при аварийном отключении электричества.
Чтобы самописная финансовая система стабильно работала при 1500 пользователях, рассмотрим базовые правила написания кода, которые необходимо внедрить на проекте с первого дня разработки:
1. Отказ от тяжелых запросов в транзакциях. Все расчеты должны производиться *до* начала транзакции записи. Транзакция должна быть максимально короткой: открыли, быстро записали подготовленный набор данных, закрыли.
2. Разделение нагрузки через фоновые задания. Если пользователю необходимо сформировать сложный финансовый отчет или провести тяжелый расчет, это действие ни в коем случае не должно выполняться в основном сеансе. Передавайте такие задачи в фоновые задания. Посмотрим на пример вызова фонового задания из формы веб-клиента:
ПараметрыЗапуска = Новый Массив;
ПараметрыЗапуска.Добавить(ПараметрыДокумента);
ФоновыеЗадания.Выполнить("МодульПроведения.ВыполнитьПроведениеВФоне", ПараметрыЗапуска);
Пользователь в веб-клиенте продолжает комфортно работать с интерфейсом, пока сервер выполняет тяжелые вычисления в фоновом потоке, а результат возвращается по мере готовности через механизм оповещений.
3. Использование разделения итогов для регистров накопления. Если 1000 пользователей одновременно записывают данные, которые обновляют итоги по одному и тому же регистру (например, "Денежные средства"), возникнет очередь ожиданий на блокировках итогов регистра. В свойствах регистра накопления обязательно включайте свойство РазрешитьРазделениеИтогов. Платформа будет записывать итоги с дополнительным внутренним разрезом (номером строки движения), распределяя нагрузку, и объединять их только при чтении.
4. Оптимизация работы с индексами. Любой запрос, используемый в динамических списках или отчетах, должен опираться на существующие индексы СУБД. Регулярно проводите аудит планов запросов и настраивайте технологический журнал 1С для выявления медленных запросов (время выполнения более 1 секунды).
Подводя итог, можно с уверенностью сказать: платформа «1С:Предприятие 8.3» полностью готова к нагрузкам в 1000–1500 пользователей в веб-клиенте. Успех проекта целиком зависит от грамотного администрирования веб-серверов, правильной конфигурации СУБД и профессионализма команды разработчиков, понимающих особенности работы высоконагруженных систем.