Главная | Блог | Нагрузочное тестирование 1С: как убедиться, что система выдержит рост бизнеса

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

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

Второй источник нелинейности это объём данных. Запрос, отлично работавший на базе за полгода, на базе за пять лет может сменить план выполнения и читать в разы больше. Со стороны это выглядит как «после обновления всё сломалось», хотя обновление ни при чём.

Поэтому правильный вопрос не «работает ли система», а «при каком объёме и какой одновременной нагрузке она перестанет укладываться в приемлемое время». Ответ даёт только тест.

Ощущения сотрудников к делу не подошьёшь, поэтому производительность переводят в число. В мире 1С прижилась методика APDEX, открытый стандарт, появившийся в 2004 году благодаря альянсу Apdex во главе с Питером Севчиком.

Логика такая. Для каждой ключевой операции задаётся целевое время T: сколько она должна занимать, чтобы человек не испытывал дискомфорта. Замеры делятся на три группы. Уложились в T, это «удовлетворён». От T до 4T, это «терпимо», такие замеры учитываются наполовину. Дольше 4T, это «неудовлетворён», вклад нулевой. Итог считается как доля от единицы: 0,94 и выше означает отличную работу, от 0,85 хорошую, ниже 0,7 систему пора чинить.

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

Отдельно про целевое время. Его назначает не отдел ИТ, а бизнес: это вопрос работы, а не техники, сколько кассир может держать очередь и за сколько менеджер обязан ответить клиенту. У продавца и у годового отчёта нормативы отличаются в разы, и одинаковое число для всех обесценивает метрику.

Что нужно подготовить до запуска теста:

• Список ключевых операций: десять или пятнадцать действий, из которых состоит рабочий день, с целевым временем.
• Копия рабочей базы реального объёма: на демобазе тест не покажет ничего.
• Стенд, повторяющий продуктив по железу, СУБД и настройкам: иначе результаты не переносятся.
• Профиль нагрузки: кто, что и как часто делает за день, включая пики вроде закрытия месяца.
• Критерий приёмки, зафиксированный до начала: какое значение APDEX и на какой нагрузке считается успехом.
• План сбора данных: технологический журнал платформы и счётчики СУБД включаются заранее.

Штатный инструмент для таких испытаний это Тест-центр из «1С:Корпоративный инструментальный пакет». Он позволяет описать многопользовательский сценарий, запустить его автоматически, проконтролировать выполнение и собрать результаты. Нагрузку создают виртуальные пользователи, запущенные на отдельных рабочих местах и управляемые через саму информационную базу.

Масштаб платформы фирма «1С» проверяла публично. В тесте «1С:ERP Управление предприятием» в одной базе одновременно работали 30 000 активных пользователей. Стенд работал на сборке PostgreSQL от 1С под Linux, база занимала около терабайта и содержала порядка 700 тысяч сотрудников, 2,5 миллиона контрагентов и около 10 миллионов документов. За десять часов система выполнила около 885 тысяч ключевых операций с итоговым APDEX 0,858, то есть с оценкой «хорошо».

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

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

Что обычно выявляет тест:

• Конкурентные блокировки на регистрах накопления: несколько операций обращаются к одним и тем же строкам и выстраиваются в очередь.
• Медленные запросы в доработках: соединения с подзапросами, виртуальные таблицы без отбора и запросы в цикле заставляют базу читать лишние данные.
• Регламентные задания в рабочее время: фоновые процессы забирают ресурсы сервера у пользователей.
• Узкие места в дисках и настройках СУБД: при малой нагрузке они незаметны, а в пик тормозят всю систему.
• Взаимоблокировки и таймауты: такие ошибки возникают только при одновременной работе многих пользователей.

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

Нагрузочное тестирование не отменяет мониторинга. Оно отвечает на вопрос «выдержит ли», мониторинг на вопрос «что происходит сейчас». Подсистема «Оценка производительности» из библиотеки стандартных подсистем считает APDEX на рабочей базе постоянно, и это дешевле любого теста.

И последнее: тестирование имеет смысл повторять. Поводы очевидны: плановый рост числа пользователей, крупная доработка, переход на другую СУБД или новую версию платформы, подготовка к сезону. Разовое испытание перед внедрением устаревает вместе с системой.

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