Платформа 1С 8.3.3.715
PostgreSQL 9.2.1-1.1C(x64)
Конфигурация Управление торговлей 11.


При работе в клиент-серверном варианте возникают проблемы в производительности связанные
с переходом из процедур исполняющихся на клиенте в процедуры исполняющиеся на сервере и обратно.

Например, есть процедуры заполняющие таблицы формы данными.

//////////////////////////////////
&НаКлиенте
Процедура ЗаполнитьСписок()

    ЗаполнитьСписокНаСервере();

КонецПроцедуры

&НаСервере
Процедура ЗаполнитьСписокНаСервере()

    ТЗ = ПолучитьТаблицуДанных();
    ЗначениеВДанныеФормы(ТЗ,Список);

КонецПроцедуры
//////////////////////////////////

Здесь "Список" это реквизит управляемой формы тип "Таблица знчений". Замер производительности показывает,
что весь этот код выполняется примерно за 30 секунд, при этом функция ПолучитьТаблицуДанных()
выполняется 2 секунды,а ЗначениеВДанныеФормы(ТЗ,Список) выполняется 1 секунду.
Остальное время занимает переход из клиентской процедуры ЗаполнитьСписок()
в серверную процедуру ЗаполнитьСписокНаСервере() и обратно. Причем обратно
дольше, поскольку таблица "Список" к этому моменту уже заполнена (порядка 16000 строк).

При использовании директивы &НаСервереБезКонтекста, переход между процедурами происходит моментально,
но в такой процедуре естественно реквизиты формы не доступны, а передать реквизит "Список" как параметр,
нельзя из-за ошибки "Нельзя изменять поле, содержащее объект данных формы".


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

http://infostart.ru/public/198264/

попробуй обойтись без контекста

(2) спасибо, с помощью инструкций препроцессора удалось выполнить весь код на клиенте, но разумеется только в толстом клиенте. Весь код теперь выполняется за 3 сек, а не 30.

Но толстый клиент не есть хорошо, потому что клиентские процессы вертятся на одном компе в терминале,а ОЗУ толстый клиент жрет почти в 5-10 раз больше, чем тонкий.

Оставлю это на крайний вариант.

Может еще кто нибудь что нибудь посоветует))

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

(0) а на 8.2 такого не замечал? Имхо, 1северный вызов контекстный на 1600 строк должен быть не хуже внеконтекстного и заполнения на клиенте. И еще:ты случаем программно там форму не меняешь, видимость там какую?

(5) на 8.2 не замечал, потому что не рабтал с ней в клиент серверном варианте, это мой первый опыт, и так получилось что поставили сразу 8.3.
Настройки видимости присутсвуют, это как то отражается на скорочти перехода с клиерта на сервер и обратно?

Меня собственно интересует почему этот переход с клиента на сервер и обратно вызывает такие дикие тормоза, даже в случае если клиент, сервер 1с и SQL стоят на одном компьютере. Где узкое место? И вообще физически откуда и куда передаются данные и почему так медленно? Почему если весь код выполнить на клиенте он выполняется в за 3 секунды? С клиента обратится в базу данных SQL и выбрать 16000 строк быстрее чем выбрать их на сервере и передать на клиент. Может есть что почитать на эту тему?

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

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

(9)+ контекст - он в две стороны передается