Partager via

Are web services too slow?

  • Article

I spend a lot of my time with professional developers building systems on .NET,  discussing various architectural and design issues. One of my focuses as the moment is web services, and one of the topics that comes up on a fairly regular basis, when discussing web services, is the issue of speed.

 

Typically the question is couched in terms of “web services sound quite interesting, but they seem like they will be a bit slow, and speed is important to us”. Some people will then go on to tell you they have written their own special application protocol, to get the most speed out of their application.

 

So, are web services too slow? The short answer is no. The slightly longer answer? Read on….

 

So why do people think web services might be too slow. A lot of it seems to stem from the use of all those angle brackets – there seems to be some aversion to them – that and the “verbose” text that is the typical serialisation of an XML Infoset on to the wire. It is this very openness – as opposed to the opacity of say a DCOM ORPC wire level packet - that gives web services it great interoperability.

 

I think it was Pat Helland who likened XML to the cardboard packaging that we are all familiar with when we get good delivered - yes, it may be a little bulky and bigger than the item it is transporting, but its role is to help ensure that the package gets delivered to the right place safely. By and large, most of us are happy with that set up. Well, those angle brackets serve the same purpose for your application payload in a web service call.

 

However, text and angled brackets is not the only format for serialising an XML infoset – Indigo supports an optimised binary format that Don Box mentions in his Why Indigo? : The Five Minute Challenge blog. “[We] don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast” .

 

Another aspect to the web services speed issue is the assumption developers have that web services are bound to be the bottleneck. Why? Any sort of network call means latency, but are web services the bottleneck here? Not really. Yes, there is obviously a cost associated with the serialisation/de-serialisation, and the latency when the packet is on the wire, but how does that manifest itself to users – the perceived latency in the way the application handles the network calls versus the actual latency? A well designed application and judicious use of threads / asynchronous web service calls can help enormously, whatever you put on the wire.

 

There is also the issue of the application level protocol, and whether it is too chatty. This is a tougher one, but if you had a chatty interface that makes lots of calls, then you are going to be susceptible to speed issues irrespective of the protocol you use.

 

Architects and systems designers that go through this process of investigation do usually come to the conclusion that all the benefits afforded by web services – openness, cross industry support, interoperability, developer tool support, etc etc – more than make up for any issues (real or perceived) around speed.

 

In my next blog I will tackle the issue of moving large amounts of data using web services – an area where some advice and guidance is often needed, and a blog topic in its own right.

Comments

  • Anonymous
    October 22, 2004
    Hmm, interesting, could you maybe elaborate on this some, Why are people thinking they are to slow? What are these problems people are complaining about?

    I have heard this before, people say oh no use remoting, speed, speed, speed.

    However, I got to tell you I have been using Web services here at a fortune 500 global company, I can push and pull data all over the world faster than most people can blink. I have a web service in Belgium. Yeah, it was slow, it was integrating with a legacy Progress Database, it was the database that was slow. I put in caching of the data noticable speed jump and now no user complains about speed.

    Scalable, this one web service went from being local Belgium only, to All Europe Locations, To All US location, with our US location going Ohh I want that here. To now opened up to our Customers. Web services to me are a godsend. Ok I am not moving megs of data per method call, only 10kb up to maybe 500 kb a method call but sometimes hundreds of calls per minute but that is the intention, maybe it is just me, but there are things like paging data, and so on. I guess I am not seeing what all these performance problems are that I keep hearing so much about, you might have a SQL server directly attached to an application making queries, are you really going to be returning megs of rows per query at a time or are you going to page it, why not same thing with web services?

    So anyway can you please explain to me why people think this performance is an issue? Why is this an issue, what are people trying to do with this data? Yes if you put in timers they are slower, but slower is a relative term, we are talking a hundred or so milliseconds to get data from belgium to the US not seconds from at least from my experimentation. Oh, and our China and Korean location getting data back to the US is faster, but they have better bigger pipes back here.
  • Anonymous
    October 22, 2004
    Web services are surely somewhat limited in terms of "scalability". COM is quite clever; I can make in-process calls, same-machine different process calls, and different machine, different process calls, and I don't have to care too much about it. Remote calls just have higher latency.

    As such, in spite of COM being a "lower-level" protocol (describing, as it does, things like v-table layouts and so on), it offers, thanks to DCOM, in some sense a higher level of abstraction.

    I personally like location transparency, though I know some don't. Web services--by concentrating so much on transport issue--seem to deny me that possibility.
  • Anonymous
    October 22, 2004
    Obviously, network latency can be an issue with WS. HTTP compression helps a lot with this issue.

    We're all using HTTP compression with WS? Right? Right?
  • Anonymous
    May 31, 2009
    PingBack from http://woodtvstand.info/story.php?id=3247