Hi,
About 5000 computers will be making a call to a central server, and they will be passing in a GUID to the central server.
The server will then return True/False back to the client.
Is there a big difference in performance between a web service and a regular Http request to a Url on the server?
I am not 100% sure on a performance benefit in response time, but a WebService request that returns just the true false, rather than a regular http request and then parsing the response I'm guessing would be more efficient overall.
I have an app that currently has about 7000 machines calling a .net web service using WCF.
Each machine makes the call once every 15 minutes. The service takes the data and shoves it into SQL server; which is installed on the same box.
Right now it's collecting about 350MB of data a day.
The load is barely registering and we're in the process of rolling it out to 25,000 clients.
I guess my point is that passing a guid to the server with a true / false value coming back is not a whole lot of load to be worried about unless the web server was a POS 5 years ago.
I would think the difference wouldn't much if any difference. The HttpRequest may actually be faster just because its using one less layer in the stack. If you see yourself expanding the services in the future, you might go ahead and use WebSerivce, not because of performance (again the performance difference is probably negligible), but because the WebService is going to be more maintainable as services get more complex.
REST web services are HTTP.
Consequently, I don't understand the question. Perhaps you should provide more information on the protocol, the messages, whether it's RPC-style or document-style, how big the document is, etc.
I assume by Web Serivce you mean SOAP. My experience with various SOAP stacks on different platforms (Java, .NET, Ruby, PHP) is that in this case you're probably looking at an order of magnitude difference in processing such a simple message. There's usually a good deal of overhead with SOAP, which is negligible if you're passing large messages, but overkill for small messages. Using SOAP for this is like an elephant carrying a penny. I would recommend just a simple HTTP handler in this case.
Are all 5000 clients going to be hitting the server at one time? Do you need to guarantee a certain response time?
Yeah, a SOAP envelope is relatively hefty. I'd suggest a REST-based service that will keep the size of data being marshaled around to a minimum.
SOAP and REST Web Services imply some overhead, but are certainly the way to go if you think you'll need to scale up to returning some other information other than true/false.
An HTTP response of just 1/0 or true/false will be much smaller, and therefore theoretically faster.
Realistically it won't make much difference. Out of the things that could introduce latency in this request you have:
Even if you have a blindingly fast network and database server, the amount of time spent doing the the network round trip and database access (which possibly may involve another network round trip) will render the overhead of executing the compiled code of whatever web service framework you use insignificant.