При планировании внедрения крупной системы на базе 1С:Предприятие или при масштабировании текущей инфраструктуры неизбежно возникает вопрос: выдержит ли сервер заданную нагрузку? Нагрузочное тестирование — это не просто запуск скрипта, а комплекс мероприятий, направленных на выявление "бутылочных горлышек" в связке железа, сети и настроек СУБД. Разберем подробно, какими инструментами и методиками следует пользоваться, чтобы увидеть реальную картину производительности.
Прежде всего, проанализируем ситуацию с выбором подхода. Существует два основных пути:
Рассмотрим пошагово каждый из инструментов, предложенных экспертами.
Для систем на базе 1С:ERP или Комплексной автоматизации наиболее эффективным является использование встроенного "Тест-центра". Это подсистема, которая позволяет автоматизировать выполнение многопользовательских сценариев. Выясним причину, почему этот инструмент считается приоритетным: он учитывает не только нагрузку на SQL, но и работу сервера приложений 1С, а также все блокировки на уровне метаданных.
Разберем алгоритм работы с Тест-центром:
Если задача стоит проверить именно СУБД в отрыве от логики 1С, рассмотрим подробнее утилиту HammerDB. Это индустриальный стандарт для тестирования транзакционной нагрузки (TPC-C). Она позволяет создать нагрузку в сотни и тысячи потоков, имитируя работу с базой данных.
Проанализируем преимущества HammerDB: инструмент показывает количество транзакций в минуту (TPM) и позволяет увидеть момент, когда добавление новых пользователей перестает увеличивать производительность и начинает её деградировать из-за очередей к ресурсам или блокировок. Однако, важно помнить, что HammerDB тестирует SQL-сервер в целом, и результаты могут отличаться от специфических запросов 1С.
Многие администраторы начинают с теста Гилева. Разберем по шагам его особенности. Это отличный инструмент для быстрой оценки "скорости одного потока" (однопоточной производительности процессора и дисков). Но, как справедливо отмечено в обсуждении, он практически не нагружает MS SQL Server в многопользовательском режиме. Он покажет вам определенное количество "попугаев", что полезно для сравнения двух разных серверов между собой, но не ответит на вопрос: "выдержит ли сервер 1000 пользователей?".
Часто слабым звеном оказывается именно дисковый массив. Для его проверки рекомендуется использовать утилиту Diskspd. Рассмотрим пример команды для имитации нагрузки, типичной для SQL Server (чтение и запись блоками по 8 Кб в несколько потоков):
diskspd.exe -b8K -d60 -h -L -o32 -t8 -r -w25 -c1G testfile.dat
В этой команде мы задаем размер блока 8K, 25% записей (остальное чтение) и глубину очереди. Если задержка (latency) при таком тесте превышает 20 мс, значит, диски станут "бутылочным горлышком" еще до того, как SQL Server выйдет на полную мощность.
Во время проведения любого теста необходимо отслеживать состояние системы через системный монитор (PerfMon). Выделим критически важные показатели:
Прежде чем делать выводы о "слабом железе", проверим настройки, которые могут искусственно занижать результаты тестов:
Max Degree of Parallelism в значение 1 или в соответствии с количеством ядер в одном NUMA-узле.Max Server Memory), чтобы ОС не начинала использовать файл подкачки.Подведем итог: наиболее надежный способ протестировать связку 1С и MS SQL — это комплексный подход. Начните с теста Diskspd для проверки дисков, затем проведите замеры тестом Гилева для оценки процессора, и завершите полноценным нагрузочным тестированием через ERP Тест-центр для имитации реальной работы пользователей. Только так вы сможете гарантировать стабильную работу системы под нагрузкой.