SOAP Performance...
2 posts in topic
Flat View  Flat View

Posted By:   Dan_Kozin
Posted On:   Wednesday, June 5, 2002 07:40 PM


I am doing some performance analisys on my SOAP service, and I am seeing some very suprising times. It takes almost a full second for me to call and get back a response from my service. The reason it is suprising is that the similar RMI call takes only about 30 msec. The data that is marshalled and sent over the wire is not that big, a vector of about 50 objects(Strings, ints, longs).

My client and my soap service are running on a different machines on the same lan. My rpc servlet is running within the websphere4 container.

Is it normal?


Re: SOAP Performance...

Posted By:   ulf_paulsson  
Posted On:   Tuesday, June 11, 2002 05:18 AM

Well the reason for the latency is due to the fact that Axis (at least Beta 1) has a very poor implementation in the handling of TCP communication. The response from the server is divided in two HTTP packets. The delays for the ACKs are on average 350 milliseconds. Then the clients waits for the server to close the socket. This takes on average 370 millisecs.

Build your own client that parses the content_length from the HTTP header and read that number of bytes from the stream and then close the socket from the client.

This should reduce the response time.

Or use HTTP 1.1.



Re: SOAP Performance...

Posted By:   Ara_Abrahamian  
Posted On:   Saturday, June 8, 2002 11:06 AM


I've done some benchmarks on WAS4 and Sun's Xml-RPC and from what I've seen SOAP is at least 2 times slower in simplest calls than RMI/IIOP. If you increase the complexity and weight of the envelope you'll see it gets a lot slower, 10-20 times and so on. What I've seen is that for most normal cases (transfering an object with 20-30 fields of various types) it's around 3 times slower, but completely acceptable since it's only some msecs more costly. It's interesting to know that it's damn slow for arrays. Imho it's all about de/marshaller and if you write your own then it should be a lot faster.


About | Sitemap | Contact