вторник, 5 октября 2010 г.

WCF transfer large DataSet or DataTable

В WCF достаточно проблемно организована работа с большими объемами данных. Например, передача большого DataSet упирается в: сериализацию, ограничения на размер буфера и размер пакета и т.д.

Если у вас гоняются через WCF сервис действительно большие таблицы, то вам может понадобится решение «Transfer gigantic DataTables over WCF / .Net Remoting» которое лежит на Codeplex.

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

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

Авторы утверждают что:

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

2.       Улучшает пропускную способность до 75% (WCF с передачей DataTable может передавать со скоростью 3154 Кб/с, а такое решение – 12245 Кб/с).

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

Меня сметили в реализации следующие вещи:

1.       Открытие дополнительного ServiceHost выглядит не очень. Скорей тут нужно публиковать отдельный сервис, который будет висеть постоянно. Так можно будет не привязываться к хостам, которыми в ряде случаев (например при хостинге на IIS мы не управляем).

2.       Регулировать размер возвращаемых данных нужно относительно того, какие квоты выставлены для сервиса.

3.       Использовать не только Binary сериализацию, и не только net.tcp. Все таки для инета это тоже может очень хорошо работать.

В итоге: идея жизнеспособная, но решение надо прорабатывать под конкретные нужды.

Posted via email from Комуникликабельность

Комментариев нет: