В общем всё по порядку: имеем почти типовую УТ 11.1(пара реквизитов добавлена, пара предопределённых элементов справочников, ничего особенного), в которую обработками из внешних файлов загружаются данные поступлений импорта и таможенных деклараций к этим поступлениям.
Получаются документы с довольно большими табличными частями, но не сказать, что неподъемными: ~10 тыс позиций. При открытии формы документа имеем зависание на ~20-30 секунд, причём код модуля даже не начинает выполняться(ставил брейкпоинт в самом начале "ПриСозданииНаСервере"). Обычное приложение в лице УТ 10.3 на той же системе нормально открывает и 20 тыс позиций.
Чтобы было исчерпывающе: УТ 11.1.5.16, платформа 8.3.4.482(также пробовали на 8.3.5.1068), клиент-сервер, характеристики сервера сейчас не озвучу, но не думаю, что это важно - то же поведение и на другом сервере, и на файловой... При этом работает всего один пользователь(тестер).
Настроил технологический журнал, посмотрел, какой запрос делается при открытии формы, сам запрос занял где-то 7 мегабайт текста.

Собственно вопрос: это можно победить, не закупая железа на 100500 тыщ мильёнов? Или плюнуть на всё, не выпендриваться и писать всё на 10.3?

А это точно зависит от количества строк в ТЧ? Маленькие документики открываются быстро?

(0) Каша масленная какая-то..

Какой документ?

7 мегабайт запроса - это что? Примерно таблички скажи.

rls кстати, отключен?

(1) Да, маленькие быстро открываются, проверял на демке, грузил в неё такой же документ. Демонстрационный документ открывается за секунду, созданный - тормозит.

В управляемых формах, в клиент-сервере, табличка начинает люто тупить при параметрах

25 колонок * 100000 строк, не раньше.

(2) >7 мегабайт запроса - это что? Примерно таблички скажи.
"ПоступлениеТоваровИУслуг", "ТаможеннаяДекларацияИмпорт".
7 мегабайт - это трейс запроса при открытии по технологическому журналу.

rls отключён

Экий толстый запрос

7 мегабайт - это трейс запроса при открытии по технологическому журналу.

Жесть какая-то.

Взять тот же документ, очистить его, оставив 30 строк в ТЧ и посмотреть трейс.

(5) ++++

Посмотреть, есть ли в ТЧ колонки "через Точку"

Лучше всего дать мне демку, я вам все расскажу.

(0) было дело, грузили доки 10к-100к строк. и та же фигня, хотя сервера стояли вайвай пописятядерваще. в итоге приняли как данность

(11) 40-60 колонок правда было. тупить начинало и на 10к строк. причем тупило примерно одинаково, что 10к что 100к, пользователи разницы не ощущали

(9) "Через точку" - в смысле "реквизиты реквизитов"? Посмотрю сейчас.
Могу дать конфу и файлы для загрузки и объяснить, как грузить, там достаточно просто.

(13) dt-шнег, плиз.

(14) Сейчас, из демки сделаю только.

(14) Вот dt: https://yadi.sk/d/Zc5z2PcoWQhKG
Последний по дате документ поступления.

(16) качаю.

(17)+1

Тормозит... Трейсить - какой смысл? Все равно типовую корячить   тут (и во всех остальных документах) ты не будешь

(19) Если есть способы - могу и раскорячить, всё равно её планировалось в дальнейшем значительно переделывать и снимать с поддержки.

В таможенной декларации, как и в остальных формах документов, есть вывод реквизитов номенклатуры через точку в таб.часть товаров.
Это проблема конечно, но это общая проблема конфигурации.

(0) Вот твой запрос

17 секунд идет

