Доброго времени суток коллеги. Обращаюсь к тем , кто уже сталкивался с проблемой передачи "больших" таблиц на клиента. А именно , ситуация такая :

Есть обработка , которая при открытии показывает справочник номенклатура (около 40 000 поз) , пользователь отмечает необходимые позиции и выбирает процент наценки, по произвольному желанию, и к этим строкам в базе нужно подтянуть "последнюю цену + процент наценки". и отобразить обновленную таблицу (с которой сотрудник работает весь день, т.е. периодически происходит обновление "снуля").

Путем проб и ошибок , была организована кнопка которая , переносит "данныеФормыКоллекция" , размером ~ 26 тыс. строк , и около 20 колонок по 1 типу на колонку (По замерам производительности выдается ~ 10 000 000 как принято , так и отдача), на СерверБезКонтекста. На Сервере (без контекста), эти данные превращаются в ТЗ через "ДанныеФормыВЗначение" подставляются в запрос , происходит выполнение запроса , и далее Результат запроса выгружается обратно в "ДанныеФормыКоллекция" и копируются в реквизит формы на клиенте.

Вроде всё по науке, но загрузка такой таблицы на сервер (и на клиент тоже) происходит порядка 10-15 секунд в одну сторону (Запрос выполняется около 1 секунды). После многочисленных тестов уперся в то , что дело в "Большом" объеме трафика , хотя в обычном приложении это происходит практически мгновенно. Итогом по кнопке "Обновить" платформа уходит в "Неответ" на 25-30 секунд.

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

Перенос таблицы через данные формы - происходит непозволительно долго , получается "Патовая" ситуация. когда "Разделение данных на клиент и сервер" работает в 10-ки раз медленнее чем обычное приложение. В Общем если у кого есть мысли как передавать подобные данные с клиента на сервер и обратно быстрее, помогите плз.

"После многочисленных тестов уперся в то , что дело в "Большом" объеме трафика "

Недотащили..

Дело в долгой сериализации в XDTO.

* P.S. :
Сервер один , находится в Датацентре, пользователи работают по удаленке , скорость интернета по 1 М/бит на пользователя.

Сериализация через FastInfoSet дает выигрыш примерно в 2-3 раза.
Только ТонкийКлиент не работает с FastInfoSet-ом, печаль. Поленились.

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

(4) Я забил и таскаю данные блоками по 10000 строк.

(4) Юзер выбирает, какой блок он обрабатывает.
Для моих 20 колонок это примерно 3-5 секунд задержки.

Основная таблица храниться на сервере в ВХ.

Многие дубли данных свернуты в Хеш.

ясно , видимо только "кусками" ... =( очередной Fail...

или может ещё у кого будут мысли ?

Но причина в другом.
Ладно бы передача, 20 секунд можно подождать, чё.

Я сделал блоками потому что при 100000 строк данныеФормыКоллекция, которая вроде бы на клиенте, при скролле начинает адски тупить сервер 1С. Не стал разбираться.

20 - 30 секунд подождать "обновления" - пользователю , который месяца 2 назад работал на обычном приложении и обновление было 0,5 - 1 секунда , объяснить дескать "подожди уж чё там .. 30 секунд" - обычно проблемно и вызывает кучу негатива от перехода ... на современное "Управляемое приложение".

(11) Это я к тому, что 20 секунд не самое страшное :-)

Ладно, это может у нас старенький xeon 2006 года, тупит, а ваш пока нормально переваривает большую таблицу. Но когда-нибудь ...

директор обещал новый сервак , с рейдом на "SSD" , и оперативой в 128 гб ... надежда только на него ... но если и с ним будет такая задержка ... хоть обратно откатывай Обычное приложение )))

Проблема не в 1с, проблема в голове.
40000 строк юзеру не нужны
Ему нужны инструменты с ними.
Сделайте наглядный инструмент и не отображайте 40000 строк, это бессмысленно.

инструменты работы с ними, конечно же-)

(13) уверен, что и не надо было переходить на УФ... вебклиент, ради которого и устроили этот геморрой нужен 0,01% пользователей, а страдают все.

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

ХранилищеЗначений, у него сжатие есть

(17) предлагаю прежде всего ответить на простой вопрос: сколько строк можно воспринять быстро визуально?
Допустим, юзер может сразу проанализировать целиком экран(пусть это 40 строк).
Между 40 и 40000 очень большая разница.
дальше предлагаю посмотреть, каков сценарий работы пользователя с этими строками и какую задачу он хочет решить своими действиями.
После этого можно предложить вариант, который устроит и тебя, и его.

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

(18) Пофиг.

(18) 1С в клиент-сервере само жмет трафик. Либо deflate-ом, либо своим супералгоритмом.
Тут время уходит на сериализацию.

В толстом клиенте ее нет.

(21) +1

(21) Пробовал?

(19) , предположим , пользователь захотел создать документ из этой таблицы по отбору "Без пометки удаления" и "Поставщик такой-то" , пометок удаления всего 1000 шт из 40 000 + с реквизитом "Поставщик такой-то" тыс 15 ... несмотря на то что отбор будет установлен после начального отображения (т.е. вначале полюбому уже таблицу тащить) , после отбора все равно таблица будет ненамного меньше ... и результат .. клик ~ 20 секунд ожидания ... не айс

(19) , про то что сам документ с такой ТЧ будет открываться ~ 20 сек просто по чтению с сервера... это так сказать расширение проблемы "Контекста"

(23) Что пробовал?

(24) у меня документ на 10000 строк открывается менее чем за 1с.
Да и зачем его сразу открывать? Это по сценарию работы? Опиши его

что касается отборов - они- на форме.
равно как и критерии для отбора.

(0) А почему не юзать ДС?

(28) ДС ? расшифруйте абривиатуру плз.

(24) "Да и зачем его сразу открывать? Это по сценарию работы? Опиши его "

очень напоминает ситуацию с Apple ... "а зачем вам карта памяти ? зачем вам возможность сменить аккумулятор !? .. мы считаем вам это ненужно ..."

(14) +100500

Грустно.
Остается единственное решение - уменьшать кол-во гоняемых строк таблицы.

p.s. запишу в копилку для будущих срачей "УФ vs обычные формы".

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

(29) Динамический список

(29) Динамический список
(32) УФ - для ларька жи.. Для бизнеса (зарабатывания денег) только обычные формы. Если надо удаленно, то только RDP по 150 долл на пожизненную лицензию.

(30) и они правы

40000 строк в gui - это рехнуться можно...

(35) Когда останутся только одни уф, да еще и такси. А ты их знать не будешь. Ты останешься не у дел

(34) (28) - Динамический список не может иметь ВТ , а без них нет никаких ТЗ в запросе , а это не подходит по условию задачи ...

(39) По условию задачи (как я понимаю) функционала запросов ДС достаточно. О каких ТЗ в запросе идет речь?

(33) ты неправ , "По твоей волшебной кнопке надо делать контекстный серверный вызов, а в нем уже выгружать из данных формы в ТЗ. Тут и сериализоваться ничего не будет"

в момент контекстного серверного вызова , у тебя начинается передача ВСЕГо контекста формы (а не только таблицы) на сервер , и при загрузке обратно на форму мы ловим обратную сериализацию (на сервере у нас ТЗ (результат запроса) , и без сериализации на клиенте их не получить (кроме как через ДС , который не имеет ВТ). Таким образом без каких - либо особых циклов на клиенте , мы имеем двустороннюю сериализацию (хотя цикл на самом деле есть , типа установить наценку в выбранных строках , и вобщем то по результатам этих циклов , таблица меняется и далее происходят какие-то действия, например создать заказ поставщику)

(40) => (0) , "пользователь отмечает необходимые позиции и выбирает процент наценки, по произвольному желанию, и к этим строкам в базе нужно подтянуть "последнюю цену + процент наценки". и отобразить обновленную таблицу (с которой сотрудник работает весь день". Таблица - выбранные пользователем строки , по придуманному из головы отбору , с какими то значениями , которые введены на клиенте.

(41) Надеюсь. Ты когда сервер вызываешь внеконтекстно, все переменные ты передаешь по значению?

(43) Даже не все, а только "тяжелые"

(43) при вызове внеконтекстной серв. процедурины - передаю "данныеФормыКоллекция" , одна конкретная таблица , которая сразу падает в запрос

(42) У ДС есть свойство ВыбранныеСтроки, через которые получишь массив ссылок товар. Через ПоказатьВводЧисла вызываешь ввод этой наценки и с массивом в качестве параметра вызываешь безконтекстную процедуру обновления данных наценки.

(45) Она потом лезет обратно, на Клиент, после отработки серверного вызова, если у параметра не поставлено ЗНАЧ. Так и задумано, надеюсь?

(45) , ну на сервере , я в него загружаю ТЗ результат запроса (Через ЗначениеВДанныеФормы) и он в этом виде возвращается на клиент , где копируется на форму.

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

(41) На сервере хранится весь контекст. При контекстном сервером вызове передается не вся форма, а только изменения (с оптимизацией для тонких каналов). Итак, никакой сериализации этой злой таблицы.
На клиент передается только ВИДИМАЯ часть таблицы значений. Это четко отслеживается при пролистывании со включенным счетчиком серверных вызовов. Собственно, это же прямо описано в талмуде про оптимизацию управляемых форм. Таким образом, на клиента так же ничего жуткого не уходит.
Таблицу делаем реквизитом формы. Работаем с данными на сервере. Профит. Никаких жутких вызовов.
На самом деле, за счет этих механизмов сама платформа делает то, о чем говорит Immortal в (19).
Вообще, в серверных вызовах передача массивных параметров - жуткий моветон. В большинстве случаев, выгоднее держать их в реквизитах формы и делать контекстные вызовы.
ПЫСЫ: Вообще, советую пересмотреть смысл существования этой таблицы в 40 тыщ строк. Приятнее вывести на форму те самые фильтры, по которому клиент выполняет поиск, и отражать уже нужные товары, а не злющий список.

(49) Хм, сдаюсь. Через ж*пу, так через ж*пу.

(38) в том-то и дело, что приходится тратить время (читай деньги работодателя) на эту технологию ради технологии. сам, естественно, категорически против, ибо абсолютно никакого профита она не приносит

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

(50)
1) Вы не работали с достаточно большими таблицами.
2) Вы можете продолжать читать мантру "Вам это не надо".

(50) 3) Вы не понимаете, что такое сериализация :-)

Тут проблема явно в дизайне интерфейса. Пользователь просто привык, работая с обычными формами, к тому, что кроме гигантского списка в 40к строк у него ничего нет. И как-то приучил себя бегать по нему туда-сюда. А между тем, если ему дать грамотно спроектированный UI, он мог бы свои задачи решать гораздо эффективнее.

К сожалению, 1С-ников этому не учат.

(56) наверняка можешь предложить на выбор 5 решений, но к сожалению не будешь учить одинэсников

(54) имхо, стремление пользователя к таблицам в тысячи строк - это пережитки работы в Екселе. В 99,999% случаев. Это лечить надо, а не потакать.

(58) , (56) - да , примерно так и есть , но вот что думаю об лечении "хотелок" : если человек привык приносить пользу компании и ему удобнее это делать именно ТАКИМ способом и в таком виде (форма и способ работы обычно складывается из бизнес процессов компании и численности сотрудников) ... то имхо дело 1С-ника , если уж пошли на переход на новую платформу , - реализовать функционал , при котором пользователь уже и без новых "Витков обучений" будет как рыба в воде. ИМХО 1С , всётаки для пользователей , и от их "хотелок" часто зависит бизнес в целом.

