передача временной таблицы с клиента на сервер

[gl00mie]

Цитата:

Сообщение от S.Kuskov

Почему таки нельзя просто взять и скопирования буфер временной таблицы так же как строку или контейнер?

Если говорить о передаче по сети объекта "по значению", то в любом случае будут передаваться какие-то данные, представляющие объект. Соотв., объект нужно уметь сериализовать (представить в виде потока данных - бинарных или того же XML) и десериализовать (из потока данных воссоздать представление объекта в памяти). В этом плане те же объекты-коллекции имеют готовые механизмы сериализации/десериализации - экземплярный метод pack() и статический create(), аналогично обстоит дело с классами, реализующими SysPackable. Их можно запаковать на одной стороне в контейнер, "чохом" передать его и распаковать (воссоздать) на другой стороне. Временные таблицы тут отличаются лишь тем, что у них нет собственного механизма сериализации/десериализации, поэтому приходится приделывать им костылики.

Цитата:

Сообщение от S.Kuskov

Я лишь хотел убедится, что "НЕ элементарные" типы передать за один/два RPC вызова нельзя.

При передаче объекта "по значению" все зависит от того, поместится ли его сериализованное представление в один/два RPC-пакета или нет.

[S.Kuskov]

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

Буфер временной таблицы это сложный объект, который в общем случае может быть представлен в памяти не одной последовательнойстью байт а несколькими и поэтому требует операции сериализации для передачи по значению? AndyD?

[AndyD]

Временные таблицы - это не только сами данные.
Не забывайте про метаданные и индексы, связанные с ними.
Кроме того, таблица может находится не только в памяти, но и на диске.

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

Во-первых, непонятна сама структура этих индексов, насколько они привязаны к текущему положению табицы в памяти и затем на диске. Т.е., можно ли их перенести на противоположную сторону без пересоздания.
Во-вторых, размеры этих индексов могут быть сопоставимы или больше, чем сами данные. Например, для DAX2009RU7, размер выделяемой памяти под InventTable (заполнял ItemId и ItemName, есть много добавленных полей) в два раза меньше, чем под InventDim (заполнял InventDimId и InventLocationId, некоторые поля отключены в конфигурации) при одном и том же количестве вставленных записей

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

Хотя, мне на самом деле не понятно - зачем нужна передача с клиента на сервер таблицы целиком? Точнее, зачем изначально создавать таблицу на клиенте? Почему нельзя создать временную таблицу на сервере, а заполнять еще уже на клиенте?

[S.Kuskov]

Цитата:

Сообщение от AndyD

Хотя, мне на самом деле не понятно - зачем нужна передача с клиента на сервер таблицы целиком? Точнее, зачем изначально создавать таблицу на клиенте? Почему нельзя создать временную таблицу на сервере, а заполнять еще уже на клиенте?

Ну так для сокращения Chattiness же ...

[AndyD]

Цитата:

Сообщение от S.Kuskov

Ну так для сокращения Chattiness же ...

Мне не понятен сам класс задач, который решают подобным образом.

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

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

[fed]

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

[AndyD]

Цитата:

Сообщение от fed

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

Эм.
Я правильно понимаю, что речь идет о выводе данных на стороне клиента (через запросы с группировками)?

[fed]

Цитата:

Сообщение от AndyD

Эм.
Я правильно понимаю, что речь идет о выводе данных на стороне клиента (через запросы с группировками)?

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

[vanokh]

Цитата:

Сообщение от fed

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

Именно такой тупой отчет и оптимизировал Группировки на сервере сократили время выполнения в разы.
От предложенной версии OLAP и/или SSRS заказчик отказался (((

Также тестировал передачу записи по одной (вместо контейнера) - общее время примерно то же самое (5 мин для 100тыс записей). Похоже все-таки это не один вызов RPC, а та же самая куча...

Также пробовал сериализовать в XML - траффик растет примерно раз в 10 + много времени тратится на сериализацию-десериализацию (для тех же 100 тыс. было около 15 мин, если не ошибаюсь)

[AndyD]

Цитата:

Сообщение от fed

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

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

[fed]

Цитата:

Сообщение от AndyD

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

Потому что во многих случаях, эту таблицу просто не будут группировать и сортировать. А учитывая что зачастую клиенты работают через тормозной WiFi, чуть большее быстродействие AOS (по сравнению с клиентским рабочим местом), будет начисто убито медленной и печальной перекачкой таблицы по одной записи, если пользователь попробует по ней побровзится. Ну то есть - я не уверен что во всех случаях перекачка контейнером выгодна, но поскольку она мне несколько раз заметно помогла, а ее использую по умолчанию так сказать...