Имя: Пароль:
1C
1С v8
Долгое открытие формы в клиент-серверном режиме
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
Косяк - в генах УТ11.
Посмотри вот это - оно?
http://catalog.mista.ru/public/199272/
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
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) Спасибо! Покурю автовакуум.
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn