|
Долгое открытие формы в клиент-серверном режиме | ☑ | ||
---|---|---|---|---|
0
newbling
09.11.16
✎
14:30
|
УТ 11.1 - практически основная форма обработки ПодборТовараВДокументПродажи. В файловом режиме открывается 4 секунды, в клиент-серверном 34.
В каком направлении копать? |
|||
1
newbling
09.11.16
✎
14:30
|
(0) хотел написать - практически типовая.
|
|||
2
Cyberhawk
09.11.16
✎
14:31
|
Я бы начал с замера в отладчике. Если он не показывает время 34 секунды нигде, то профайлер и запросы
|
|||
3
newbling
09.11.16
✎
14:31
|
По замеру и смотрю.
|
|||
4
newbling
09.11.16
✎
14:33
|
(2) А профайлер только для mssql?
|
|||
5
Cyberhawk
09.11.16
✎
14:34
|
(3) Ну и что там, в сумме цифры дают твои 30 секунд? Замер не учитывает время выполнения запросов, поэтому если замер не показывает подозрительно длительные операции, то дело в запросах
|
|||
6
Cyberhawk
09.11.16
✎
14:36
|
(4) Если подразумевается средство для просмотра текстов и длительности, то не только
|
|||
7
newbling
09.11.16
✎
14:37
|
(5) замер 34 показывает на открытии формы. Надо бы всех выгнать в конце дня, отладку на сервере включить чтоб поковыряться в ПриСозданииНаСервере. Мб там дело.
|
|||
8
Cyberhawk
09.11.16
✎
14:40
|
Лол. У тебя замер без длительности исполнения серверного кода, чего ты ждешь тут?
|
|||
9
Живой Ископаемый
09.11.16
✎
14:45
|
2(5) почему замер не учитывает время выполнения запросов?
|
|||
10
newbling
09.11.16
✎
14:56
|
Врубил отладку на сервере, косяк вообще не там, где изначально думал. Все проблемы в ЕстьЗначенияЦенПозжеДатыПодбора().
Сейчас буду ковырять нафиг оно нужно вообще |
|||
11
newbling
09.11.16
✎
14:57
|
Там запрос
"ВЫБРАТЬ РАЗРЕШЕННЫЕ | МАКСИМУМ(ЦеныНоменклатурыСрезПоследних.Период) КАК Период |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В (&ВидыЦен)) КАК ЦеныНоменклатурыСрезПоследних" |
|||
12
newbling
09.11.16
✎
14:57
|
вот в нём всё и встаёт
|
|||
13
Живой Ископаемый
09.11.16
✎
15:03
|
2(12) чо планируешь делать?
|
|||
14
newbling
09.11.16
✎
15:04
|
Да вот ищу где она там достаётся. Насколько понял, это некая проверка на актуальность цен. Вроде как нужна, но 30+ секунд на открытие грёбаного подбора это перебор.
|
|||
15
newbling
09.11.16
✎
15:06
|
(14) Думаю вообще нафиг её убрать, а проверять актуальность цен при добавлении в переносе в корзину с оповещением.
Должна быть настолько редкая ситуация, что каждый раз так пользователя мучить смысла нет. |
|||
16
newbling
09.11.16
✎
15:07
|
при переносе можно будет сделать проверку по виртуальной таблице только по подобранной номенклатуре и будет почти моментально проверять.
|
|||
17
Живой Ископаемый
09.11.16
✎
15:09
|
2(14) Ну то есть ты понял, зачем-то получается максимальный период из физической практически(потому что не задана дата среза) таблицы периодического регистра сведений по данному виду цен.
Наверное и нужно, но наверняка можно получить как-то по-другому, быстрее. |
|||
18
newbling
09.11.16
✎
15:10
|
ага, только для этого надо править общий модуль. Этим и займусь.
|
|||
19
newbling
09.11.16
✎
15:28
|
Ааа, там вот зачем оно нужно.
УсловиеОтбораПоДате = ?(ЕстьЦеныВБудущем, "&Дата", ""); ПодстрокаЗамены = СтрЗаменить(ПодстрокаЗамены, "{УсловиеОтбораПоДате}", УсловиеОтбораПоДате); т.е. если нет цен позже текущей даты, то запрос идёт по срезу последних, если есть, то по срезу последних на дату... |
|||
20
newbling
09.11.16
✎
15:35
|
В общем, на данный момент просто решил выставлять, что Цены в будущем есть. Оказалось быстрее сразу делать срез по текущей дате, чем проверять нужно ли его делать.
После поправки типового кода скорость возросла с 34 секунд до 0.7 секунд. |
|||
21
newbling
09.11.16
✎
15:35
|
Даже интересно, а в каких случаях оно надо и даёт прирост производительности.
|
|||
22
newbling
09.11.16
✎
15:55
|
нет, ошибочка вышла, это на файловой ускорение произошло. На клиент-серверной замедление в 3 раза лол
|
|||
23
newbling
09.11.16
✎
15:55
|
я уж обрадовался
|
|||
24
newbling
09.11.16
✎
16:01
|
Альтернативное решение - установить, что цен в будущем нет, тогда запрос просто будет по срезу последних, а самим уже перед записью регистра цен следить за тем, чтоб не писали на будущее число.
|
|||
25
Живой Ископаемый
09.11.16
✎
16:04
|
2(24) а при установленной дате в срезе последних насколько быстрее все?
|
|||
26
newbling
09.11.16
✎
16:17
|
(25) в файловой в 6 раз быстрее, в клиент-серверной в 3 раза медленнее =D
|
|||
27
newbling
09.11.16
✎
16:24
|
В общем, на данный момент решил сделать так:
Проверку цен на будущее не делаем, задаём сразу Ложь. Получаем ускорение с ~34 секунд до ~1 секунды. Запрещаем запись цен на будущую дату в регистре цен номенклатуры. Если понадобится, буду какими-нибудь отложенными движениями делать. |
|||
28
Cyberhawk
09.11.16
✎
16:35
|
(9) Я имел в виду запросы ДС, например. Т.н. "неявные", т.е. выполняемые не из объекта встроенного языка "Запрос".
Ну т.е. акцент хотел сделать на том, что если в замере время сильно не совпадает с наблюдаемым, то дело может быть в таких "неявных" запросах. |
|||
29
newbling
09.11.16
✎
16:36
|
(28) не, в данном случае совпадает.
|
|||
30
Живой Ископаемый
09.11.16
✎
16:49
|
2(28)э... ну да наверное, но такие запрос можно сделать явными. Например устанавливать параметр в текст запроса в какой-либо процедуре и тогда время ее выполнения будет фиксироваться в замере.
|
|||
31
Живой Ископаемый
09.11.16
✎
16:51
|
хотя все равно да, когда порция данных с сервера будет подтягиваться, то время будет консумиться, но в замерах не отображаться.
|
|||
32
aleks_default
09.11.16
✎
17:39
|
а так не быстрее?
ВЫБРАТЬ РАЗРЕШЕННЫЕ первые 1 | ЦеныНоменклатурыСрезПоследних.Период КАК Период |ИЗ | РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В (&ВидыЦен)) КАК ЦеныНоменклатурыСрезПоследних УПОРЯДОЧИТЬ ПО ЦеныНоменклатурыСрезПоследних.Период УБЫВ |
|||
33
Ёпрст
09.11.16
✎
17:48
|
(32) нет
|
|||
34
newbling
09.11.16
✎
19:27
|
Вообще, хотелось бы поднять вопрос почему так происходит и в чём косяк? Почему запрос в файловом режиме отрабатывает 0.7 секунд, а в клиент-серверном 84, т.е. в 120 раз дольше. Мб проблема в настройке сервера?
|
|||
35
Mauser
09.11.16
✎
19:30
|
(34) Гб проблема в рассчитаных итогах
|
|||
36
newbling
09.11.16
✎
19:44
|
(35) я на тестовой базе запустил перед уходом тии на всякий случай - посмотрим.
|
|||
37
kofeinik
09.11.16
✎
22:52
|
||||
38
Fragster
гуру
09.11.16
✎
23:23
|
а что профайлер говорит? а статистика обновлена? а прочие регламенты скуля выполнены?
|
|||
39
Fragster
гуру
09.11.16
✎
23:24
|
почему не запрос к физической таблице вида
Выбрать Первые 1 Период Из РС.Цены Где Цены.ВидЦен В (&Цены) Упорядочить по Период Убыв как в (32) только без среза последних |
|||
40
Fragster
гуру
09.11.16
✎
23:24
|
что с RLS?
|
|||
41
Fragster
гуру
09.11.16
✎
23:24
|
в (39) пропущены разрешенные
|
|||
42
Ranger_83
09.11.16
✎
23:47
|
(0) файловая быстрее работает серверной, удивлен?)
Особенно, если сервер загружен,а в фаловой ты сидишь один |
|||
43
newbling
10.11.16
✎
09:44
|
(38) вот буду разбираться, вообще веб клиент тормозит там, где не должен бы.
|
|||
44
newbling
10.11.16
✎
09:48
|
(37) да, тоже, видать, буду чикать всё лишнее. Уж больно всё тормозно.
|
|||
45
newbling
10.11.16
✎
09:52
|
(37) но нам принципиальны ожидаемые остатки. Вот характеристики можно грохнуть
|
|||
46
newbling
10.11.16
✎
09:56
|
тии, кстати, никакого результата не дало.
|
|||
47
newbling
10.11.16
✎
10:07
|
(38) а можно подробнее про статистики и регламенты
|
|||
48
newbling
10.11.16
✎
11:51
|
(38) Можешь, пожалуйста, сказать в каком направлении копать, какие мануалы покурить, а то я серверной оптимизацией не занимался ещё.
|
|||
49
Fragster
гуру
10.11.16
✎
11:55
|
(48) https://kb.1c.ru/articleView.jsp?id=13 или гугл
|
|||
50
newbling
10.11.16
✎
11:59
|
тут какие-то неведомые постгрешные настройки, автовакуумы, коэффициенты масштабирования и ещё мегатонны безусловно полезной, но объёмной информации, которую просто нет времени изучать.
|
|||
51
newbling
10.11.16
✎
12:12
|
(50) в гугле. Посмотрим сейчас первую ссылку
|
|||
52
Fragster
гуру
10.11.16
✎
12:20
|
так у тебя постгре?
|
|||
53
newbling
10.11.16
✎
12:26
|
(52) на уровне настроить архивацию через pgdump
|
|||
54
newbling
10.11.16
✎
12:26
|
т.е. профан полный
|
|||
55
newbling
10.11.16
✎
12:27
|
балин, доступ к статье запрещён (52)
|
|||
56
Fragster
гуру
10.11.16
✎
12:28
|
про постгре закрывает все вопросы https://kb.1c.ru/articleView.jsp?id=91
|
|||
57
Fragster
гуру
10.11.16
✎
12:29
|
именно по настройке. ну и 8.3.9 релиз
|
|||
58
newbling
10.11.16
✎
13:16
|
(56) блин, и там доступ запрещён =(
|
|||
59
newbling
10.11.16
✎
13:16
|
(56) можешь название статьи сказать - так поищу
|
|||
60
Fragster
гуру
10.11.16
✎
13:23
|
(59) "Настройки PostgreSQL для работы с 1С:Предприятием. Часть 2"
|
|||
61
newbling
10.11.16
✎
13:27
|
(60) спасибо! нашёл, сейчас почитаю
|
|||
62
newbling
10.11.16
✎
14:31
|
(60) скульные настройки выставил как там рекомендуется, а что ты про статистику говорил?
|
|||
63
newbling
10.11.16
✎
14:32
|
пока не тестил - надо, я так понимаю, службу перезапускать чтоб он конфиг считал
|
|||
64
Fragster
гуру
10.11.16
✎
14:48
|
(62) статистика - это для мсскуля
|
|||
65
newbling
10.11.16
✎
15:20
|
После настроек 28 секунд открывается. Почти на 20% возросло. Прогресс, конечно, но всё равно придётся отменять проверку будущих цен.
|
|||
66
newbling
10.11.16
✎
15:53
|
(57) а почему 8.3.9?
У меня 8.3.8 |
|||
67
Fragster
гуру
10.11.16
✎
16:37
|
(66) они там койче переписали в вопросе постгре
ну и постгре от постгрепро для 1с последнюю неплохо бы поиметь |
|||
68
newbling
10.11.16
✎
17:48
|
(67) А там какой примерно прирост будет? 8.3.9, конечно, поставить можно, но какая из них стабильная - вот вопрос.
|
|||
69
ansh15
10.11.16
✎
18:06
|
(62) vacuumdb --analyze имя_базы
"--analyze Также вычислить статистику для оптимизатора." https://postgrespro.ru/docs/postgresql/9.4/app-vacuumdb Можно запускать в планировщике, когда нагрузка на сервер минимальна, ночью в выходной, например. |
|||
70
newbling
10.11.16
✎
22:18
|
(69) а то, что автовакуум включён, всё равно надо мануально делать analyze?
|
|||
71
ansh15
11.11.16
✎
02:45
|
(70) Для большинства случаев сбора статистики при включенном autovacuum, наверное, достаточно. Там сбор статистики выполняется при достижении определенных условий, заданных параметрами autovacuum_analyze_threshold и autovacuum_analyze_scale_factor. При ручном выполнении сбор статистики выполнится для всех таблиц в базе. Это не значит, что эту процедуру обязательно нужно выполнять.
Можно еще включить online_analyze для всех таблиц, а не только для временных по умолчанию, но тогда при интенсивных изменениях/удалениях нагрузка на сервер будет больше. Тот же тест Гилева показывает на 5-6 баллов меньше чем при выключенном. В общем, смотреть надо по обстоятельствам. А ночью в выходной можно vacuumdb --full |
|||
72
ansh15
11.11.16
✎
02:46
|
Неплохо разъясняется что к чему http://www.oslogic.ru/knowledge/638/optimizatsiya-postgresql-autovacuum-sborka-musora/
|
|||
73
newbling
11.11.16
✎
09:24
|
(72) Спасибо! Покурю автовакуум.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |