Re: SOAP performance

David Orchard wrote:

>It's hard to really evaluate these things without more data.  
>
hi,

i agree but i think it is valuable to make efforts to characterize what 
factors are important for SOAP toolkit performance - we did some work on 
that in [1] although we concentrated mostly on scientific computing - we 
have plans for more in future especially related to scalability, memory 
footprint, and optimizations (and we welcome comments about it!).

also one should consider that there can be big gains *if* you know the 
structure of XML messages and optimize infrastructure for those messages 
(like FIX protocol) and/or have  tools to generate very fast  "schema 
specific" parsing (such as generating schema specific parsing code 
executed by automata described in [2])

>What was
>the cpu load on the slow machine that was doing compression?  What is
>the relationship between cpu speeds on the compression/decompression
>machines and the round trip time?  
>  
>
when we were doing our evaluation of use of SOAP toolkits in scientific 
computing most of interactions for high performance toolkits was 
CPU-bound when done over fast network and compression would only slow 
down them - in other words they were CPU bound not IO bound  (you can 
reproduce it by running our tests [3]).

>FWIW, I don't think it surprising that certain CPU speeds make
>compression worse.  IMO, the more important question is what is the
>relationship between cpu and network speed? 
>
i think that there are two ends of spectrum: very fast local network and 
WAN with low bandwidth (modem) and huge bandwidth but noticeable 
latencies (intercontinental links or space :)).

> And there's also the
>relationship between client versus server cpu and encryption/decryption.
>Imagine that decompression is "cheap" compared to compression, then it
>might be that a telco could upgrade is servers to do compression on
>messages to clients, and thus compression is a net benefit to the
>system.
>  
>
that i think will depend on bandwidth usage - i do not think this a big 
deal for broadband users but may be big win for mobile/modem users 
especially if mobile users have to pay for bandwidth usage (Europe?) ...

alek

[1] Madhusudhan Govindaraju, Aleksander Slominski, Kenneth Chiu, Pu Liu, 
Robert van Engelen, Michael J. Lewis, Toward Characterizing the 
Performance of SOAP Toolkits 
<http://www.extreme.indiana.edu/xgws/papers/soap_perf_char_grid2004.pdf>. 
To appear in the proceedings of the 5th IEEE/ACM International Workshop 
on Grid Computing, (short paper) November 8th, 2004, Pittsburgh, USA.
[2] Kenneth Chiu and Wei Lu. A Compiler-Based Approach to 
Schema-Specific XML Parsing. 
<http://wam.inrialpes.fr/www-workshop2004/ChiuLu.pdf> In First 
International Workshop on High Performance XML Processing(Satellite of 
WWW2004), May 2004.
[3] http://www.extreme.indiana.edu/xgws/soap_bench/


>>-----Original Message-----
>>From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf
>>    
>>
>Of
>  
>
>>Francis McCabe
>>Sent: Tuesday, October 26, 2004 12:08 PM
>>To: Michael Champion
>>Cc: David Booth; Robert James Steele; www-ws@w3.org
>>Subject: Re: SOAP performance
>>
>>
>>I guess that those pointy brackets are expensive!
>>But, really, is this a surprise?
>>
>>(I was mildly surprised at the result re. compression: it makes things
>>worse)
>>
>>Frank
>>
>>On Oct 25, 2004, at 2:32 PM, Michael Champion wrote:
>>
>>    
>>
>>>On Oct 25, 2004, at 5:13 PM, David Booth wrote:
>>>
>>>      
>>>
>>>>
>>>>Sounds interesting.  Is there a URL for it?
>>>>
>>>>
>>>>        
>>>>
>>>http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html
>>>
>>>
>>>      
>>>
>
>
>
>  
>


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