Масштабирование системы 1С для работы нескольких сотен и тем более тысячи активных пользователей — это сложная инженерная задача, где простого наращивания количества ядер процессора недостаточно. При работе с Управляемыми формами архитектурные требования существенно меняются по сравнению с классическими решениями. Разберем подробно, как правильно спроектировать серверную инфраструктуру, чтобы избежать деградации производительности при росте нагрузки.
Проанализируем типичную ошибку при выборе серверного железа: покупку многопроцессорных систем с низкой тактовой частотой (например, Xeon 2.1–2.4 ГГц). Для 1С критически важна производительность на одно ядро (Single-core performance). Это связано с тем, что многие операции в 1С выполняются последовательно в рамках одного потока.
Рассмотрим рекомендации экспертов:
rphost эффективно использует доступные ядра, но при большом количестве пользователей (400+) нагрузка на контекстные переключения процессора возрастает. Оптимально использовать современные процессоры с 8–16 быстрыми ядрами на один сокет.Пример расчета лимита соединений для балансировки нагрузки:
ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений / (КоличествоNUMAНод * Коэффициент);
// Где коэффициент обычно равен 1 или 2 в зависимости от интенсивности работы.
Посмотрим на дисковую подсистему. В современных высоконагруженных базах 1С использование классических жестких дисков (даже 15k SAS) в RAID10 для хранения рабочих данных — это путь к очередям диска и зависаниям. Проанализируем современный стек технологий:
TempDB и кэшем сервера 1С использование NVMe предпочтительнее из-за крайне низких задержек (latency).TempDB SQL-сервера и кэш сервера 1С.Для базы в 500 Гб и 400+ пользователей стандартных настроек SQL «из коробки» будет недостаточно. Проанализируем ключевые параметры:
MAXDOP = 1. Это гарантирует, что один тяжелый запрос не парализует все ядра процессора. В редких случаях на очень мощных CPU можно пробовать значение 2 или 4, но только после нагрузочного тестирования.TempDB, равное количеству ядер процессора (но не более 8), и устанавливаем их на самый быстрый SSD/NVMe в системе.Разберем ситуацию с доставкой приложения пользователям. В теме часто звучит вопрос: «RDP или веб-публикация?». Для Управляемых форм ответ однозначен:
Тонкий клиент через веб-сервер (IIS или Apache) по протоколу HTTP/HTTPS является приоритетным. Рассмотрим преимущества:
Важный момент: если разработчики жалуются на «глюки» веб-сервера, это часто связано с неправильной настройкой таймаутов или использованием устаревших методов в коде конфигурации (избыточные вызовы сервера). Проанализируем настройки публикации и убедимся, что включено сжатие и используются 64-битные модули расширения веб-сервера.
Когда количество пользователей переваливает за 500, пора переходить от одного сервера 1С к полноценному кластеру. Разберем, как распределить роли:
rphost. При 1000 пользователях лучше иметь 2–3 рабочих сервера, чтобы распределить нагрузку.Не забудем про Shared Memory. Если сервер 1С и SQL-сервер находятся на одной физической машине, использование протокола Shared Memory значительно ускоряет обмен данными по сравнению с TCP/IP. Однако при 1000 пользователей мощностей одного физического сервера может не хватить, и придется разделять их на разные узлы, соединенные 10-гигабитной сетью.
На основе анализа темы и лучших практик, предложим следующую схему:
Сервер СУБД (SQL): 2 процессора с частотой от 3.0 GHz (например, Gold серия), 384 GB RAM, диски NVMe под базу и TempDB.
Сервер 1С: 2 процессора с максимально возможной частотой (важнее ядер), 128-256 GB RAM, SSD под кэш и логи.
Клиентская часть: Тонкий клиент 1С, установленный на рабочие места, подключение через HTTPS к публикации на IIS/Apache.
Помните, что покупка дорогого железа — это лишь половина успеха. Без регулярного аудита технологического журнала, оптимизации индексов и контроля качества кода конфигурации даже самый мощный сервер со временем начнет «тормозить».