Имя: Пароль:
1C
1С v8
Что может не учитывать "Замер производительности"?
, ,
0 yabes
 
12.03.19
14:21
Добрый день. Оптимизирую проведение сложного большого документа (25000 строк). Анализирую скорость проведения с использованием "Замера производительности":
1) Нажимаю кнопку "Замер производительности"
2) Провожу документ
3) Повторно нажимаю "Замер производительности"

В итоге фактически документ проводится 7 минут, а замер производительности показывает 30 секунд
Как такое может быть? Что не учитывается?
1 aleks_default
 
12.03.19
14:24
Серверная отладка включена?
2 oslokot
 
12.03.19
14:25
Потому что на клиенте 25000 строк это овердохера
3 yabes
 
12.03.19
14:25
(1) Да, включена
4 yabes
 
12.03.19
14:26
(2) Это документ Форма ввода бюджета. По нескольким крупным проектам он очень большой
5 yabes
 
12.03.19
14:26
(0) Тестирую в своей тестовой базе, там только один пользователь. Блокировок не должно быть
6 aleks_default
 
12.03.19
14:27
Ну возможно это время передачи с клиента на сервер и обратно.
7 Конструктор1С
 
12.03.19
14:27
(0) "В итоге фактически документ проводится 7 минут, а замер производительности показывает 30 секунд"

Замер производительности не учитывает время на передачу тонны данных с сервера на клиент.
8 yabes
 
12.03.19
14:28
(7) Есть какие-нибудь советы по оптимизации? Без уменьшения количества строк в ТЧ
9 Конструктор1С
 
12.03.19
14:28
Если возникает задача таскать такое количество данных, используй регистр сведений вместо ТЧ, и будет тебе щасте.
10 Вафель
 
12.03.19
14:28
попробуй из списка провести
11 aleks_default
 
12.03.19
14:31
Плюс всякие платформенные процедуры типа записи движений в регистры, регистрации в планах обмена и т. п.
12 Cyberhawk
 
12.03.19
14:33
Время выполнения запроса ДС не учитывается в замере нигде.
Не читал нулевой пост, только заголовок.
13 Timon1405
 
12.03.19
14:35
настройки  - отображать показатели производительности - текущие вызовы: сколько показывает?
14 yabes
 
12.03.19
14:39
(10) Еще несколько раз перепровел документ и из формы и из списка - время снизилось до 2,5 минут в обоих случаях, видимо статистика обновилась. Но время сохранения одинаковая, что из формы, что из списка
15 yabes
 
12.03.19
14:40
(12) А есть полная инфа по "Замеру производительности" что он не учитывает?
16 Cyberhawk
 
12.03.19
14:43
(15) Этого не нужно, т.к. замер учитывает только длительность перехода от выполнения одной строки кода к выполнению другой и суммирует их.
Зная это ничего больше мудрить не нужно.
17 Вафель
 
12.03.19
14:44
(16) так цель то не вычислить что и сколько, а оптимизировать
18 yabes
 
12.03.19
14:49
(13) Последние данные:
Время проведения документа из формы фактически: 3,5 мин
Время проведения по замеру производительности: 30 сек
Накопленные вызовы: 7, время: 196,25, отправлено 4202, принято 1277614
19 yabes
 
12.03.19
14:51
(17) Ну так я и оптимизировал, что по "Замеру производительности" у меня документ стал проводиться 30 секунд - это в 10-ки раз быстрее, чем раньше) Но фактически все равно долго
20 Вафель
 
12.03.19
14:51
где конечная точка стоит
21 yabes
 
12.03.19
14:53
(20) Я не ставил точки, чтобы учитывались и подписки на события.

1) Нажимаю кнопку "Замер производительности"
2) Провожу документ
3) Повторно нажимаю "Замер производительности"
22 H A D G E H O G s
 
12.03.19
14:56
Время записи в СУБД
23 Вафель
 
12.03.19
14:56
ну и вообще по замеру время оценивать - так никто не делает. По замеру оченивать плохие строчки кода можно только
24 Rema Dan
 
12.03.19
14:56
Возможно что документ проводится задним числом. И платформа пересчитывает итоги регистров за пол года. Это тоже не будет видно в отладчике.
25 H A D G E H O G s
 
12.03.19
14:57
(23) Ты не представляешь, сколько ценного может дать замер, когда тебе доступа к серверу 1с нет.

Замер производительности может дать главное - доступ к серверу sql и 1C :-)
26 yabes
 
12.03.19
14:58
(24) Это документ по бюджетам. Он записывает данные в регистр наоборот со следующего месяца и на несколько лет вперед.
Расчет текущих итогов я отключил
27 yabes
 
12.03.19
14:59
(24) А итоги рассчитаны на начало месяца. Поэтому пересечения нет
28 Жан Пердежон
 
12.03.19
15:00
(18) проведи документ из списка

сам документ очень тяжелый, особенно табдок в шапке (в твоем случае скорее всего передача клиент-сервер); а так пути оптимизации фвб - сохранение табдока в реквизите (ускорит открытие), построение самого дерева табдока, проведение - выкинуть примитивные типы из измерений; отказаться от зависимых оборотов (если есть)
29 Вафель
 
12.03.19
15:10
(25) так доступ к серверу можно получить запустив внешнюю обработку
30 yabes
 
12.03.19
15:16
(28) Я уже писал, что время сохранения из формы и из списка как ни странно примерно одинаковое. Сейчас еще раз на всякий случай провел так и так. В результате:
Время сохранения из списка: 2 мин 47 сек
Время сохранения из формы: 2 мин 57 сек
31 Вафель
 
12.03.19
15:20
значит остальное запись движений и документа
32 Rema Dan
 
