есть база на основе бух-3 в ней есть доп план счетов и все типовые отчеты модернизированы для работы с ним, база работает почти 2 года, размер базы - не большой примерно 7 гигов. База на SQL.

до начала этого месяца отчет за февраль выполнялся менее 2х секунд (котик даже не появлялся), с понедельника этот-же отчет выполняется около 10 секунд.
В этот промежуток больших доработок не накатывали, но перепроводили часть документов задним числом.

есть тестовый сервер, на нем есть 2х недельная копия - там этот же отчет выполняется быстро
на тестовый сервер средствами SQL скопировал рабочую базу - отчет работает медленно (то есть проблема не в сервере)

что пробовал (все на тестовом сервере на копиях)
1. Стандартные - управление итогами, там не видно никаких дат в далеком прошлом или далеком будующем
2. полное ТИИ - результатов нет
3. обновление статистики на SQL - результата нет
4. Дефрагментация и перестроение индексов на SQL - пока идет
5. Профайлер - выдает кучу мелких запросов (порядка 15 тысяч), ни одного длительного там нет
6. RLS - не виновато, все это под полными правами

куда еще копнуть?

что "говорит" замер производительности ?

запросы в цикле

если с железом и сетью порядок, в профайлере нет 10 сек, значит в 1с написан копрокод. смотреть (1) (2)

(1) (2) типовой запрос бух отчетов выполнение через компоновку

на сколько я сейчас смотрю в SQL больше всего времени занимает создание (инсерт) временных таблиц NG, вроде это виртуальные таблицы остатков или подобное...

(4) путаете: создание таблиц NG происходит при реструктуризпции

А по типовому плану счетов какая скорость?

Что с размером темпдб, его приростом, местом на том диске, здоровьем этого диска, очередью к этому диску?

(6) у меня там данных нет
(7) вроде с диском проблем нет, и да сервер перезагружали


сейчас повторил с профайлером отчет с одинаковыми настройками.

старая копия - 96 строк в профайлере (быстро)
свежая копия - 14803 строк в профайлере (медленно)

может кастомное представление кому добавили?

(9) добавляли внешние источники данных, но они в этих отчетах не используются.

нашел причину,

проблема оказалась в куче вызова процедуры заполнения одного хитрого параметра сеанса.

Он должен заполнятся только при запуске 1с, а получилось, что заполняется при вызове отчета.

ну ужто профайлер 1с запускал?

(12) запускал еще в (0), а нашел через историю изменения конфигурации в хранилище, потом трассировкой поддтвердил...

всё оказалось буднично, расходимся

(2) это не грех

(15) кидать в людей камни - плохо

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

Если же выполняется огромное количество однотипных мелких запросов (частотные запросы).
Тогда надо настроить логирование техножурнала на SDBL событие без отсечки по длительности. Далее "Анализ техножурнала (ИР)" поможет свернуть все такие события в одну строку и покажет итог.
Например такое может происходить при получении представлений ссылочных объектов:
https://i.imgur.com/3WTafWW.png

(17) > "Анализ техножурнала (ИР)"
Дядь Сереж, иногда реклама становится навязчивой и прекращает работать из-за разрыва в понятиях эксперта и джуна.

(18) Ну так аргументируй, почему здесь эта информация не к месту. Может действительно я в не в тему написал.

(17) "огромное количество однотипных мелких запросов" для карточки счёта - это очевидно, тут ТЖ не нужен.
Это получается представление документов и субконт.

(20) Как без ТЖ, ты поймешь их общую долю в длительности операции?

(21) ТС с этим справился без техжурнала как-то.

(22) Так вот, повторяюсь, мне не понятно, как он и с чем справился. Это лишь твоя догадка. Только сам топикстартер может прояснить это, если захочет.

(23) я нашел через сравнение трассировки кода (из замеров производительности) на медленной и быстрой базе,

в целом проблема совсем не очевидная:
при запуске отчета запускается отдельный сеанс и выполняется все, что в глобальном модуле "модуль сеанса", туда добавили параметр для RLS, когда добавляли руководствовались соображением, что лишние 8 сек при старте 1с - это допустимо.

Но оказалось, что эти 8 сек добавляются в любое регламентное задание, в том числе и в любой отчет.

