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

вызовов серверной процедуры с учетом времени серверных процедур - 4.3 сек, без учета - 3.7 сек

то есть как я понимаю
сам вызов (1 оператор) идет 3.7 сек
серверный код 0.6 сек

чего я не так делаю?

зы
НаСервереБезКонтекста использовать не вариант из-за текущей архитектуры формы, причины этой архитектуры здесь обсуждать не хочу...

так там может этого контекста тонны....
снифером если посмотреть сколько данные передается при выполнении этого вызова?

кроме соболезнований чего еще ждешь при такой простановке вопроса?

формируй жэтот документ как-то по-другому

Может попробовать использовать &НаСервереБезКонтекста?

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

Видел я одну конфу для мфо, не знаю кто ее писал, но она была монструозной, в плохом смысле. Вот там все было ещё хуже я бежал оттуда

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

(5) у меня самое тяжелое это табличный документ примерно на 300..500 строк и 20 столбцов

(7) Именно этот табдок таскается(создается) при этом медленном контекстном вызове?

(7) У тебя точно на всех командах одинаковые серверные вызовы с передачей контекста формы?
Может в остальных командах вызовы процедур серверных общих модулей, а только в этом именно серверная процедура в модуле формы?

(0) Что-то я не врубился как замер сделан. Отладка на сервере включена?
"серверный код 0.6 сек" этот результат замера, или твоя интерпретация?

(8) да создается он

(9) завтра посмотрю, а то на память не помню

(10) это значение в результате замера,
кстати завтра попробую замерить не все скопом а только то, что на сервере

(0) Слишком много данных тянешь из клиента на сервер.

Попробуй передавать поменьше (грубо только ссылку на текущий объект) а побольше получать сразу на сервере из базы.

(13)+ Не забыть про условие что тек. объект должен быть записан в базу перед печатью.

Вот если это нечто вроде не записываемого объекта (не документ а обработка) то тут уже хз как.

Ну и другие варианты возможны.
Может при том самом вызове с табдоком в процедуру передаются тяжелые параметры, какая-нибудь таблица формы, упакованная в массив структур. Если в ней 100500 строк, то они мгновенно на сервер не уползут.
Или может в тех других процедурах перед передачей на сервер происходит очистка тяжелых данных формы. Например, известная же тема, что для заполнения ТЧ на сервере надо сначала сделать ТЧ.Очистить() на клиенте и только потом использовать серверный вызов.

(12) Скинь обработку штоле. или cf
[email protected]

(14) это у меня обработка для пакетного создания документов
(16) обработка не имеет смысла, она из самописки завязана на собственные метаданные, а слать сф не могу

(17) Ну я хотя бы посмотрю ленивым взглядом.

(7) может тормозит как раз передача(возврат) ТД, а другие вызовы делаются при пустом ТД

(19) Типа уже частично заполненный ТД передается с клиента на сервер для дозаполнения?

(20) другие вызовы (возможно) делаются при пустом ТД, а при этом вызове на сервер уходит пустой ТД, а обратно уже заполненный и именно здесь тормоза.

(0) Есть такое, большие табличные документы могут по минуте гоняться. Гоняйте их через временное хранилище - поможет 100%.

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

(23) Плохо, что не разобрался.

(23) v8: Табличный документ, тонкий клиент и производительность.

(24) Ок, завтра гляну ЗиК, там это сплошь и рядом :)
Но у вас немного другая была ситуация - на форме элемента необходимо отобразить данные, а у меня в печатной форме такая засада была. Все нюансы уже не вспомню...

Тяжёлый контекст формы может тормозить серверные вызовы, не используй ТЧ

ПоместитьВоВременноеХранилище - присутствует?

посмотрел повнимательнее, походу у меня тормоза из-за переменной типа "соответствие", это кеш для формирования табдока в нем я храню уже сформированые куски табдока.

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

&НаСервере

мКешПоСтатьям = КешПоСтатьям.Получить();
//что-то делаю
КешПоСтатьям = Новый ХранилищеЗначений(мКешПоСтатьям);

может есть какой нормальный способ хранить переменную на сервере без передача в контексте?

В параметрах сеанса?

(29) это форма какого ОБъекта? Навскидку - ее надо бы в реквизиты объекта прицепить, который связан по умолчанию с открытой формой и тогда ее реквизит окажется в контексте сервера.

(29) "хранить переменную на сервере" - временное хранилище же.

(31) перенос из реквизитов формы в реквизиты объекта ровным образом ничего не меняет, так-же медлено...

(29) реквизит АдресВХранилище, и сохраняй свой кэш во ВременномХранилище

короче пока сделал через ВременноеХранилище - все стало значительно лучше...

(35) Это не объясняет, почему остальные процедуры не тормозили. Они же тоже этот кэш туда-сюда гоняют.

(36) как я понимаю они не гоняют, почему - не знаю...

сейчас то, что раньше занимало 4 сек, сейчас занимает 0.7 сек

(37) Возможно, гоняется только то, к чему идет обращение. Обращения нет - нет и тормозов.

Возможно диффы гоняются

(39) Т.е. 1Ска отслеживает, что если кэш поменялся на клиенте, он будет отправлен на сервер, и если поменяется и там, то будет отправлен обратно на клиент?
Умная какая

(37) без текстов модуля тут вообще не о чем рассуждать

(40) скорее хэшь сумма кэша изменилась - значит повторно кэшировать пора