(59) Если система внедряется, значит, текущие возможности по автоматизации не устраивают, не?

(59) Не совсем так ) пользователей всё устраивает , была самописка , которая прошла через руки нескольких поколений 1-С-ников. Вопрос в том что никто не значет что и где в этой самописке отрабатывает , но бизнеспроцессы вроде идут. Вот руководство и решило актуализировать "самописку", "Что бы побыстрее и поновее и понятно что для кого и где ..".

(61) => (60)

Загрузи в регистр сведений. Некрасиво, зато будет ДС.

(61) 1C ники пытаются подменить технологическую проблему организационной. Психологическая деформация уровня "я тут самый умный". Понять и забить. Но прощать нельзя.

(63) С разделением по пользователям? Да ты шутник.

(64) нука расскажи нам технологическое решение проблемы?

все-таки сделай регистр сведений. даже несмотря на мнение некоторых "суперспецов" тут на форуме.

это просто из описания логики работы с этой ТЗ вытекает.

Из существующих механизмов (67) самый хорший

(66) Передавать на клиент блоками.
(68) Это "хороший" механизм будет работать ну на 5 пользователях, может быть. А скорее всего и нет.

(67) если по логике 1С что такие таб. должны быть в ДС - тогда наверно да, РС подходит. Но прям как-то не красиво совсем ...
Данные , которые посути хранить ненужно , будут проходить через запись / удаление ... Будем думать ...

(70) Вы попробуйте. Потом напишите.
У вас же несколько пользователей будет работать?

(71) 3-е, в общем попробую оба варианта, потом отпишусь как сделали...
Всем спасибо за участие , у меня по теме всё ).

(70) Если не хранить, то чет не догоняю тогда. Как пользователь может за один раз из 40 тыр наотмечать сразу 26 тыр строк? Не хранить это значит отметить и вывести в отчет. Это не хранить.

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

(73) "Не хранить это значит отметить и вывести в отчет" , примерно так , только не в отчет , а в документ. После чего продолжить работу уже по другому условию , с другими контрагентами ("кому-то на такой-то товар сейчас можно скинуть 5%" и подобное ... маркетологи).

(74) хм. есть мысль, что если вникнуть в задачу более глубоко можно придумать и более красивое решение.

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

(69) в чем проблему видишь?

(76) Проблему вижу в записи 40000 строк и эскалации блокировки на всю таблицу.

(75) могут , это 3 человека с примерно равным функционалом. т.е. все 3-е могут одновременно по той или иной номенклатуре проставить разные значения в одной колонке (т.к. документ уйдет по разным контрагентам и разным договорам).

Да и просто записать 40000 строк - это не секундное дело.

(75) если вникнуть во все тонкости , то наверно было бы наиболее правильно разделить функционал установки условии и отгрузки , в этом случае у нас и история "Кто , что проставил" будет , и сотрудникам вроде как ничего при создании документов  проставлять не надо , а данные по условиям брались из места , где всё это валяется. Но это скорее всего приведет к потребности наёма специально обученного человека , который будет это проставлять , а на "это" идут неохотно (если раньше это делали 3 , то после обновления это будут делать 4+ человека , да ещё и медленнее в 2 раза ))) хорошая оптимизация получается ...)

(61)"Что бы побыстрее и поновее и понятно что для кого и где .."
ахаха. "побыстрее" и "УФ" в одном предложении не надо использовать.
как я и писал выше, руководство решило внедрить трехнологию только ради технологии, без профита для бизнеса.
россиянские бизнесмены такие бизнесмены....

(0) Только мне одному кажется, что в форме должна быть еще одна ТЗ с передачей данных только по изменяемому?

(82) Вариант про ДС на основной список + ТЗ на форме, куда бы писались изменения, введеннные пользователем , а при создании документа - обрабатывать на сервере спр-к номенклатуры + ТЗ измененных данных тоже как вариант на самом деле + условным оформлением выводить текст итоговых значений в нужные колонки ДС'а... попробуем идея неплоха.