WCF - возвращение больших изображений - ваш опыт и советы по этому вопросу

Question

Мы используем сервисный слой WCF для возврата изображений из репозитория. Некоторые изображения цветные, многостраничные, почти все в формате TIFF. Мы испытываем медлительность - одна из многих проблем.

1.) Какой у вас был опыт возврата изображений через WCF? 2.) Есть ли у вас какие-либо советы по возврату больших изображений? 3.) Все сообщения сериализуются через SOAP правильно?
4.) wcf плохо сжимает большие файлы tiff?

Спасибо всем!

Answer 1

Ладно. Для того, чтобы подтвердить ответы ZombieSheep и Seba Gomez, вам обязательно нужно посмотреть потоковую передачу данных. Тем самым вы можете легко интегрировать GZipStream в процесс. На стороне клиента вы можете изменить процесс сжатия и преобразовать поток обратно в желаемое изображение.

При использовании потоковой передачи можно выбрать количество классов, которые можно использовать в качестве параметров / возвращаемых типов, и вам необходимо изменять привязки повсеместно.

Вот сайт MSDN о включении потоковой передачи. - это страница MSDN, которая описывает ограничения для потоковых контрактов.

Я предполагаю, что вы также контролируете код на стороне клиента, это может быть очень сложно, если вы этого не делаете. Я использовал потоковую передачу только тогда, когда у меня был контроль над сервером и клиентом.

Удачи.

Answer 2

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

Я где-то читал, что даже если вы установите для TransferMode значение «Потоковое», если вы не работаете ни с самим потоком, ни с сообщением, ни с реализацией IXmlSerializable, сообщение не передается в потоке.

Обязательно имейте это в виду.

Answer 3

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

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

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

Answer 4

Какие привязки вы используете? У WCF будут некоторые накладные расходы, но если вы используете basic-http с MTOM, вы потеряете большую часть перечитанного base-64. У вас все еще будут заголовки и т. Д.

Другим вариантом было бы (подождите ...) не использовать здесь WCF - возможно, просто обработчик (ashx и т. Д.), Который возвращает двоичный файл.

Повторное сжатие - сам WCF не будет сильно влиять на сжатие; транспорт может, особенно через IIS и т. д. с включенным gzip - однако изображения печально известны тем, что их трудно сжать.

Answer 5

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

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

Мы начали с рефакторинга метода тремя способами.

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

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

Method3 вызывается для завершения запроса, когда Method2 сообщает, что чтение носителя запроса завершено. Это освобождает выделенные ресурсы.

Этот подход практичен, потому что вы можете немедленно дать пользователю обратную связь о ходе операции. У вас есть бонус, который заключается в разделении запросов на Method2 в разных потоках. Прогресс, о котором может сообщить чанк, как это делают некоторые клиенты BitTorrent.

---

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

---

Если проблема с производительностью не устранена, рассмотрите возможность упаковки результатов с использованием GZipStream или прочитайте о кодировщиках сообщений и обратите особое внимание на двоичный механизм и механизм оптимизации передачи сообщений (MTOM). 1039 *