Как программно создать большое количество документов для тестирования нагрузки в 1С

В процессе разработки и внедрения информационных систем на платформе 1С:Предприятие часто возникает необходимость проверить, как поведет себя база данных при достижении критических объемов. Особенно это актуально для файловых баз данных (формат .1CD), которые имеют специфические архитектурные ограничения. Рассмотрим, как создать инструмент для генерации тестовых данных и к каким техническим порогам стоит готовиться.

Метод простого копирования документов

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

// Пример простого цикла создания документов
Для Итератор = 1 По 100000 Цикл
    НовыйОбъект = СсылкаНаОбъект.Скопировать();
    НовыйОбъект.Дата = ТекущаяДата(); // Устанавливаем актуальную дату
    НовыйОбъект.Записать();
КонецЦикла;

В данном примере мы берем готовую ссылку на документ (СсылкаНаОбъект), создаем его точную копию методом Скопировать() и записываем в базу. Однако при использовании такого кода в чистом виде вы быстро столкнетесь с низкой скоростью записи, так как каждое обращение к файлу базы данных требует отдельных ресурсов ОС на открытие и закрытие транзакций записи.

Оптимизация записи с помощью транзакций

Чтобы существенно увеличить скорость генерации (в примере автора темы скорость достигла 400 документов в секунду), необходимо использовать механизм транзакций. Проанализируем, почему это важно: при записи вне явной транзакции 1С оборачивает каждый вызов Записать() в отдельную внутреннюю транзакцию. Если же мы объединим группу документов в один блок, количество дисковых операций записи резко сократится.

Рассмотрим модифицированный код с использованием транзакционного пакета:

КоличествоВПакете = 300; // Оптимальный размер для файловой базы
Счетчик = 0;

НачатьТранзакцию();

Для Итератор = 1 По ОбщееКоличество Цикл
    НовыйОбъект = СсылкаНаОбъект.Скопировать();
    НовыйОбъект.Дата = ТекущаяДата();
    НовыйОбъект.Записать();
    
    Счетчик = Счетчик + 1;
    
    // Фиксируем пакет и открываем новую транзакцию
    Если Счетчик >= КоличествоВПакете Тогда
        ЗафиксироватьТранзакцию();
        Счетчик = 0;
        НачатьТранзакцию();
    КонецЕсли;
КонецЦикла;

Если ТранзакцияАктивна() Тогда
    ЗафиксироватьТранзакцию();
КонецЕсли;

Важный нюанс: не стоит делать одну транзакцию на миллион документов. В случае сбоя вся транзакция откатится, а оперативная память может переполниться. Размер пакета в 300–500 объектов является «золотой серединой» для файлового режима.

Технические лимиты файловой базы данных (.1CD)

При проведении подобных экспериментов важно понимать, на каком этапе база данных может «рухнуть». Существует распространенное заблуждение, что предел файловой базы — 4 Гб. Выясним реальное положение дел:

1. Ограничение на размер таблицы: В стандартном режиме (размер страницы 4 Кб) ограничение в 4 Гб накладывается не на весь файл 1Cv8.1CD, а на одну внутреннюю таблицу. Например, таблица самого документа может быть небольшой, но таблица движений по регистрам (индексам) может достичь предела гораздо быстрее.
2. Размер страницы данных: Начиная с версии платформы 8.3.8, при создании базы можно указать размер страницы (8, 16, 32 или 64 Кб). Это позволяет одной таблице разрастаться до 32–64 Гб. Однако стоит помнить, что при увеличении размера страницы падает общая производительность системы.
3. Количество записей: Существует внутреннее ограничение на количество строк в одной таблице, которое для старых форматов составляло около 16 миллионов записей. В современных реалиях этот лимит выше, но производительность начинает деградировать задолго до его достижения.

Почему база начинает тормозить при росте объема

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

Также стоит учитывать следующие факторы:

• Фрагментация файла: При интенсивной записи данных файл базы становится сильно фрагментированным. Рекомендуется регулярно выполнять процедуру «Сжатие таблиц» через конфигуратор или утилиту chdbfl.exe.
• Блокировки: В файловой базе при записи блокируется вся таблица. Если во время работы вашего скрипта в базе попытается работать реальный пользователь, он получит ошибку блокировки.
• Нагрузка на CPU: Как заметили участники обсуждения, процесс генерации данных в 1С обычно нагружает только одно ядро процессора, так как выполнение кода в одном сеансе однопоточное.

Использование готовых инструментов

Если вам требуется не просто «забить место» в базе, а создать корректные связанные данные (справочники, виды субконто, корректные проводки), рекомендуется рассмотреть профессиональные инструменты:

1. Инструменты разработчика (ирТестированиеМетаданных): Специализированные надстройки, такие как ЗаполнитьРеквизитыНепустымиЗначениями(), позволяют автоматически наполнять объекты данными, учитывая типы реквизитов.
2. Типовая обработка «Генерация тестовых данных»: Часто встречается в крупных конфигурациях (ERP, УТ 11). Она позволяет моделировать деятельность предприятия, создавая цепочки документов (Заказ -> Реализация -> Оплата).

Подводя итог, можно сказать, что файловая база 1С способна выдерживать значительные объемы (десятки гигабайт и миллионы документов), если администрирование выполняется грамотно: используются транзакции, контролируется размер таблиц и регулярно проводится обслуживание индексов.