HighLoad-тестирование 1С: зачем нужно и когда

HighLoad-тестирование 1С — это проверка базы под нагрузкой, близкой к реальной: десятки и сотни одновременных пользователей, пиковые операции закрытия периода, массовое проведение документов. Тест показывает, где именно система упрётся в потолок — в сервер, в код или в архитектуру, — до того как это произойдёт в бою, на глазах у бухгалтерии и склада.

Почему возникает деградация 1С под нагрузкой

На 40 пользователях база виснет ровно в девять утра, когда бухгалтерия открывает месяц, а склад параллельно закрывает ночную смену отгрузок. Полгода назад та же конфигурация на тех же 40 пользователях работала ровно. Но штат вырос на десять человек, ассортимент — в три раза, а сервер остался прежним. Поэтому нагрузка, которая раньше растворялась в свободных ресурсах сервера, теперь упирается в лимит — процессора, диска или блокировок СУБД, и не так важно, что назвать причиной первым.

Отчёт вида «всё работает медленно» ничего не говорит о настоящей причине. Тормозить может диск сервера — не хватает IOPS под пиковую запись, может не хватать памяти кластеру серверов 1С, может тормозить один неоптимальный запрос в отчёте, который раньше выполнялся по 5 записям, а теперь по 50 000. Или всё проще: два бухгалтера одновременно проводят документы по одному контрагенту и держат друг друга в очереди блокировки.

Похожая картина у розницы и оптовой торговли: кассы или менеджеры одновременно бьют чеки и выставляют счета в час пик, а фоновое обновление регистра цен или пересчёт остатков забирает ресурсы сервера именно в этот момент. Пользователь не видит фонового процесса — он видит только зависший интерфейс и растущую очередь клиентов у кассы.

Ставка здесь не абстрактная. Зависшая база в момент закрытия месяца — это не раздражение бухгалтерии, а несданная вовремя отчётность, штраф от контролирующих органов, отгрузки, которые не ушли клиенту до конца дня, и склад, который встал на два часа в самую горячую смену. Для среднего бизнеса в Москве два часа простоя склада в сезон — это упущенные заявки на сумму, которая окупает нагрузочное тестирование на год вперёд.

Как исправить проблему: из чего состоит HighLoad-тестирование 1С

Чинить наугад — значит менять железо, конфигурацию или код методом проб и надеяться попасть в причину с первого раза. HighLoad-тестирование убирает угадывание: нагрузку эмулируют специализированными инструментами вроде Vanessa Automation или встроенных средств замера производительности платформы, записывают метрики APDEX, время отклика по ключевым операциям, загрузку процессора и диска отдельно на сервере СУБД и на сервере приложений — и смотрят, где график производительности ломается первым.

Сценарий теста строят не абстрактно, а по реальному профилю базы: сколько пользователей одновременно проводят документы утром, сколько формируют отчёты в течение дня, когда запускается регламентное задание пересчёта итогов. Обычно тест занимает от одного до трёх рабочих дней вместе с подготовкой тестового контура — прогонять нагрузку на боевой базе никто не станет, чтобы не положить её раньше времени.

Тест Гилёва и полноценный HighLoad-тест — не одно и то же

Тест Гилёва (TPC) — быстрый способ прогнать типовую операцию и получить условную оценку производительности сервера в баллах. Он хорош как первичная диагностика: за 15-20 минут показывает, тянет ли текущее железо конфигурацию в принципе. Но это синтетика на одном пользователе — она не показывает, что происходит с блокировками объектов, когда документы одновременно проводят 60 человек. Полноценный HighLoad-тест эмулирует именно многопользовательскую нагрузку, поэтому вскрывает проблемы, которые тест Гилёва физически не видит.

По итогам мы получаем не общий вывод «сервер слабый», а конкретный список: какой запрос отчёта съедает 40% времени операции, где не хватает индекса в базе данных, какая роль в разграничении прав создаёт лишние блокировки. Дальше — точечная доработка: переписать запрос, добавить индекс, изменить логику проведения документа. Такую работу закрывает доработка 1С в рамках отдельного этапа, а настройку и сопровождение сервера после теста — сисадмин по тарифу 3800 руб/час.

Что делать, если ошибка повторяется после оптимизации

Бывает так: индекс добавили, запрос переписали, тормоза ушли — а через полтора месяца база снова виснет в тот же час. Обычно это значит, что оптимизация закрыла симптом, а не причину: ускорили конкретный отчёт, но нагрузка тем временем выросла ещё на 15% — новый склад, новый филиал, — и упёрлись в тот же потолок железа чуть позже.

Если ошибка повторяется, первым делом сравнивают не код, а тренд: технологический журнал за месяц до доработки и после. Часто выясняется, что причина не в одном узком месте, а в архитектуре — например, база растёт быстрее, чем планировали, и хранение временных таблиц уже не помещается в оперативную память сервера. Косметическая доработка здесь не спасёт: нужен апгрейд конфигурации сервера с оглядкой на актуальные системные требования 1С, а иногда и пересмотр логики работы конкретного участка.

Второй частый сценарий — повторный тест показывает, что проблема сдвинулась, а не исчезла: раньше упирались в диск, после апгрейда упёрлись в лицензии одновременных подключений или в блокировки конкретного регистра. Здесь помогает не разовая правка, а цикл: тест → диагноз → доработка → контрольный тест по той же методике, чтобы сравнивать метрики, а не ощущения пользователей.