50:44.896000-171986,DBV8DBEng,3,Sql='SELECT
T2._LineNo2921,
T2._Fld2923RRef,
T2._Fld2922RRef,
T2._Fld2924RRef,
T2._Fld2925RRef,
T2._Fld2926,
T2._Fld2927,
T2._Fld2928,
T2._Fld2929RRef,
T2._Fld2930,
T2._Fld2931,
T2._Fld2932,
T2._Fld2933RRef,
T2._Fld2934,
T2._Fld8981,
T2._Fld2935RRef,
T2._Fld2936_TYPE,
T2._Fld2936_RTRef,
T2._Fld2936_RRRef,
T2._Fld2938,
T2._Fld2939RRef,
T2._Fld7575RRef,
T2._Fld8982RRef,
T2._Fld7646,
T2._Fld7647,
T2._Fld7648,
T2._Fld8983,
T2._Fld8984RRef,
T2._Fld8985,
T2._Fld13327,
T2._Fld8986RRef,
T2._Fld13328,
T2._Fld13329RRef,
T2._Fld13330RRef,
T2._Fld17563RRef,
T2._Fld17564RRef,
T2._Fld18396RRef,
T2._Fld18397,
0 AS SDBL_IDENTITY
FROM _Document162_VT2920 T2
INNER JOIN _Document162 T3
ON T3._Fld10059 = T2._Fld10059 AND T3._IDRRef = T2._Document162_IDRRef
WHERE ((T3._Fld10059 = 0)) AND (T3._IDRRef = 0xBF31089E0133AF2411E408F7C9A166F2)
ORDER BY 39 ASC, T2._LineNo2921'

еще вопрос интересный
канал толстый до клиента?

файловой просто плохо на объемах 100К+ в одной таблице

(0)> Или плюнуть на всё, не выпендриваться и писать всё на 10.3?
самое верное решение.
8.2-8.3 УФ будут допиливать до 9.0

В базе могут выполняться фоновые задания

(22) Главный вопрос - как его ускорить? С виду обычный JOIN основной таблицы с табличной частью, ничего особенного.
(23) Локалка, по-моему сотня.
(24) Файловая, собственно, тут ни при чём, проблема на клиент-серверной.
(25) Если до понедельника ответов не найду, видимо так и будет.
(26) Ну и что? База практически пустая(не та, что в dt, а просто обычная пустая база). Фоновые задания в пустой базе ставят всё раком?

(0) Праивльно лия понял что открываете вы док именно из загрузки. тоесть программно.

А теперь второй важный вопрос. Покажи код как ты открываешь документ.  программно. КОроче нужно посмотреть всю процедуру как ты его заполняешь и открываешь.

Что то мне подсказывает, что ты обработку загрузки криво написал

(28) Я открываю документ интерактивно.

начни использовать такси. там тормозов = ноль.

FROM _Document162_VT2920 T2
INNER JOIN _Document162 T3
ON T3._Fld10059 = T2._Fld10059 AND T3._IDRRef = T2._Document162_IDRRef AND ((T3._Fld10059 = 0)) AND (T3._IDRRef = 0xBF31089E0133AF2411E408F7C9A166F2)
ORDER BY 39 ASC, T2._LineNo2921'

(30) проверял?

(32) в такси -списки и демонические списки летают как в семерке.

ну и еще есть вопрос - от куда запрос получил? из профайлера или тех журнала? сдается, что из технологического журнала :)

(30) Попробую, раз такое дело.
(31) Не понял, эт к чему? Это кусок запроса, что выше.

(35) это ПРАВИЛЬНЫЙ запрос, а у тебя НЕ ПРАВИЛЬНЫЙ

условие нужно внести в джойн

ну и еще у тебя основная таблица назначена, значит у тебя и упорядовачивание по индексу ссылка+дата идет, я конечно не уверен на 100% но мне кажется, что тут то-же засада могет быть

(37)+ из-за неявного вложеного запроса...

(36) Оу. Не заметил. Проблема в том, что это автосгенеренный запрос, я не могу на него повлиять. Точней, могу, переделав форму. Так вот, что влияет на условия в запросе, который генерит платформа?

