I'll admit it:  I'm a big fan of web services.  Whenever I encounter a problem where we need to share data or business logic across multiple development environments (e.g. .Net to Java) or across non-homogeneous hardware (PC to AS/400, for example), I'll suggest using web services.

 

And more or less every time I've suggested them, I get the same responses:  "Oh no, XML is way too slow to parse" or "The SOAP overhead will kill the network."  So, invariablely I'll brew up some prototypes to demonstrate that performance will be altogether acceptable, then move on from there.

 

A few days ago I did a Google search for "web service performance myths" and I was surprised that although I got a bunch of results, very few of them addressed actual, real-world performance metrics for web services.  Yes, XML is (relatively) computationally expensive to parse.  Yes, the SOAP envelope can be many times the size of the actual data payload.  But, how much does that actually affect web service performance? 

 

Let's find out!

 

To start, I created about the most simple web service you could create in C#:

The web service method was purposely made as simple as possible for a couple of reasons:  First, by only passing an int back and forth, the SOAP overhead is maximized as a percentage of the total message size.  Second, by minimizing processing in the method, the processor load we'll see on the server will mainly be due to XML creation and parsing.

 

For the client, I wrote a small, multithreaded C# Windows Forms app that would determine the time it took to repeatedly call the web service and then calculate the number of calls made per second.

 

To get some benchmark numbers, I ran this code on fairly modest hardware:  The server was a 3GHz hypertheaded P4 and the client ran on a 1.6GHz Pentium M laptop.  The server and client were connected with 100Mb/sec ethernet.

 

Without further ado, here's the results:

At maximum throughput with 5 client threads running, it only takes 0.65 ms to create the SOAP envelope, send it to the server, parse the XML, increment the value passed in, re-wrap it in SOAP, return it over the network and parse the XML once again.  Not bad.

 

Here's what I find real interesting: check out the screenshot at the bottom of this post--this is the network usage with 5 client threads at 1,500 calls per second, and it's barely 20% of a 100Mb/sec line.  If we were network bandwidth limited, we could have hit around 7,500 calls per second.  So much for the SOAP overhead being the limiting factor.

 

For this little demo, the limiting factor turned out to be client processing power: at 5 client threads, the processor was pegged the entire time the program ran.  The 3GHz server wasn't pegged, but it was getting close--running at about 75% to support 1,500 calls/sec.  Had I been hitting the server with multiple clients (or a more powerful client), we would have topped out at 2,000 calls/sec before we ran out of server processing bandwidth.

 

But that's not really a hard limit:  since web services are stateless and built on top of HTTP, you can easily add servers behind a load balancer until you finally exhaust network bandwidth.

 

I hope you found this data as enlightening as I did :)

 

Ben

We've been talking a lot about Silverlight at work lately, so last week I installed the Orcas beta and the Silverlight 1.1 alpha tools.  I looked through the sample code (which looks decent), but I find that actually using the tools is the best way for me to find strengths and shortcomings, so I built a little tic-tac-toe game.

 

Actually, let me step back and make a statement:  I hate HMTL apps!  Don't get me wrong, I like their unparalleled scalability and the whole "no deployment" model, but overall HTML is frustratingly simplistic.  It works fine for simple input screens like Google's search, but you're stuck with a couple basic controls (textbox, radio button, listbox, etc) and a client-side scripting language that's, umm....  inconsistently implemented.

 

Also, as an aside, I never quite understood the hype behind AJAX...  yeah, it's nice to be able to talk to the server without having to do a POST or GET, but you're still stuck with the same limited set of client controls.

 

So, for me at least, being able to use XAML instead of HMTL is a huge benefit, and I'm hoping that it's really going to open the door to some neat new things on the web.

 

I have to say that overall I was really pleased with what Microsoft has come up with so far.  The development tools are still incomplete and buggy, but they're good enough that you can create Silverlight content pretty quickly--I was able to get tic-tac-toe working in a couple of hours with no previous Silverlight knowledge.

 

Overall, the whole Silverlight things mimics the ASP.NET model--you've got one file that has the basic control layout defined, and a code-behind page that contains the basic page logic.  The main difference is that instead of generating HTML, you're generating XAML.  You can also implement both client-side and server-side events like you can with ASP.NET, with the option of using IronPython on the client side, woohoo! <-- lots of sarcasm there, when I was at the Microsoft Connections conference they had an IronPython class in one of the huge rooms and... almost nobody went to it :-p

 

The only downside I see thus far is that it's from Microsoft--so you know there will be a vocal minority out there trying to discredit as something evil.  That was one big advantage with Flash, as it was more or less universially accepted since it was a 3rd party product.  But, Flash is now an Adobe product so I think it won't be long before they bloat the heck out of it like they did with the Acrobat Reader.

 

It's going to be interesting to see how it all plays out.

 

Ben