Web Services, Overhead and Performance

Earlier this week a friend of mine asked me for some advice over an argument that some developers at his company were having.  They are collecting data from a device, and one developer wanted to have the device send the data to a web service to receive the data.  The other developer thought a web service would be to much “overhead” and wanted a different solution using direct writes or XML to the database and a UDP socket notifier for the server to parse the data.

I didn’t actually speak to the developers myself, but my friend sent me an MSN transcript of their “discussion”.  Apparently tempers grew quite hot!  I did read most of the discussion and spoke with my friend to learn more about the system.

It turns out there would be many transactions with the database and web service coming from these devices with a fair bit of geographic data that had to be processed at the server.  One developer felt that using a web service would  involve too much XML/SOAP overhead and wanted to write his data as XML to the database directly.

I was not in favor of this suggestion.  A web service makes perfect sense in a .NET situation.  It denotes a logical boundary between applications and computers, and would be pretty obvious to any supporting developer what is going on.  Usually two applications do not share the same database (maybe the same server, but not the same database).   This increases complexity.

I was also not convinced that the “overhead” of the SOAP would actually limit the application.  Microsoft has done a lot to optimize web services.  They’re easy to develop now, easy to consume, and as I said: a logical boundary between systems.

In the end I strongly recommended that they do some benchmarking.  This early in the game is the perfect time to test assumptions.  I also recommended using one of the new Service Bus APIs out there that use technologies like Microsoft Message Queues if the web services are too slow.

Also, as Jeff Atwood recommended in his Coding Horror blog, sometimes it is cheaper to throw another $5000 server at the solution (even TWO servers) instead of paying two $70,000 / year developers to spend three-to-six months doing performance enhancements.

One thought on “Web Services, Overhead and Performance”

  1. I think XML/XSD is really a awesome way to store different types of data combining them together. I’m never going back into time, just for performance issue’s. But that said, that doesn’t mean i have to transmit `XML`. PC’s are very cheap as you mentioned. But `new` network infrastucture also are expensive. And you also have to look at your performance graph how quickly you have to buy these new pc’s and infrastructure (Liniair line ?). So: Does this program/sollution scale with the company ? With big companies, now problem. They don’t grow that fast. But small size companies that are around 3 years old, can grow instantly very fast. And at that moment of time there getting problems.

    So i’m implementing my own XMLSerializers (Binary) for some messages. And i’m always going to use protocols like HTTP (WebRequest) or others that have caching mechanisms. So i don’t mind overhead on the client with respect to performance. But network communication with servers and performance on these servers can be a problematic in the future.

    It’s not mutch of work and with a little bit of boiler plate code, you can always handle your communication differently. Thus if your communication is getting a lot of traffic, check if it can be cached. Or send it in a binary kind of format, that is easy to convert to XML/CLR-Objects and back.

    Thanx Eric.

Leave a Reply

Your email address will not be published. Required fields are marked *