Мне кажется проблема именно в УФ, есть включить показатели производительности то можно увидеть, что зависает все после получения данных на клиенте в моем примере 5мб дынных(упакованных скорее всего в xml, так ведь общается клиент с сервером 1С?), УФ рисуются чтоле, у меня такая же фигня когда я загружаю данные из ДанныеФормыКоллекция
Операция        Расшифровка            Время (сек)    Количество итераций    Среднее
ЗаполнениеТаблицДанными    ЗаполнениеРеквизитовШапки    0/00:00:56.254    14 058            0/00:00:00.004
ЗаполнениеТаблицДанными    ЗаполнениеТаблицТоваров        0/00:00:15.750    27 631            0/00:00:00.001
ПередачаУпраления    ВызовКлиента            0/00:01:27.571    2            0/00:00:43.786
ПередачаУпраления    ВызовСервера            0/00:00:27.648    2            0/00:00:13.824

По мне так проблемы в г-коде, самые явные:
1. Обращения через точку(заполнить чего то там служебные реквизиты номенклатуры в ТЧ)
2. Неумелое оперирование обработкой ТЧ при открытии формы: данные ТЧ считываются во временную таблицу 8 или 10 раз в разных модулях и потом всегда построчный обход с заполнением свойств вместо считывания в ВТ 1 раз и передачи МВТ между вызовами

ну и
1. Возможное время на компиляцию 8-10 модулей при первом открытии формы при старте программы, здесь надо проверять, как и считывание значений(повт. используемых и проч.).
2. закомментаривание кода "ПриСозданииНаСервере" и в "ПриЧтенииНаСервере" приводит к открытию формы за доли секунды=)

проблема - тут одна, все правы, в г-нокоде.
Тех кто писал эти самые ГУФ.

Посмотрел что происходит - ну это жесть конечно.

Проблема действительно в платформе и связана она с получением реквизитов номенклатуры для отображения на форме.
С небольшим количеством записей всё нормально - просто запрос на соединение с таблицей номенклатуры.

Но с 10к записей происходит полный бред - платформа генерирует 10000 запросов на вставку ссылки на номенклатуру во временную таблицу, потом получает по этим ссылкам доп. реквизиты 1 запросом, потом еще 10000 раз записывает значения этих реквизитов во временную таблицу. Т.е. 20к операций вставок в таблицу происходит. Уж не знаю что это они - память экономят, или какой косяк обходит из-за совместимости с кучей СУБД, но это натуральная жесть.

(43) подобное поведение бывает при записи во времянку нетипизированного реквизита, там идет доп запрос ко всем метаданным....

по этому ВТ они такие, с ними нужно осторожно....

Так платформа виновата или, согласно (41), автор кода?

а что за поле _Fld10059 и стоит ли на нем галка "индексировать"

(44) Тут не при чем нетипизированные реквизиты, тут нет запросов к куче таблиц, тут просто построчная вставка во временную таблицу 10 000 строк. По_одной_строке. И потом еще раз вставка, уже с полученными значениями доп. реквизитов. Это очевидная проблема платформы. И с небольшим количеством строк так не происходит - получается всё одним запросом. Это позволяет предположить, что такое поведение есть результат кривой "оптимизации". Например, возможно, предполагалось, что нужно будет получать не все строки, а только часть.

(46) Этот запрос не вызывает проблем, выполняется миллисекунды.

(46) Кстати, это важно. Это общий реквизит ОбластьДанныхОсновныеДанные, и индекс по нему нельзя выбрать. Он либо всё время формируется, либо не формируется вообще, надо документацию читать.

(33) на ларьках или серьезно?

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

В процессе отработки процедур "ПриЧтенииНаСервере" выполняются два таких запроса - с ТЗ на 10к строк.

Однако, проблема производительности не в этом - запросы не очень быстрые, но около секунды выполняются.

Проблема в самой концепции обработки данных формы в "ПриЧтенииНаСервере" - там последовательно выполняются различные команды заполнения и каждая команда обходит ВСЮ табличную часть в 10к строк.

