Как ускорить сериализацию и транспорт для больших графов объектов; WCF 3.5 и SL3

Question

У меня есть проект 3.5 SP1, сервис WCF, который ограничен потреблением клиентов Silverlight 3. В связи с бизнес-требованиями нам приходится работать с большими графами объектов, которые гидратируются через SQL Server на стороне WCF и затем отправляются клиенту Silverlight. Они глубокие, у вас может быть класс, который имеет два свойства коллекции, и у каждого элемента в коллекции есть коллекции. Фундаментальный дизайн - это то, что есть, то, что я унаследовал и должен работать в течение короткого срока. Насколько большой мы говорим? Пример коллекции верхнего уровня с 250 элементами после сериализации составляет 14 МБ при передаче по проводу без каких-либо модификаций (httpBinding и DataContractSerializer). 250 предметов - это мало, требования, с которыми мы сталкиваемся, требуют, чтобы мы были в состоянии работать с более чем 10000 предметов, что, учитывая мои ограниченные математические навыки, превышает 500 МБ, чтобы тянуть через провод. Без прогулки в парке - на самом деле - вы, вероятно, могли бы прогуляться в парке, пока он сбивал.

Итак, есть несколько вещей, которые мы рассматриваем, одна из них - отойти от DataContractSerializer и использовать XmlSerializer, чтобы мы могли переместить множество этих свойств в атрибуты и уменьшить размер полезной нагрузки. Мы также смотрим на двоичные XML-привязки.

У меня такой вопрос, что бы вы сделали? Может ли сжатие IIS играть роль здесь? Отходить от DCS плохая идея? Есть ли лучшая техника? Я до ручья без весла?

Answer 1

Как уже говорили другие, посмотрите, нужно ли вам передавать этот объем данных.

Лучший способ отправки больших объемов данных - использовать потоковую передачу, см .:

http://msdn.microsoft.com/en-us/library/ms733742.aspx

Answer 2

Вам абсолютно нужно , чтобы снять все эти данные за один раз? Если это приложение Silverlight, я не вижу, чтобы вы физически отображали более 10000 (или даже 250) записей размера, который вы описываете. Можно ли использовать пейджинг для уменьшения объема данных, передаваемых по проводам?

Вместо 10 000+ можно показывать 10-20 записей на страницу, поэтому система запрашивает только 10-20 в зависимости от обстоятельств.

Не уверен, если это вариант для вас, учитывая требования, которые вы описываете, но это, кажется, самое очевидное решение для меня.

---

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