Веб-сервис по сравнению с обычным HTTP-запросом

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

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

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

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

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

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

Веб-службы REST являются HTTP.

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

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

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

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

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

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

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

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

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