Стоимость сериализации в веб-сервисе - PullRequest
Новая
       4

Стоимость сериализации в веб-сервисе

3 голосов
/ 05 октября 2010

Мой следующий проект связан с созданием API данных в рамках предприятия.Данные будут использоваться несколькими приложениями, работающими на разных программных платформах.Хотя мои коллеги обычно предпочитают SOAP, я бы хотел использовать архитектуру RESTful.

Большинству приложений потребуется только несколько объектов при каждом вызове.Однако другим приложениям иногда нужно будет сделать несколько последовательных вызовов, каждый из которых включает тысячи записей.Я беспокоюсь о производительности.Сериализация / десериализация и использование сети - вот где я боюсь найти узкое место.Если каждый запрос связан с большой задержкой, все корпоративные приложения будут вялыми.

Реальны ли мои опасения?Будет ли проблема с сериализацией в такой объемный формат, как XML или JSON?Существуют ли альтернативы?

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

Хотя я предпочел бы ответы, относящиеся к REST, мне интересно услышать, как пользователи SOAP могут с этим справиться.

Ответы [ 3 ]

2 голосов
/ 05 октября 2010

Одним из преимуществ REST является то, что вы можете свободно использовать любой тип носителя, который вам нравится.Почему бы не продолжать использовать текст / CSV?Вы также можете включить HTTP-сжатие, чтобы еще больше снизить пропускную способность.

Службы REST отлично подходят для использования всех различных форматов данных.Какой бы формат ни подходил для вашего сценария.

1 голос
/ 05 октября 2010

Мы предлагаем как XML, так и JSON.Ваше упомянутое время рендеринга действительно может быть проблемой.На стороне сервера у нас есть JAXB, чья стандартная реализация на солнце немного медленная, когда дело доходит до маршала XML.У XML есть недостаток в многословности, но он также хорош в совместимости и имеет схему + явное управление версиями.

Мы компенсировали многословие несколькими способами (особенно ограничив набор результатов):

  • Если у вас есть контейнер с элементами, предложите подкачку в своем xml-ответе (как размер страницы, так и номер страницы, например, / items? Page = 0 & size = 3).Клиент сам может уменьшить размер, уменьшив размер страницы.
  • Предложите сворачивающиеся элементы, например, несколько клиентов интересуются только одним полем данных всего элемента.Сделайте это с параметром (например, / items? Select = name), тогда только вложенный элемент 'name' будет включен в строку вашего элемента item.Это резко уменьшает размер.

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

Также используйте сжатие, это значительно сокращает многословный XML (в нашем случае полезная нагрузка уменьшилась в 10 раз).Со стороны клиента вы можете сделать это с помощью заголовка «Accept-Encoding: gzip».Если вы используете Apache, конфигурация сервера также проста

0 голосов
/ 05 октября 2010

Я хотел бы предложить три правила:

  1. Одним из них является наблюдение, что существует множество веб-сервисов SOAP (особенно созданных с использованием технологии .NET 2.0 "ASMX"), которые отправляют свои объекты передачи данных , сериализованные в XML.Конечно, есть много сервисов RESTful, которые отправляют XML или JSON.Сериализация / десериализация XML редко является сдерживающим фактором.
  2. Одной из распространенных причин узких мест в веб-службах является интерфейс, который побуждает клиентские приложения получать данные, выполняя эти тысячи последовательных вызовов (для этого есть термин: болтливый интерфейс).Это то, чего вам следует избегать при разработке интерфейса вашего веб-сервиса, независимо от того, с каким четырехбуквенным сокращением вы решите продолжить.
  3. Одна вещь, которую следует помнить о REST, это то, что он (частично) обозначает передачуof state, который может не подходить для некоторых операций, когда вы не хотите передавать состояние бизнес-объекта с сервера на клиентское приложение.В этих случаях веб-служба SOAP (как предлагают ваши коллеги) является более подходящей;или, возможно, комбинация служб SOAP и REST, где службы REST позаботятся об операциях, когда передача состояния является подходящей, а службы SOAP выполнят остальные (каламбур непреднамеренные :-)) операций.
...