Вроде все логично, но уверен, что 99% 1с ников вполне могут вляпаться в это...

Пока переписал заполнение с 8 сек до 1.5 сек, но надо думать системно и мне пока не понятно как это решить...

По идеи наверно можно этот параметр сеанса передавать при запуске отчета и заполнять его из файла, но то-же как то не очень мне нравится, ладно подумаю...

(24) у тебя отчеты формируются регламентом?

Или таки фоновое выполнение делает инициализацию снова?

(26) фоновые

(24) Теперь все понятно.
Эффективным способом поиска тут будет техножурнал по событиям SDBL с группировкой по строкам исходного кода.

Значит просто параметрине ициализировпн до старта отчета.
Сделай чтение параметра в при запуске

Но по идее повторное выполнение должно уже быстро проходить

кстати эта-же херня работает и при поиске в динамическом списке,

кто знает как передать произвольный параметр в процедуру "УстановкаПараметровСеанса()" ????

(31) Там теперь запускаются "системные" фоновые задания. Им тоже нужно корректно RLS использовать в своих внутренних запросах.

что теперь каждого фоновое заново инициализирует параметры?

(33) > теперь
Всегда так было. Фоновое - новый сеанс со всеми вытекающими.

(33) да, я сделал специальный регистр.... и далее

ИспользоватьКеш = (ПолучитьТекущийСеансИнформационнойБазы().ИмяПриложения = "BackgroundJob");

(31) Только через базу или любой другой внешний ресурс, одновременно доступный разным сеансам 1С

(24) 8 секунд на заполнение одного параметра - это постараться надо, не каждый справится;
и его значение точно нужно при запуске, а не при первом использовании?

(35) ИспользоватьКеш  = ПолучитьТекущийСеансИнформационнойБазы().ПолучитьФоновоеЗадание() <> Неопределено;
Так универсальнее

(38) Это дольше, т.к. выполняет обращение к менеджеру кластера (сервису фоновых заданий), и потому в данном случае неоправданно.

(39) Не вижу неоправданной нагрузки. Когда следующий раз начнут тормозить вебсервисы, опять будете героически искать в чем дело?

(40) Включи хотя бы замер производительности и увидишь что разница даже на моем локальном сервере с одним пользователем будет в 10 раз. А уж на нелокальном и 100 раз вполне может быть.
https://i.imgur.com/CmiekP1.png

(41) https://its.1c.ru/db/edtdoc/content/355/hdoc
1с почему то тоже его рекомендуют, возможно другие виды сеанса тоже могут вернуть идентификатор фонового задания, но не уверен.
А по производительности этот код выполняется 1 раз за время работы сеанса, зачем торговать этими десятитысячными секунды?

(42) Это руководство пользователя EDT и там даже не рекомендация, а пример
"Определить тип сеанса можно с помощью методов ПолучитьТекущийСеансИнформационнойБазы() и ПолучитьФоновоеЗадание()."

(43) > пользователя EDT
Я давно подозревал, что 1Сники - не программисты =)

(44) Это пользователи EDT не программисты и походу у них 1С своя, другая
(43) https://its.1c.ru/db/v8317doc#bookmark:dev:TI000000126 расово верный "пример", и хитрец вырвал предложение из контекста "Вызов метода ПолучитьФоновоеЗадание() у полученного объекта позволит однозначно понять, стартует сеанс фонового задания или какой-либо другой сеанс."

(45) Ну и где там написано "рекомендуется"? Опять же описан один из способов.
Вот еще способ:
Проверка значения свойства ИмяПриложения на равенство "BackgroundJob" у полученного объекта позволит однозначно понять, стартует сеанс фонового задания или какой-либо другой сеанс.

Чем твой способ лучше этого в плане надежности?
Я не вижу преимуществ в этом плане. А в плане скорости вижу недостаток. Поэтому для критичного к скорости кода разумнее использовать более быстрый способ.
А какой код критичен к скорости, каждый решает сам.

Проверил на базе с нелокальным сервером приложений. Относительная разница сохранилась. А абсолютная выросла в 10 раз.
https://i.imgur.com/Y8WoYqc.png

(46) Точнее выросла не абсолютная разница, а сама длительность в обоих способах.

Само абсолютное время будет ничтожно в любой значимой операции