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


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) Спасибо! Покурю автовакуум.


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