|
Что может не учитывать "Замер производительности"? | ☑ | ||
---|---|---|---|---|
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?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |