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

← На главную

Разница в скорости выполнения операций между пользователем с полными правами и обычным сотрудником — классическая проблема при администрировании 1С. В данной статье мы разберем, почему возникает такой дисбаланс, как выявить «узкие места» в коде и что сделать, чтобы система перестала тормозить.

Шаг 1. Проверяем механизмы ограничения доступа (RLS)

Одной из наиболее частых причин медленной работы является RLS (ограничение доступа на уровне записей). Для администратора с полными правами эти проверки игнорируются, тогда как для рядового пользователя система при каждом чтении данных проверяет право доступа к конкретному объекту.

Чтобы исключить влияние RLS, выполните следующие действия:

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

Также важно обратить внимание на целостность системы доступа. Если при обновлении ключей доступа вы получаете ошибку (например, Невозможно обновить ключ доступа объекта), это свидетельствует о «битой» структуре метаданных. Убедитесь, что все пользовательские документы добавлены в определяемые типы, которые используются механизмом RLS. Игнорирование этой ошибки приводит к тому, что фоновые задания по пересчету прав зависают, создавая избыточную нагрузку на сервер.

Шаг 2. Анализируем код на наличие ошибок производительности

Даже если права настроены корректно, сам алгоритм обработки может содержать «бутылочные горлышки». Рассмотрим представленный в теме запрос. Первая ошибка — использование функции ТекущаяДата() в качестве параметра периода для виртуальной таблицы Остатки(&Дата, ).

Использование ТекущаяДата() заставляет СУБД каждый раз пересчитывать план выполнения запроса, так как параметр является динамическим. Для получения остатков на текущий момент правильнее передавать значение НЕОПРЕДЕЛЕНО или вообще исключить параметр периода, если он не требуется. Это позволит 1С более эффективно работать с кэшированием планов запросов в SQL.

Шаг 3. Оптимизируем структуру запроса

Рассмотрим, как можно переписать сложный запрос для повышения скорости работы. Вместо использования тяжелых вложенных соединений, мы можем объединить данные более элегантно. Проанализируем пример оптимизированного запроса:


ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
    СУММА(ТоварыНаСкладахОстатки.ВНаличииОстаток) КАК ВНаличииОстаток,
    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена,
    ЕСТЬNULL(НоменклатураДополнительныеРеквизиты.Значение, "") КАК ЗначениеСвойства
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки(&Дата, ) КАК ТоварыНаСкладахОстатки
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних
        ПО ТоварыНаСкладахОстатки.Номенклатура = ЦеныНоменклатурыСрезПоследних.Номенклатура
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК НоменклатураДополнительныеРеквизиты
        ПО ТоварыНаСкладахОстатки.Номенклатура = НоменклатураДополнительныеРеквизиты.Ссылка
            И (НоменклатураДополнительныеРеквизиты.Свойство = &Свойство)
СГРУППИРОВАТЬ ПО
    ТоварыНаСкладахОстатки.Номенклатура,
    ЦеныНоменклатурыСрезПоследних.Цена,
    ЕСТЬNULL(НоменклатураДополнительныеРеквизиты.Значение, "")

Что изменилось в этом подходе:

Мы избавились от избыточных вложенных запросов, которые усложняли чтение и выполнение плана СУБД.
Использование ЛЕВОЕ СОЕДИНЕНИЕ напрямую с виртуальной таблицей остатков позволяет СУБД быстрее сопоставить данные, если правильно настроены индексы.
Применение ЕСТЬNULL помогает избежать лишних проверок на этапе формирования выборки в коде 1С.

Шаг 4. Рекомендации по отладке

Чтобы окончательно локализовать проблему, используйте Замер производительности в конфигураторе. Запустите его под обоими пользователями и сравните количество вызовов и время исполнения конкретных строк кода. Если в отладке видно, что основной «вес» приходится на обращение к объектам через точку (например, Выборка.Номенклатура.Родитель), это сигнал к тому, что нужно переносить получение этих данных непосредственно в запрос.

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

Подводя итог, разница в скорости работы пользователей в 1С УТ 11 обычно кроется либо в неоптимальных настройках RLS (или ошибках в их метаданных), либо в «кривом» запросе, который SQL-сервер не может эффективно кэшировать из-за использования динамических параметров. Последовательная оптимизация запроса и проверка прав доступа помогут вам уравнять производительность для всех групп пользователей.