Хотя явно быстрее 1 раз обойти всю ТЧ и выполнить со строкой несколько команд.

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

Если выпилить из документа всё лишнее и переписать оптимально - будет летать.

Волшебно быстрый сервак, разогнанный до 4.5 Ггц, подгружает ядро процессора на 100% при открытии формы документа на овер 10 сек...
И в ERP 2.0 по сути тот же документ используется с тем же кодом... И заявлены тыщи пользователей онлайн. Мда...

В общем в (41) всё верно сразу написано, что-то я пропустил этот пост.

(53) Я убрал вызов ПриСозданииНаСервере и ПриЧтенииНаСервере - существенно открытие не ускорилось. Что-то не сходится...

(54) Ну ты что-то плохо убрал или плохо замерил. с 10 секунд до 2 у меня время упало.

Подойдём к проблеме с другой стороны.
Если документы надо просматривать и, возможно, редактировать, стоит ли их делать такими огромными?

(55) Что значит "плохо убрал"? Я вчера 1С увидел, что ли?

(56) Это НЕ огромные документы. Ещё раз говорю, 10.3 отлично открывается с аналогичным документом на 20 тысяч позиций.

(57) Не знаю, когда ты увидел 1С, но можно быть в курсе, что есть подсистема оценки производительности, из которой можно взять объективные данные до и после.
Сейчас вот специально замерил - до отключения ПриЧтенииЗаписи 19 сек, после - 3 сек.
При многократном повторении сохраняется такая тенденция.
Если у тебя лучше не стало - значит плохо убрал.

(59) Да, ты прав, прошу прощения. Просто я постепенно комментировал код, и время выполнения также менялось постепенно. А когда раскомментировал всё назад - сразу оценил, насколько сильно тормозило до этого.

Это все дибильная передача контекста с клиента на сервер имхо...

(61) Полностью согласен, сам вчера столкнулся. Впервые начал делать серьезную обработку на УФ, а не просто добавил простенькие формочки объектов. И тут повылазило.

Итак, платформа 8.2.16.368. В обработке есть реквизит типа "ДеревоЗначений", дерево размещено на форме. Для заполнения дерева при нажатии кнопки на клиенте вызываю контекстную серверную процедуру, в которой делаю следующее:

ОбработкаОбъект = ДанныеФормыВЗначение(Объект, Тип("ОбработкаОбъект.ФормированиеИОбработкаКлиетскихОтчетов"));
ОбработкаОбъект.ЗаполнитьДанныеДляОтчетов();
ЗначениеВДанныеФормы(ОбработкаОбъект, Объект);

Процедура из модуля обработки заполняет дерево, делаю запрос с помощью СКД, а затем серверная процедура формы загоняет обработку обратно. Когда данных не так много, все работает достаточно прилично, но когда начал отлаживать на примере с 3200 корневых строк в дереве, заполнение стало выполняться по 50 секунд, это очень много для небольшой самописной конфы в клиент-серверной базе. В дереве всего два уровня, у большинства строк всего одна подчиненная, редко у каких по две-три.

Старая версия обработки делала аналогичные запросы и заполняла табличную часть, а не дерево - менее 1 секунды на все про все.

Самое странное то, что при выполнении в окошке показателей видно, что сам серверный вызов заканчивается через 2-4 секунды, отображается объем полученных обратно данных, а после этого вся форма висит десятки секунд.

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

А вот в самой строке, где делается серверный вызов и стоит иконка обработки сервером отнимает 85 процентов времени! То есть вызов сделался, данные успешно обработались сервером и то ли контекст так долго тянется обратно, то ли проблема именно в отрисовке данных на форме. Это полная задница.

В дереве есть всего два ссылочных реквизита, думал, проблема в подтягивании их представлений. Заменил типы на строки, ничего не поменялось, просто тормозит.

