On my travels I get asked the simple question many times ... "are web services fast"?
I usually answer by showing the above graphic. Back when I started on Web Services in 2002, the answer was no. As you can see over 5 years, the answer has definitely changed to "it depends".
I say "it depends" with a little sarcasm. Obviously the performance shown in this chart tells you web services performs. However, in practice I find misuses of performance data and/or web services.
The first thing to be wary of is people trying to prove web services aren't viable are folks using "Hello World" string in/string out web services compared to legacy communication protocol xyz. I usually ask such folks how many distributed services in their architecture are string in string out with such small payloads. The answer is none. Usually the service uses complex industry standard schemas and has a small payload in with a large payload out. The above graph therefore is based on a 3k input document using banking industry standard schemas with a 10k output document.
The second thing to be wary of is primitive web services testing. The above graph is an example of primitive web services testing. This is because my team works on optimizing web services. It shows very clearly the impact of web services calling services that have zero business logic. If we optimize the performance of this primitive we will help in all scenario using web services. However, for customers you need to understand that when you add business logic, the performance impact of web services is far less of a concern. To accurately gauge performance impacts of web services in your application, I would suggest a measuring a vertical slice of your entire application, starting at the web service interface, then calling business logic, and finally any database logic. Comparing that vertical slice between web services and legacy communication protocol xyz is a useful comparison.
Lastly, don't replace every legacy communication protocol xyz in every application with web services. Web Services has been documented by almost every vendor to be useful when the service calls are coarse grained. Replacing "services" with calls that are under 1k of input with 1k of output (example a string in, a simple bean out) isn't usually a good idea. Reusable services in a SOA (for example) are typically much larger in payloads as they tend to be calling services that are not fine grained in payload or function.
Now, you may be asking two questions ...
1) How did we improve the performance over the years
2) What is the performance story for 2007 and the new Web Services Feature Pack?
I think those are two good posts to add in the next week or two ...
