Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Долгое открытие формы в клиент-серверном режиме

Долгое открытие формы в клиент-серверном режиме
Я
   newbling
 
09.11.16 - 14:30
УТ 11.1 - практически основная форма обработки ПодборТовараВДокументПродажи. В файловом режиме открывается 4 секунды, в клиент-серверном 34.

В каком направлении копать?
 
 
   newbling
 
1 - 09.11.16 - 14:30
(0) хотел написать - практически типовая.
   Cyberhawk
 
2 - 09.11.16 - 14:31
Я бы начал с замера в отладчике. Если он не показывает время 34 секунды нигде, то профайлер и запросы
   newbling
 
3 - 09.11.16 - 14:31
По замеру и смотрю.
   newbling
 
4 - 09.11.16 - 14:33
(2) А профайлер только для mssql?
   Cyberhawk
 
5 - 09.11.16 - 14:34
(3) Ну и что там, в сумме цифры дают твои 30 секунд? Замер не учитывает время выполнения запросов, поэтому если замер не показывает подозрительно длительные операции, то дело в запросах
   Cyberhawk
 
6 - 09.11.16 - 14:36
(4) Если подразумевается средство для просмотра текстов и длительности, то не только
   newbling
 
7 - 09.11.16 - 14:37
(5) замер 34 показывает на открытии формы. Надо бы всех выгнать в конце дня, отладку на сервере включить чтоб поковыряться в ПриСозданииНаСервере. Мб там дело.
   Cyberhawk
 
8 - 09.11.16 - 14:40
Лол. У тебя замер без длительности исполнения серверного кода, чего ты ждешь тут?
   Живой Ископаемый
9 - 09.11.16 - 14:45
2(5) почему замер не учитывает время выполнения запросов?
   newbling
 
10 - 09.11.16 - 14:56
Врубил отладку на сервере, косяк вообще не там, где изначально думал. Все проблемы в ЕстьЗначенияЦенПозжеДатыПодбора().

Сейчас буду ковырять нафиг оно нужно вообще
 
 Рекламное место пустует
   newbling
 
11 - 09.11.16 - 14:57
Там запрос

    "ВЫБРАТЬ РАЗРЕШЕННЫЕ
    |    МАКСИМУМ(ЦеныНоменклатурыСрезПоследних.Период) КАК Период
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В (&ВидыЦен)) КАК ЦеныНоменклатурыСрезПоследних"
   newbling
 
12 - 09.11.16 - 14:57
вот в нём всё и встаёт
   Живой Ископаемый
13 - 09.11.16 - 15:03
2(12) чо планируешь делать?
   newbling
 
14 - 09.11.16 - 15:04
Да вот ищу где она там достаётся. Насколько понял, это некая проверка на актуальность цен. Вроде как нужна, но 30+ секунд на открытие грёбаного подбора это перебор.
   newbling
 
15 - 09.11.16 - 15:06
(14) Думаю вообще нафиг её убрать, а проверять актуальность цен при добавлении в переносе в корзину с оповещением.

Должна быть настолько редкая ситуация, что каждый раз так пользователя мучить смысла нет.
   newbling
 
16 - 09.11.16 - 15:07
при переносе можно будет сделать проверку по виртуальной таблице только по подобранной номенклатуре и будет почти моментально проверять.
   Живой Ископаемый
17 - 09.11.16 - 15:09
2(14) Ну то есть ты понял, зачем-то получается максимальный период из физической практически(потому что не задана дата среза) таблицы периодического регистра сведений по данному виду цен.
Наверное и нужно, но наверняка можно получить как-то по-другому, быстрее.
   newbling
 
18 - 09.11.16 - 15:10
ага, только для этого надо править общий модуль. Этим и займусь.
   newbling
 
19 - 09.11.16 - 15:28
Ааа, там вот зачем оно нужно.

        УсловиеОтбораПоДате = ?(ЕстьЦеныВБудущем, "&Дата", "");
        
        ПодстрокаЗамены = СтрЗаменить(ПодстрокаЗамены, "{УсловиеОтбораПоДате}", УсловиеОтбораПоДате);


т.е. если нет цен позже текущей даты, то запрос идёт по срезу последних, если есть, то по срезу последних на дату...
   newbling
 
20 - 09.11.16 - 15:35
В общем, на данный момент просто решил выставлять, что Цены в будущем есть. Оказалось быстрее сразу делать срез по текущей дате, чем проверять нужно ли его делать.

После поправки типового кода скорость возросла с 34 секунд до 0.7 секунд.
   newbling
 
21 - 09.11.16 - 15:35
Даже интересно, а в каких случаях оно надо и даёт прирост производительности.
   newbling
 
22 - 09.11.16 - 15:55
нет, ошибочка вышла, это на файловой ускорение произошло. На клиент-серверной замедление в 3 раза лол
   newbling
 
23 - 09.11.16 - 15:55
я уж обрадовался
   newbling
 
24 - 09.11.16 - 16:01
Альтернативное решение - установить, что цен в будущем нет, тогда запрос просто будет по срезу последних, а самим уже перед записью регистра цен следить за тем, чтоб не писали на будущее число.
   Живой Ископаемый
25 - 09.11.16 - 16:04
2(24) а при установленной дате в срезе последних насколько быстрее все?
   newbling
 
26 - 09.11.16 - 16:17
(25) в файловой в 6 раз быстрее, в клиент-серверной в 3 раза медленнее =D
   newbling
 
27 - 09.11.16 - 16:24
В общем, на данный момент решил сделать так:

Проверку цен на будущее не делаем, задаём сразу Ложь. Получаем ускорение с ~34 секунд до ~1 секунды.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует