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

В каком направлении копать?

(0) хотел написать - практически типовая.

Я бы начал с замера в отладчике. Если он не показывает время 34 секунды нигде, то профайлер и запросы

По замеру и смотрю.

(2) А профайлер только для mssql?

(3) Ну и что там, в сумме цифры дают твои 30 секунд? Замер не учитывает время выполнения запросов, поэтому если замер не показывает подозрительно длительные операции, то дело в запросах

(4) Если подразумевается средство для просмотра текстов и длительности, то не только

(5) замер 34 показывает на открытии формы. Надо бы всех выгнать в конце дня, отладку на сервере включить чтоб поковыряться в ПриСозданииНаСервере. Мб там дело.

Лол. У тебя замер без длительности исполнения серверного кода, чего ты ждешь тут?

2(5) почему замер не учитывает время выполнения запросов?

Врубил отладку на сервере, косяк вообще не там, где изначально думал. Все проблемы в ЕстьЗначенияЦенПозжеДатыПодбора().

Сейчас буду ковырять нафиг оно нужно вообще

Там запрос

    "ВЫБРАТЬ РАЗРЕШЕННЫЕ
    |    МАКСИМУМ(ЦеныНоменклатурыСрезПоследних.Период) КАК Период
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В (&ВидыЦен)) КАК ЦеныНоменклатурыСрезПоследних"

вот в нём всё и встаёт

2(12) чо планируешь делать?

Да вот ищу где она там достаётся. Насколько понял, это некая проверка на актуальность цен. Вроде как нужна, но 30+ секунд на открытие грёбаного подбора это перебор.

(14) Думаю вообще нафиг её убрать, а проверять актуальность цен при добавлении в переносе в корзину с оповещением.

Должна быть настолько редкая ситуация, что каждый раз так пользователя мучить смысла нет.

при переносе можно будет сделать проверку по виртуальной таблице только по подобранной номенклатуре и будет почти моментально проверять.

2(14) Ну то есть ты понял, зачем-то получается максимальный период из физической практически(потому что не задана дата среза) таблицы периодического регистра сведений по данному виду цен.
Наверное и нужно, но наверняка можно получить как-то по-другому, быстрее.

ага, только для этого надо править общий модуль. Этим и займусь.

Ааа, там вот зачем оно нужно.


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


т.е. если нет цен позже текущей даты, то запрос идёт по срезу последних, если есть, то по срезу последних на дату...

В общем, на данный момент просто решил выставлять, что Цены в будущем есть. Оказалось быстрее сразу делать срез по текущей дате, чем проверять нужно ли его делать.

После поправки типового кода скорость возросла с 34 секунд до 0.7 секунд.

Даже интересно, а в каких случаях оно надо и даёт прирост производительности.

нет, ошибочка вышла, это на файловой ускорение произошло. На клиент-серверной замедление в 3 раза лол

я уж обрадовался

Альтернативное решение - установить, что цен в будущем нет, тогда запрос просто будет по срезу последних, а самим уже перед записью регистра цен следить за тем, чтоб не писали на будущее число.

2(24) а при установленной дате в срезе последних насколько быстрее все?

(25) в файловой в 6 раз быстрее, в клиент-серверной в 3 раза медленнее =D

В общем, на данный момент решил сделать так:

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

Запрещаем запись цен на будущую дату в регистре цен номенклатуры. Если понадобится, буду какими-нибудь отложенными движениями делать.

(9) Я имел в виду запросы ДС, например. Т.н. "неявные", т.е. выполняемые не из объекта встроенного языка "Запрос".
Ну т.е. акцент хотел сделать на том, что если в замере время сильно не совпадает с наблюдаемым, то дело может быть в таких "неявных" запросах.

(28) не, в данном случае совпадает.

2(28)э... ну да наверное, но такие запрос можно сделать явными. Например устанавливать параметр в текст запроса в какой-либо процедуре и тогда время ее выполнения будет фиксироваться в замере.

хотя все равно да, когда порция данных с сервера будет подтягиваться, то время будет консумиться, но в замерах не отображаться.

а так не быстрее?
ВЫБРАТЬ РАЗРЕШЕННЫЕ первые 1
    |    ЦеныНоменклатурыСрезПоследних.Период КАК Период
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены В (&ВидыЦен)) КАК ЦеныНоменклатурыСрезПоследних
УПОРЯДОЧИТЬ ПО ЦеныНоменклатурыСрезПоследних.Период УБЫВ

