SOAP Performance

[Pat Young <pa...@yahoo.com>]

Would anyone be interested in discussing their
experiences with SOAP performance and the types of
applications they are running?

I am working on a SOAP based reporting system.  The
average results set is 200 rows with 20 columns from a
JDBC data source.  The data source is very quick and
not much of a factor in my tests.  For one user we get
pretty decent results on a single processor, 3GHz
Windows server, which is 1 to 2 seconds per response. 
Things seems to scale fairly well until we get to 8
threads, when we get a response in about 8 seconds. 
At that point our Web server is completely maxed out
and performance gets really slow.  by threads, I mean
JMeter test clients threads that I am using to put a
load on the server.

I know that SOAP servers have to convert all of the
data to a SOAP response and send that result back to
the client.  So is what I am seeing normal, or should
I be expecting better performance?

Pat


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: SOAP Performance

[Aleksander Slominski <as...@cs.indiana.edu>]

Dennis Sosnoski wrote:

> Performance can definitely be a problem with the current frameworks, 
> especially if you're using rpc/enc with the default Axis options. 
> Changing to doc/lit will generally give you better performance 
> (partially because you can reduce the size of the XML messages being 
> exchanged). For some performance comparisons you can see 
> http://www.sosnoski.com/presents/cleansoap/comparing.html
>
> I'd also suggest getting a capture of your data exchange so you can 
> see if there are obvious ways to improve the representation and reduce 
> the message sizes. Even if you're stuck using rpc/enc you may be able 
> to improve performance by disabling multiRefs and xsi:type information 
> in what Axis generates (check the Axis docs or mailing list archive 
> for details on how to do this).

i would also add that older versions of AXIS had problems with hanging 
references in thread context that led to memory bloat, resource 
contention, and sometimes even out of memory exceptions.

in general i think that low memory footprint is way more important than 
how fast you parse a message - it is much worse to run out of memory for 
many clients than just to accept a bit of slowdown for hundreds of 
concurrent clients.
 
also if you have many clients calling web service and it takes non 
trivial amount to compute a response i would strongly recommend either 
async API or at least have an ID that is immediately returned and client 
uses the ID to get results.

for results of experiments (and interpretation of them) with handling 
large number of clients, sync (RPC-style) and async. interactions 
(WS-Addressing) and scalability you may want see your paper: 
http://www.extreme.indiana.edu/xgws/papers/ws_dispatcher_ipdps2005.pdf - 
results in case when endpoints are asymmetrical (such as cable modem 
with much bigger downstream than upstream) are particularly interesting 
foo for thoughts when you consider how to design service for scalability.

best,

alek

>
> Pat Young wrote:
>
>> Would anyone be interested in discussing their
>> experiences with SOAP performance and the types of
>> applications they are running?
>>
>> I am working on a SOAP based reporting system.  The
>> average results set is 200 rows with 20 columns from a
>> JDBC data source.  The data source is very quick and
>> not much of a factor in my tests.  For one user we get
>> pretty decent results on a single processor, 3GHz
>> Windows server, which is 1 to 2 seconds per response. Things seems to 
>> scale fairly well until we get to 8
>> threads, when we get a response in about 8 seconds. At that point our 
>> Web server is completely maxed out
>> and performance gets really slow.  by threads, I mean
>> JMeter test clients threads that I am using to put a
>> load on the server.
>>
>> I know that SOAP servers have to convert all of the
>> data to a SOAP response and send that result back to
>> the client.  So is what I am seeing normal, or should
>> I be expecting better performance?
>>
>> Pat
>>


-- 
The best way to predict the future is to invent it - Alan Kay

Re: SOAP Performance

[Dennis Sosnoski <dm...@sosnoski.com>]

Performance can definitely be a problem with the current frameworks, 
especially if you're using rpc/enc with the default Axis options. 
Changing to doc/lit will generally give you better performance 
(partially because you can reduce the size of the XML messages being 
exchanged). For some performance comparisons you can see 
http://www.sosnoski.com/presents/cleansoap/comparing.html

I'd also suggest getting a capture of your data exchange so you can see 
if there are obvious ways to improve the representation and reduce the 
message sizes. Even if you're stuck using rpc/enc you may be able to 
improve performance by disabling multiRefs and xsi:type information in 
what Axis generates (check the Axis docs or mailing list archive for 
details on how to do this).

  - Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA  425.885.7197



Pat Young wrote:

>Would anyone be interested in discussing their
>experiences with SOAP performance and the types of
>applications they are running?
>
>I am working on a SOAP based reporting system.  The
>average results set is 200 rows with 20 columns from a
>JDBC data source.  The data source is very quick and
>not much of a factor in my tests.  For one user we get
>pretty decent results on a single processor, 3GHz
>Windows server, which is 1 to 2 seconds per response. 
>Things seems to scale fairly well until we get to 8
>threads, when we get a response in about 8 seconds. 
>At that point our Web server is completely maxed out
>and performance gets really slow.  by threads, I mean
>JMeter test clients threads that I am using to put a
>load on the server.
>
>I know that SOAP servers have to convert all of the
>data to a SOAP response and send that result back to
>the client.  So is what I am seeing normal, or should
>I be expecting better performance?
>
>Pat
>