Добрый день. Оптимизирую проведение сложного большого документа (25000 строк). Анализирую скорость проведения с использованием "Замера производительности":
1) Нажимаю кнопку "Замер производительности"
2) Провожу документ
3) Повторно нажимаю "Замер производительности"

В итоге фактически документ проводится 7 минут, а замер производительности показывает 30 секунд
Как такое может быть? Что не учитывается?

Серверная отладка включена?

Потому что на клиенте 25000 строк это овердохера

(1) Да, включена

(2) Это документ Форма ввода бюджета. По нескольким крупным проектам он очень большой

(0) Тестирую в своей тестовой базе, там только один пользователь. Блокировок не должно быть

Ну возможно это время передачи с клиента на сервер и обратно.

(0) "В итоге фактически документ проводится 7 минут, а замер производительности показывает 30 секунд"

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

(7) Есть какие-нибудь советы по оптимизации? Без уменьшения количества строк в ТЧ

Если возникает задача таскать такое количество данных, используй регистр сведений вместо ТЧ, и будет тебе щасте.

попробуй из списка провести

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

Время выполнения запроса ДС не учитывается в замере нигде.
Не читал нулевой пост, только заголовок.

настройки  - отображать показатели производительности - текущие вызовы: сколько показывает?

(10) Еще несколько раз перепровел документ и из формы и из списка - время снизилось до 2,5 минут в обоих случаях, видимо статистика обновилась. Но время сохранения одинаковая, что из формы, что из списка

(12) А есть полная инфа по "Замеру производительности" что он не учитывает?

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

(16) так цель то не вычислить что и сколько, а оптимизировать

(13) Последние данные:
Время проведения документа из формы фактически: 3,5 мин
Время проведения по замеру производительности: 30 сек
Накопленные вызовы: 7, время: 196,25, отправлено 4202, принято 1277614

(17) Ну так я и оптимизировал, что по "Замеру производительности" у меня документ стал проводиться 30 секунд - это в 10-ки раз быстрее, чем раньше) Но фактически все равно долго

где конечная точка стоит

(20) Я не ставил точки, чтобы учитывались и подписки на события.

1) Нажимаю кнопку "Замер производительности"
2) Провожу документ
3) Повторно нажимаю "Замер производительности"

Время записи в СУБД

ну и вообще по замеру время оценивать - так никто не делает. По замеру оченивать плохие строчки кода можно только

Возможно что документ проводится задним числом. И платформа пересчитывает итоги регистров за пол года. Это тоже не будет видно в отладчике.

(23) Ты не представляешь, сколько ценного может дать замер, когда тебе доступа к серверу 1с нет.

Замер производительности может дать главное - доступ к серверу sql и 1C :-)

(24) Это документ по бюджетам. Он записывает данные в регистр наоборот со следующего месяца и на несколько лет вперед.
Расчет текущих итогов я отключил

(24) А итоги рассчитаны на начало месяца. Поэтому пересечения нет

(18) проведи документ из списка

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

(25) так доступ к серверу можно получить запустив внешнюю обработку

(28) Я уже писал, что время сохранения из формы и из списка как ни странно примерно одинаковое. Сейчас еще раз на всякий случай провел так и так. В результате:
Время сохранения из списка: 2 мин 47 сек
Время сохранения из формы: 2 мин 57 сек

значит остальное запись движений и документа

(30) Навскидку места которые могут тормозить при проведении из списка и не видны в отладчике:
- расчет итогов (как пересчет старых так и расчет текущих);
- RLS пользователя под которым идёт запись;
- расходы на запись в таблицы самих данных и расчет служебных данных (индексы, критерии отбора и прочие);
- регистрация в планах обмена.

(17) Хз о чем ты

(32) В моем случае:
1) Расчета итогов нет, так как документ делает движение будущими датами, а итоги рассчитаны на начало текущего месяца, рассчет текущих итогов я отключил
2) Движения делаю под администратором с полными правами
4) Регистрацию в планы обмена я отключил

профалер в руки и смотри сколько времени документ пишется в субд

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

(34) Неужто замер не показывает долгие запросы?

(37) Общее время проведения документа в замере производительности 30 сек

(38) На ИТС есть методика сбора данных с СУБД и их грамотного анализа - действуй

(32) Не знаю что ты имел ввиду под "Не видны в отладчике", но в замере производительности это все учитывается.

(40) Он именно замеры и имел в виду. Но походу он про замеры не до момента возвращения на клиента.
Например, померить код в событии ОбработкаПроведения или даже в подписках нескольких, но замер заканчивается до конца и самое главное коммита / сброса данных в буфер и пересчетов всяких итогов.

*заканчивается до конца транзакции

Не учитывается время на сериализацию\десериализацию данных при передачи на сервер и само время передачи.
При 25000 строк это и есть Ваша разница во времени

И в ТЖ Вы этого не увидмте

И SQL куритить бесполезно

(45) Да ладно пугать. На ИТС про это описано - как грамотно замерить и осознать, что время ушло "в никуда" )

АПДЕКС с клиентскими замерами полезен разве что тут и бывает

30000 строк с 4 колонками на сервер и обратно около минуты идут.
Если заменить на внеконтекстный вызов с массивом структур, то эмпирически время сокращается в 2е

(46) там есть размер передаваемых данных в call/scall. Но времени затрачиваемого на сериализации в принципе нет, а оно значительно

Но сам размер это ниочом, те же бинарные данные (например картинка) того же объема на клиент идут секунду - 2

Проверить что проблема в сериализации и передаче данных очень просто.
На этой форме делаешь кнопку.
В ней пустой контекстный серверный вызов.
И засеки время на путешествие формы туда и обратно без какого либо кода

(49) Да не. Я про (47) имел в виду. Тормоза, не пойманные счетчиками СУБД и долгими событиями ТЖ, отлавливаются АПДЕКСом.

Самый быстрый способ исправить.
Если во время нажатия на кнопку и правда Накопленные вызовы: 7
Тогда после нажатия на кнопку идите сразу на сервер и делайте всё там, так будет 1 вызов.
+ Не указано сколько записей в регистр идёт.

(53) В 2 регистра по 144 000 записей)

Ну в 8.3 эскалация на уровень таблицы по управляемым блокировкам 100 к строк.
Тут уже и правда ТЖ нужен.

(55) Это да. Но я тестирование провожу в тестовой базе, там только я один. Получается ожидания нет на блокировках как я понимаю. А если и происходит эскалация, то это еще и быстрее установится блокировка сразу на таблицу)
Но в рабочей базе согласен, этот момент необходимо продумать. Если и правда происходит эскалация на всю таблицу, то это очень плохо

(56) то что ты один, это не значит что ты один, про регламент ныне задания не забывай)

(57)  В тестовых рег. задания у нас отключены

(43) Сериализация параметров при начале и десериализация при завершении серверного вызова включается в длительность вызова и таким образом попадает в замер производительности.

Все не читал, но можно попробовать ещё включить проведение в привилегированном режиме

Вообще топикстартеру для начала нужно было свой замер предоставить на обозрение.

(59) не всегда.
(60) Проведение привелигерованное по умолчанию.

И эта одна из тех галок, которую я не видел что бы кто то хоть раз тронул

(62) если новый документ, а если документ из 8,2?