Вопрос по soap, performance, rest, xml-rpc, web-services – Производительность SOAP против XML-RPC или REST

47

Аргументы о простоте решений, использующих XML-RPC или REST, легко понять и с ними трудно поспорить.

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

Ваш Ответ

8   ответов
4

которые медленнее собирать, транспортировать, анализировать, проверять и обрабатывать.

0

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

Я бы всегда предпочел (JSON-) RPC, потому что

it's lightweight there are many great implementations for all programming languages out there it's simple to learn/use/create it's fast (especially with JSON)

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

некоторые подробности, которые вы получаете из этого стекавопрос

2

однако, что я знаю о формате SOAP, так это о да, у него есть накладные расходы, но они не увеличиваются при каждом запросе: если у вас есть один элемент, отправленный в веб-службу , у вас есть накладные расходы + построение одного элемента, и если у вас есть 1000 элементов, отправленных в веб-сервис, у вас есть накладные расходы + конструкция 1000 элементов. Издержки возникают, когда запрос XML отформатирован для конкретной операции, но каждый отдельный элемент аргумента в запросе форматируется одинаково.

Если вы придерживаетесь повторяющихся коротких пакетов данных (скажем, 500 элементов), скорость должна быть приемлемой.

5
Expanding on "pjz" 's answer.

а *), в настоящее время нет способа их кэшировать. Но если бы вы реализовали те же самые операции с использованием REST, есть вероятность, что данные (в зависимости от вашего бизнес-контекста) могут быть кэшированы, как упомянуто выше. Поскольку SOAP использует POST для своих операций, он не может кэшировать информацию на стороне сервера.

19

в то время как SOAP имеет этот стандарт.

Поэтому несколько упрощенно попытаться сравнить их: они - яблоки с апельсинами.

При этом конверт SOAP (за вычетом данных) составляет всего несколько k, поэтому не должно быть заметной разницы в скорости, если вы извлекаете сериализованный объект через SOAP и REST.

Я думаю, что проблема начинается, когда вы пытаетесь считать REST протоколом. REST - это архитектурный стиль, который может использовать протокол HTTP.
Я думаю, что неуместно говорить, что REST не определяет конверт сообщения; он говорит «использовать то, что использует http», то есть mime-types.
Да неужели? Я хочу отправить сериализованный класс C #, как потребитель протокола REST узнает, как анализировать его из MIME-типа.
Я интерпретирую вопрос как «REST» чтобы ссылаться на (как правило) «XML по HTTP»; или (менее часто) «настраиваемый формат по HTTP», и в этом случае сравнение является допустимым вопросом.
@ Тим Купер - Человек, который придумал термин REST, будет категорически не согласен с этим утверждением, как и большинство других, которые помогли распространить информацию о REST. [Читайте больше в Википедии о REST] (помогите продвинуть), чтобы понять, почемуREST !== XML over HTTP.
6

которые были сделаны в отношении этого, которые вы можете найти информативными. Пожалуйста, смотрите следующее:

SO: Rest vs Soap Performance Q&A: SOAP and REST 101 Updated SQL Server Data Services: Northwind REST and SOAP Uploads

Есть также (несколько устаревший) интересный разговор о производительности по теме наФорумы MSDN.

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

8

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

Нечто подобное JSON будет более компактным и, возможно, быстрее сериализованным / десериализованным, но не используйте его исключительно по этой причине. Делайте то, что, по вашему мнению, имеет смысл в то время, и измените его, если это проблема.

Все, что использует HTTP, обычно (если только оно не использует соединение поддержки активности HTTP 1.1, которое не реализовано во многих реализациях) запускает новое соединение TCP для каждого запроса; это довольно плохо, особенно по каналам с высокой задержкой. HTTPS намного хуже. Если у вас много коротких запросов от одного отправителя к одному получателю, подумайте, как вы можете избавиться от этих накладных расходов.

Использование HTTP для любого типа RPC (будь то SOAP или что-то еще) всегда будет сопряжено с такими издержками. Другие протоколы RPC обычно позволяют поддерживать соединение открытым.

63

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

... и теперь вы говорите, что хотите тесты. Ну, с помощью Google, я нашелодин парень тестирование которого показывает, что REST будет в 4-6 раз быстрее, чем SOAP и другоебумага это также способствует ОТДЫХУ.

Отличный ответ pjz, вы поняли, что ваш ответ не имеет ничего общего с XML-RPC или почему он не входит в число лучших вариантов для рассмотрения.
Обновлена ссылка для "одного парня"learnosity.com/techblog/2008/03/cfmx-soap-vs-rest-benchmarks

Похожие вопросы