Попробовал еще один вариант, по образцу обработки из УТ 11 "ПодборТоваровПоОтбору": делал так, что процедура из модуля возвращает дерево, а серверная процедура модуля формы вместо ЗначениеВДанныеФормы перезаполняет сам объект "ДанныеФормыСтруктура" по дереву.

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

Кто-то здесь говорил, что Такси не тормозит. Увы, проверить не могу, на работе нет сервера 8.3, чтобы промоделировать аналогичную базу, а взять домой не могу ни CF, ни DT, политика конторы, безопасники мониторят, в компы ничего вставлять нельзя.

P.S. Тут же в этой же форме вылезла еще одна проблема. Видел, что многие жалуются, что при свертке развертке дерева горячими клавишами Ctrl+Shift+Num+ и Ctrl+Shift+Num- операции делаются очень быстро, а при программном построчном выполнении Развернуть и Свернуть дико тупит. Проверено, действительно, тормозит адово, судя по всему из-за того, что при свертке каждой строки форма начинает перерисовывать состояние, прямо заметно, что "бегут" строки. Непонятно, как смоделировать нажатие горячих клавиш кроме как эмуляцией. Да и с ней есть проблемы из-за клавиш с numpad.

Пробовал играть с отображением в виде списка, сверткой в нем и повторным преобразованием в дерево - безуспешно. Может кто знает вариант?

Кстати, на том большой дереве с 3000 строк платформенное разворачивание уже тоже тормозит, но тут понятно, надо соотносить желание развернуть все с размером списка.

Короче, какая-то хрень. Даже если в контекстном серверном вызове не менять сам контекст формы, а просто возвратить дерево значений на клиент и там обрабатывать, то все равно так же точно лишние 20-30 секунд выполняется возврат контекста обратно ан сервер

(63) Попробуй отказаться от Древа.
Используй Динамический список :)

(64) По сути это не динамический список, а именно готовое дерево, в нем пользователь может поменять флажки, удалить строки, затем по этому дереву будут генерироваться клиентские отчеты.

Не могу представить реализацию такого функционала с помощью динамического списка, это методологически неверно. Плюс опять же, я писал, что после запроса из базы еще по определенному алгоритму в колонках проставляются флажки, как это сделать в динамическом списке?

Ну и последнее - если такая беда с деревьями, как разработчики вообще предполагают их использовать? :)

(65) Динамический список тоже редактируется, ставятся флажки...

(66) Но ты прав, он работает непосредственно с данными :)

(66) А пакетные запросы ваш динамический список поддерживает? У меня сложный пакетный запрос для отбора клиентов и получения доп. данных.

(67) Ага, уже посмотрел и понял, что использовать его здесь не получится никак.

У меня упп 1.3 160 гиговая быстрее летает, чем новёхонькая ут 11 с небольшой кучей документов

(68)у тебя ошибка в логике.
данные для активного чтения должны быть в одной - двух таблицах лучше в виде плоского списка.

(71) Что ты здесь понимаешь под "активным чтением"?

Обработка предназначена для формирования клиентских отчетов. Часть отчетов может быть по клиенту в целом часть - по "стратегиям", это подчиненный справочник. Некоторые отчеты могут быть и по клиенту, и по стратегиям. Соответственно, я делаю дерево, в котором клиенты - строки первого уровня, а стратегии - второго. В дереве наглядно флагами отображается, какие виды отчетов формируются, причем отдельно по клиентам, отдельно по стратегиям, все в соответствующих строках.

Этот список нужен для просмотра только один раз, он формируется автоматически по кнопке после ввода настроек на другой закладке. Таким образом, я подготавливаю данные для дальнейший операций и даю возможность наглядно просмотреть их в разрезе клиентов. Где здесь ошибка в логике?

(63) каким образом Вам удалось обрабатывать дерево значений на клиенте в УФ ?

ДеревоЗначений (ValueTree)
Доступность:
Сервер, толстый клиент, внешнее соединение.

оно там коллекцией элементов