Веб-сервис против обычного запроса Http

Question

Около 5000 компьютеров будут звонить на центральный сервер, и они будут передавать GUID на центральный сервер.

Сервер вернет True / False обратно клиенту.

Есть большая разница в производительности между веб-сервисом и обычным Http-запросом к URL на сервере?

Answer 1

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

Answer 2

Полагаю, под Web Serivce вы имеете в виду SOAP. Мой опыт работы с различными стеками SOAP на разных платформах (Java, .NET, Ruby, PHP) заключается в том, что в этом случае вы, вероятно, наблюдаете разницу в порядке обработки таких простых сообщений. С SOAP обычно приходится много накладных расходов, что незначительно, если вы передаете большие сообщения, но излишне для небольших сообщений. Использование SOAP для этого похоже на слона с копейкой. В этом случае я бы порекомендовал простой обработчик HTTP.

Все ли 5000 клиентов будут одновременно подключаться к серверу? Вам нужно гарантировать определенное время ответа?

Answer 3

REST web services являются HTTP.

Следовательно, я не понимаю вопроса. Возможно, вам следует предоставить больше информации о протоколе, сообщениях, будь то RPC-стиль или стиль документа, насколько большой документ и т. Д.

Answer 4

Реально это не будет иметь большого значения. Из всего, что может привести к задержке в этом запросе:

• Выполнение скомпилированного кода
• Сетевые туры
• Доступ к базе данных (предположительно, вы будете проверять это?)

Даже если у вас есть ослепительно быстрая сеть и сервер базы данных, количество времени, затрачиваемое на обход сети и доступ к базе данных (что, возможно, может потребовать другого обхода сети), приведет к накладным расходам на выполнение скомпилированного кода любого типа. каркас веб-сервиса, который вы используете незначительный.

Answer 5

SOAP и REST Web Services подразумевают некоторые накладные расходы, но, безусловно, это правильный путь, если вы считаете, что вам нужно увеличить масштаб до возврата другой информации, отличной от true / false.

HTTP-ответ, равный всего 1/0 или true / false, будет намного меньше и, следовательно, теоретически быстрее.

Answer 6

Я думаю, что разница не будет большой, если будет какая-либо разница. HttpRequest на самом деле может быть быстрее только потому, что в стеке используется на один слой меньше. Если вы планируете расширять сервисы в будущем, вы можете пойти дальше и использовать WebSerivce не из-за производительности (опять-таки разница в производительности, вероятно, незначительна), а потому, что WebService будет более удобен в обслуживании по мере усложнения услуг. 1001 *

Answer 7

У меня есть приложение, которое в настоящее время имеет около 7000 компьютеров, вызывающих веб-службу .net с использованием WCF.
Каждый аппарат совершает звонок каждые 15 минут. Служба берет данные и помещает их в сервер SQL; который установлен на той же коробке.

Сейчас он собирает около 350 МБ данных в день.

Загрузка едва регистрируется, и мы находимся в процессе развертывания ее для 25 000 клиентов.

Полагаю, моя точка зрения заключается в том, что передача guid на сервер с возвращением значения true / false не является большой нагрузкой, о которой стоит беспокоиться, если веб-сервер не был POS 5 лет назад.

Answer 8

Я не уверен на 100% в выигрыше в производительности во времени ответа, но запрос WebService, который возвращает только истинное ложное значение, а не обычный HTTP-запрос, и затем анализ ответа, который, как я предполагаю, будет в целом более эффективным. 1001 *