(32) нет

Вообще, хотелось бы поднять вопрос почему так происходит и в чём косяк? Почему запрос в файловом режиме отрабатывает 0.7 секунд, а в клиент-серверном 84, т.е. в 120 раз дольше. Мб проблема в настройке сервера?

(34) Гб проблема в рассчитаных итогах

(35) я на тестовой базе запустил перед уходом тии на всякий случай - посмотрим.

Косяк - в генах УТ11.
Посмотри вот это - оно?
http://catalog.mista.ru/public/199272/

а что профайлер говорит? а статистика обновлена? а прочие регламенты скуля выполнены?

почему не запрос к физической таблице вида
Выбрать Первые 1 Период Из РС.Цены Где Цены.ВидЦен В (&Цены) Упорядочить по Период Убыв
как в (32) только без среза последних

что с RLS?

в (39) пропущены разрешенные

(0) файловая быстрее работает серверной, удивлен?)
Особенно, если сервер загружен,а в фаловой ты сидишь один

(38) вот буду разбираться, вообще веб клиент тормозит там, где не должен бы.

(37) да, тоже, видать, буду чикать всё лишнее. Уж больно всё тормозно.

(37) но нам принципиальны ожидаемые остатки. Вот характеристики можно грохнуть

тии, кстати, никакого результата не дало.

(38) а можно подробнее про статистики и регламенты

(38) Можешь, пожалуйста, сказать в каком направлении копать, какие мануалы покурить, а то я серверной оптимизацией не занимался ещё.

(48) https://kb.1c.ru/articleView.jsp?id=13 или гугл

тут какие-то неведомые постгрешные настройки, автовакуумы, коэффициенты масштабирования и ещё мегатонны безусловно полезной, но объёмной информации, которую просто нет времени изучать.

(50) в гугле. Посмотрим сейчас первую ссылку

так у тебя постгре?

(52) на уровне настроить архивацию через pgdump

т.е. профан полный

балин, доступ к статье запрещён (52)

про постгре закрывает все вопросы https://kb.1c.ru/articleView.jsp?id=91

именно по настройке. ну и 8.3.9 релиз

(56) блин, и там доступ запрещён =(

(56) можешь название статьи сказать - так поищу

(59) "Настройки PostgreSQL для работы с 1С:Предприятием. Часть 2"

(60) спасибо! нашёл, сейчас почитаю

(60) скульные настройки выставил как там рекомендуется, а что ты про статистику говорил?

пока не тестил - надо, я так понимаю, службу перезапускать чтоб он конфиг считал

(62) статистика - это для мсскуля

После настроек 28 секунд открывается. Почти на 20% возросло. Прогресс, конечно, но всё равно придётся отменять проверку будущих цен.

(57) а почему 8.3.9?
У меня 8.3.8

(66) они там койче переписали в вопросе постгре
ну и постгре от постгрепро для 1с последнюю неплохо бы поиметь

(67) А там какой примерно прирост будет? 8.3.9, конечно, поставить можно, но какая из них стабильная - вот вопрос.

(62) vacuumdb --analyze имя_базы
"--analyze Также вычислить статистику для оптимизатора."
https://postgrespro.ru/docs/postgresql/9.4/app-vacuumdb
Можно запускать в планировщике, когда нагрузка на сервер минимальна, ночью в выходной, например.

(69) а то, что автовакуум включён, всё равно надо мануально делать analyze?

(70) Для большинства случаев сбора статистики при включенном autovacuum, наверное, достаточно. Там сбор статистики выполняется при достижении определенных условий, заданных параметрами autovacuum_analyze_threshold и autovacuum_analyze_scale_factor. При ручном выполнении сбор статистики выполнится для всех таблиц в базе. Это не значит, что эту процедуру обязательно нужно выполнять.
Можно еще включить online_analyze для всех таблиц, а не только для временных по умолчанию, но тогда при интенсивных изменениях/удалениях нагрузка на сервер будет больше. Тот же тест Гилева показывает на 5-6 баллов меньше чем при выключенном. В общем, смотреть надо по обстоятельствам.
А ночью в выходной можно vacuumdb --full

Неплохо разъясняется что к чему http://www.oslogic.ru/knowledge/638/optimizatsiya-postgresql-autovacuum-sborka-musora/

(72) Спасибо! Покурю автовакуум.