Содержание:

1. Проектирование модели данных при работе в системе 1С — фундамент всему
2. Ориентация на пакетную организацию процессов при использовании программы 1С:Предприятие
3. Как управлять блокировками для эффективной работы
4. Описание клиент-серверной архитектуры системы
5. Проектирование с учётом перспективных тенденций в системе 1C:Предприятие

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

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

Проектирование модели данных при работе в системе 1С — фундамент всему

Неправильно спроектированная структура данных — это трещина в фундаменте. Как бы вы ни старались, дом, построенный на нем, всегда будет шатким.

• Правильный выбор типа объекта: Не используйте справочник там, где нужен регистр сведений. Если вам нужно хранить исторические данные (например, цены, курсы валют, ответственных лиц), используйте периодический регистр сведений. Попытка «изобрести» историю в справочнике с помощью дополнительных реквизитов — прямой путь к сложным и медленным запросам.
• Использование ведущих измерений: В регистрах сведений и накопления всегда задумывайтесь о том, какие измерения будут ведущими. Платформа физически группирует данные по ведущим измерениям, что кардинально ускоряет получение срезов и работу механизма RLS (ограничение прав на уровне записей). Например, в регистре остатков товаров измерение «Номенклатура» почти всегда должно быть ведущим.
• Осторожность с неограниченными типами: Реквизиты типа «Строка неограниченной длины» и, особенно, «Хранилище значения» — это мощные, но очень «тяжелые» инструменты. СУБД хранит их отдельно от основной таблицы, и каждое обращение к такому полю — это дополнительная дорогостоящая операция. Используйте их только тогда, когда это абсолютно необходимо. Никогда не включайте такие поля в запросы без крайней нужды.

Ориентация на пакетную организацию процессов при использовании программы 1С:Предприятие

Это золотое правило производительности в 1С. Проблема «N+1 запросов», когда внутри цикла по результатам одного запроса выполняется еще один, — главный «убийца» производительности.

Плохая практика (запрос в цикле):

ВыборкаДокументов = Запрос.Выполнить().Выбрать();

Пока ВыборкаДокументов.Следующий() Цикл

    // Для каждого документа отдельным запросом получаем его сумму

    Сумма = ОбщегоНазначения.РассчитатьСуммуДокумента(ВыборкаДокументов.Ссылка);

    Сообщить(Сумма);

КонецЦикла;

Хорошая практика (пакетный запрос):

Запрос = Новый Запрос;

Запрос.Текст =

    “ВЫБРАТЬ

    |    Продажи.Ссылка,

    |    СУММА(Продажи.Товары.Сумма) КАК СуммаДокумента

    |ИЗ

    |    Документ.РеализацияТоваровУслуг КАК Продажи

    |СГРУППИРОВАТЬ ПО

    |    Продажи.Ссылка”;

Результат = Запрос.Выполнить().Выбрать();

// … дальнейшая обработка уже готовых

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

Как управлять блокировками для эффективной работы

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

• Транзакции должны быть короткими. Вся интерактивная работа с пользователем (вопросы, диалоги) должна происходить до открытия транзакции. Транзакция должна содержать только запись данных в базу и ничего лишнего.
• Используйте управляемый режим блокировок. Для сложных операций проведения, затрагивающих несколько регистров, режим автоматических блокировок часто бывает избыточным и неэффективным. Изучите и применяйте управляемые блокировки. Это позволит вам явно указать платформе, какие именно данные нужно заблокировать, минимизируя время простоя для других пользователей.

Описание клиент-серверной архитектуры системы

В архитектуре «клиент-сервер» каждый должен заниматься своим делом. Передача больших объемов данных между сервером и клиентом — одна из главных причин «задумчивости» интерфейса.

• Никогда не передавайте на клиент лишние данные. Если пользователю нужно видеть на форме 10 колонок из 100, запрос должен возвращать только эти 10 колонок.
• Все вычисления — на сервере. Не получайте на клиент таблицу данных, чтобы потом в цикле что-то посчитать. Сделайте это в запросе на сервере и верните клиенту только итоговый результат.
• Используйте динамические списки. Для отображения больших объемов данных в формах списков используйте объект «ДинамическийСписок». Он загружает данные порционно и умеет эффективно выполнять отборы на стороне СУБД, а не на клиенте.

Проектирование с учётом перспективных тенденций в системе 1C:Предприятие

Система, которая «летает» на тестовой базе со 100 документами, может полностью «встать», когда в ней будет 10 миллионов записей. Всегда задавайте себе вопрос: «А как это будет работать через 3 года?».

• Индексируй заранее: При создании регистров и справочников сразу продумывайте, по каким полям чаще всего будет идти поиск, и устанавливайте для них свойство Индексировать.
• Планируй архивацию: Если вы проектируете систему с интенсивным накоплением данных (например, логов, записей о действиях), сразу закладывайте механизм архивации или свертки старых данных.

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

Специалист компании ООО “Кодерлайн”,

Радченко Степан