Третий сценарий встречается у компаний с самописными или сильно доработанными конфигурациями: проблема действительно устранена в одном модуле, но всплывает в соседнем, потому что оба используют один и тот же общий регистр или один и тот же фоновый обработчик. В таких случаях повторный тест обязательно захватывает не только проблемный участок, а весь суточный цикл базы — иначе следующая жалоба придёт через месяц с той же формулировкой.

Как предотвратить деградацию 1С при росте бизнеса

Предотвратить дешевле, чем тушить. Правило простое: нагрузочный тест делают не после того, как база легла в пиковый день, а перед событиями, которые предсказуемо поднимают нагрузку.

• ✓сезонный пик продаж или подготовка к инвентаризации;
• ✓подключение нового филиала или магазина к общей базе;
• ✓переход на 1С:Управление торговлей или другую конфигурацию с бóльшим документооборотом;
• ✓рост штата больше чем на 20-30% за квартал.

Рабочий регламент для среднего бизнеса — контрольный HighLoad-тест раз в год плюс внеплановый прогон перед любым событием, которое меняет профиль нагрузки. Отдельно держат постоянный мониторинг технологического журнала и APDEX, чтобы заметить деградацию за недели до того, как она станет заметна пользователям, а не в момент, когда бухгалтерия уже пишет в поддержку.

Отдельная история — конфигурации, которые давно не обновляли. Устаревшая платформа часто не умеет того, что умеет свежий релиз: нормальную оптимизацию запросов, работу с индексами, параллельное выполнение фоновых заданий. Если база последний раз обновлялась два-три релиза назад, часть проблем с производительностью снимается через обновление 1С — раньше, чем через покупку нового сервера.

Полезная привычка — держать план нагрузки на бумаге: сколько пользователей сейчас, сколько ожидается через год, какой документооборот планируется после запуска новой точки продаж. Такой план превращает нагрузочное тестирование из разовой пожарной меры в обычный пункт бюджета на ИТ, наравне с лицензиями и сопровождением.

Сколько стоит нагрузочное тестирование 1С и что входит в услугу

Стоимость теста зависит от размера базы, числа эмулируемых пользователей и того, нужен ли контрольный прогон после доработки. Ориентир по частым сценариям — в таблице: она собрана по симптомам, с которыми к нам обращаются компании из Москвы и области.

По итогам теста заказчик получает отчёт с графиками нагрузки, узкими местами и приоритизированным списком правок — что даёт наибольший эффект при наименьших затратах. Это отдельная точка принятия решения: часть компаний ограничивается настройкой сервера, часть заказывает доработку кода, часть решает, что дешевле пересмотреть архитектуру, чем латать текущую.

Если по итогам теста нужна доработка кода или архитектуры — это доработка 1С, стоимость считается по объёму правок. Если тест показывает, что типовая конфигурация выросла из размера бизнеса и упирается в архитектурный потолок, есть смысл смотреть в сторону внедрения 1С:ERP — она рассчитана на нагрузку, для которой обычная УТ или Бухгалтерия не проектировались.

Для компании, которая ещё не сталкивалась с зависаниями, но растёт быстрее плана, разумный шаг — не ждать сбоя, а встроить нагрузочный тест в проект внедрения 1С ещё на этапе настройки: тогда сервер и конфигурация рассчитаны на нагрузку через год, а не на нагрузку сегодняшнего дня.

❓ Частые вопросы

Чем HighLoad-тестирование отличается от теста Гилёва?

Тест Гилёва — быстрая синтетическая проверка на одном пользователе, за 15-20 минут показывает потенциал сервера. HighLoad-тест эмулирует десятки и сотни реальных пользователей одновременно и вскрывает блокировки, конфликты записи и узкие места в коде, которые синтетическая проверка не видит в принципе.

Сколько времени занимает нагрузочное тестирование базы 1С?

Обычно от одного до трёх рабочих дней вместе с подготовкой тестового контура и сценария нагрузки под реальный профиль базы. Сама нагрузка прогоняется не на боевой базе, а на её копии, поэтому пользователи продолжают работать в обычном режиме без простоя и риска для данных.

Нужно ли останавливать работу базы на время теста?

Нет. Тест выполняют на копии базы в отдельном тестовом контуре, идентичном по конфигурации боевому серверу и объёму данных. Пользователи в это время продолжают работать как обычно, а результаты и рекомендации переносят на продуктивную базу только после согласования конкретных изменений с заказчиком.

Как часто нужно повторять нагрузочное тестирование?

Раз в год как плановую проверку, плюс внепланово — перед событиями, которые заведомо поднимают нагрузку: сезонный пик продаж, подключение нового филиала к общей базе, переход на другую конфигурацию, рост штата больше чем на 20-30% за квартал или подготовка к инвентаризации.

Что делать, если после теста и доработки скорость не выросла?

Значит, оптимизация закрыла симптом, а не причину. Нужен повторный тест по той же методике со сравнением метрик до и после доработки — часто проблема оказывается в архитектуре базы или в другом узком месте, которое раньше маскировалось первым по очереди сбоем.