Производительность SOAP против XML-RPC или REST

Question

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

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

Answer 1

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

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

Answer 2

REST как протокол не определяет какую-либо форму конверта сообщения, в то время как SOAP имеет этот стандарт.

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

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

Answer 3

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

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

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

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

Answer 4

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

• SO: отдых против производительности мыла
• Q & A: SOAP и REST 101
• Обновленные службы данных SQL Server: загрузка REST и SOAP с помощью Northwind

На форуме MSDN .

есть (несколько устарелый) интересный разговор о производительности.

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

Answer 5

Расширение ответа "pjz".

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

Answer 6

SOAP определенно медленнее. Полезные данные значительно больше, и их сборка, транспортировка, анализ, проверка и обработка медленнее.

Answer 7

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

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

Answer 8

Думаю, главный вопрос здесь - как сравнить RPC с SOAP.

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

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

• это легкий
• Есть много замечательных реализаций для всех языков программирования
• это просто учиться / использовать / создавать
• это быстро (особенно с JSON)

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

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