Web Service Performance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I developed a Web Application that has a Web Service component. I also
created a direct API to the second layer of the Web Service without going
through the Http connection to the Web Service. I noticed that if I make the
calls through the direct API (getting about 4KB of data from disk), it will
take between 100-200 ms. However, if I make the calls via the normal
[WebMethod] Http interface, the same calls takes between 500-700 ms. That
seems excessive since the url is localhost.

Since I am using localhost in the url, I would think that the performance
shouldn't be greatly affected by line speed or is the transfer speed limited
by the line speed even though it is internal? Any ideas why there would be
such a great difference in performance between the direct API call and the
http call?
 
Since I am using localhost in the url, I would think that the performance
shouldn't be greatly affected by line speed or is the transfer speed limited
by the line speed even though it is internal? Any ideas why there would be
such a great difference in performance between the direct API call and the
http call?
Click to expand...

Serialization + wire(normally not noticable for a localhost address) +
Deserialization
 
If your saying the wire shouldn't be much of an issue, then the
serialization/deserialization must be the poorest written code ever since it
adds between 1/4 and 1/2 second to the operation to transmit and receive a
4KB to 8KB data set. To me a poorly wtitten serialization/deserialization
operation shouldn't take more than 5 ms on a 3.0 giga hertz P4 machine. It
still sounds like it is the wire since I'm still in testing on my Windows
2000 Pro which is on a cable modem with 3.0Mb/128Kb external speed. At the
128Kb upload speed (about 12KB), that would explain the extra 1/4 to 1/2
second.
 
We also found web service deserialization to be extremely slow in .net,
especially if you are transferring a lot of data. If you need to update
often, it is best to use TCP/IP if you can (sockets), or direct http if you
cannot.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor
 
serialization is quite fast, except runtime serialization on objects like
datasets.

When request is made, it goes through (i may be wrong with some of these
steps but you will get the picture) HTTP as a POST, IIS passes this to
ASP.NET, ASP.NET runs your CODE, your CODE returns data, the DATA is
serialized as sent to the requestor via HTTP the requestor desterilizes the
OBJECT.

if you want to test serialization on its own, you could do some tests,
also..... web service in general scale better, eg one request may seam slow
but when you start adding load its starts to perform very well compared to
other remote methods.

but..... you should not use SOAP on the same server? why would you do this?

Steve
 
Of course it's very dependant on the parameters you are passing. If these
are complex types (e.g. datasets) then serialisation will be slower.

Ben
 
Also don't measure the first time as you don't want to include assembly load
time (xml, xmlserializer, etc) in your test or avg time. The next ones will
be much faster.
 
Back
Top