12.03.19
15:28
(30) Навскидку места которые могут тормозить при проведении из списка и не видны в отладчике:
- расчет итогов (как пересчет старых так и расчет текущих);
- RLS пользователя под которым идёт запись;
- расходы на запись в таблицы самих данных и расчет служебных данных (индексы, критерии отбора и прочие);
- регистрация в планах обмена.
33 Cyberhawk
 
12.03.19
15:28
(17) Хз о чем ты
34 yabes
 
12.03.19
15:55
(32) В моем случае:
1) Расчета итогов нет, так как документ делает движение будущими датами, а итоги рассчитаны на начало текущего месяца, рассчет текущих итогов я отключил
2) Движения делаю под администратором с полными правами
4) Регистрацию в планы обмена я отключил
35 Вафель
 
12.03.19
16:02
профалер в руки и смотри сколько времени документ пишется в субд
36 Gantosha
 
12.03.19
16:03
вообще если это ерп , то время получения факта по такому бюджету будет куда больше, чем эти минуты которые сейчас будут оптимизированы.
37 Cyberhawk
 
12.03.19
16:15
(34) Неужто замер не показывает долгие запросы?
38 yabes
 
12.03.19
16:29
(37) Общее время проведения документа в замере производительности 30 сек
39 Cyberhawk
 
12.03.19
16:42
(38) На ИТС есть методика сбора данных с СУБД и их грамотного анализа - действуй
40 TormozIT
 
гуру
12.03.19
17:17
(32) Не знаю что ты имел ввиду под "Не видны в отладчике", но в замере производительности это все учитывается.
41 Cyberhawk
 
12.03.19
17:33
(40) Он именно замеры и имел в виду. Но походу он про замеры не до момента возвращения на клиента.
Например, померить код в событии ОбработкаПроведения или даже в подписках нескольких, но замер заканчивается до конца и самое главное коммита / сброса данных в буфер и пересчетов всяких итогов.
42 Cyberhawk
 
12.03.19
17:33
*заканчивается до конца транзакции
43 palsergeich
 
12.03.19
17:48
Не учитывается время на сериализацию\десериализацию данных при передачи на сервер и само время передачи.
При 25000 строк это и есть Ваша разница во времени
44 palsergeich
 
12.03.19
17:48
И в ТЖ Вы этого не увидмте
45 palsergeich
 
12.03.19
17:49
И SQL куритить бесполезно
46 Cyberhawk
 
12.03.19
17:50
(45) Да ладно пугать. На ИТС про это описано - как грамотно замерить и осознать, что время ушло "в никуда" )
47 Cyberhawk
 
12.03.19
17:51
АПДЕКС с клиентскими замерами полезен разве что тут и бывает
48 palsergeich
 
12.03.19
17:51
30000 строк с 4 колонками на сервер и обратно около минуты идут.
Если заменить на внеконтекстный вызов с массивом структур, то эмпирически время сокращается в 2е
49 palsergeich
 
12.03.19
17:52
(46) там есть размер передаваемых данных в call/scall. Но времени затрачиваемого на сериализации в принципе нет, а оно значительно
50 palsergeich
 
12.03.19
17:54
Но сам размер это ниочом, те же бинарные данные (например картинка) того же объема на клиент идут секунду - 2
51 palsergeich
 
12.03.19
17:56
Проверить что проблема в сериализации и передаче данных очень просто.
На этой форме делаешь кнопку.
В ней пустой контекстный серверный вызов.
И засеки время на путешествие формы туда и обратно без какого либо кода
52 Cyberhawk
 
12.03.19
17:58
(49) Да не. Я про (47) имел в виду. Тормоза, не пойманные счетчиками СУБД и долгими событиями ТЖ, отлавливаются АПДЕКСом.
53 palsergeich
 
12.03.19
18:01
Самый быстрый способ исправить.
Если во время нажатия на кнопку и правда Накопленные вызовы: 7
Тогда после нажатия на кнопку идите сразу на сервер и делайте всё там, так будет 1 вызов.
+ Не указано сколько записей в регистр идёт.
54 yabes
 
12.03.19
18:05
(53) В 2 регистра по 144 000 записей)
55 palsergeich
 
12.03.19
18:06
Ну в 8.3 эскалация на уровень таблицы по управляемым блокировкам 100 к строк.
Тут уже и правда ТЖ нужен.
56 yabes
 
12.03.19
18:11
(55) Это да. Но я тестирование провожу в тестовой базе, там только я один. Получается ожидания нет на блокировках как я понимаю. А если и происходит эскалация, то это еще и быстрее установится блокировка сразу на таблицу)
Но в рабочей базе согласен, этот момент необходимо продумать. Если и правда происходит эскалация на всю таблицу, то это очень плохо
57 palsergeich
 
12.03.19
18:32
(56) то что ты один, это не значит что ты один, про регламент ныне задания не забывай)
58 yabes
 
12.03.19
18:46
(57)  В тестовых рег. задания у нас отключены
59 TormozIT
 
гуру
13.03.19
09:29
(43) Сериализация параметров при начале и десериализация при завершении серверного вызова включается в длительность вызова и таким образом попадает в замер производительности.
60 bodri
 
13.03.19
09:35
Все не читал, но можно попробовать ещё включить проведение в привилегированном режиме
61 TormozIT
 
гуру
13.03.19
09:42
Вообще топикстартеру для начала нужно было свой замер предоставить на обозрение.
62 palsergeich
 
13.03.19
09:52
(59) не всегда.
(60) Проведение привелигерованное по умолчанию.
63 palsergeich
 
13.03.19
09:54
И эта одна из тех галок, которую я не видел что бы кто то хоть раз тронул
64 bodri
 
13.03.19
11:27
(62) если новый документ, а если документ из 8,2?