You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/06/23 01:01:58 UTC

more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

now for client/server where services are hosted over very fast network 
(Grid like environments):
www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/

comments about test results (or additional results) are welcome.

thanks,

alek

Aleksander Slominski wrote:

> hi,
>
> hope you find those results useful in identifying areas in AXIS-Java 
> (memory footprint. performance) and AXIS-C++ (working on bigger sizes) 
> that needs more work and will provide the biggest payoff (bang for 
> buck :) ) - benchmark driver is very flexible and allows to execute 
> only subset of tests to help  timing when trying to fix one aspect only.
>
> i have update the benchmark results page [1] and added new tested 
> services
> so currently there are results for AXIS-Java 1.2 streaming and non 
> streaming
> (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6, 
> XSOAP4 1.1.6-alpha4
>
> tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> using Java HotSpot(TM) Server VM over loopback network
> (that should eliminate any network interferences).
>
> code to reproduce tests results (except gSOAP) is available from [1].
>
>
> Observations
> ----------------
> it seems that AXIS-C++ HTTP transport is very inefficient as even for 
> ping (echoVoid) method
> that has no body payload it was 4x slower than gSOAP or XSOAP4 (and 
> CPU usage is 1/3 indicating
> that there is lot of IO waits or some other blocking ...) - later 
> testing (i may send those results later)
> on real gigabit Ethernet network showed that AXIS-C++ ping is /only/ 
> 2x slower than gSOAP ...
>
> it seems that AXIS-Java has huge memory leak - test was not completed 
> as JVM ran out of memory
> even though it was started with -Xmx1024m (1GB!) and it actually 
> managed not only to take
> all memory but also all swap space leading to machine freezing which 
> is very bad sign
> if you plans to run AXIS-Java based services for this kind of payloads 
> ...
>
> otherwise it seems that gSOAP is the fastest toolkit available and it 
> especially shines when transferring large amount of data. XSOAP4 even 
> though relatively new and in alpha stage is not yet optimized for 
> performance turned out to be surprisingly stable and well performing 
> (as for Java).
>
> comments are welcome.
>
> thanks,
>
> alek
> [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
>


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


Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:

>Axis Java. I am basically unable to run the tests to repro the problem
>- http://marc.theaimsgroup.com/?l=axis-c-dev&m=108795871520281&w=2
>  
>
Dims,

just a second before i leave :)

please download a whole tomcat tarball with *included* axis bench code 
and WSDD i have used for tests:
http://www.extreme.indiana.edu/~aslom/bnp/wsperf/tomcat-4_1_30_AXIS.tgz

thanks,

alek


>-- dims
>
>On Tue, 22 Jun 2004 22:20:53 -0500 (EST), Kenneth Chiu
><ch...@cs.indiana.edu> wrote:
>  
>
>>Alek is off-line till Saturday or so, so don't expect a
>>reply till then.
>>
>>By the way, were you referring to Axis C++ or Java?
>>
>>
>>On Tue, 22 Jun 2004, Davanum Srinivas wrote:
>>    
>>
>>>Alek,
>>>
>>>would you be so kind as to help us pinpoint problems in Axis? This is
>>>exactly the right time to do it as we can try and fix the problems
>>>before 1.2 release.
>>>
>>>Thanks,
>>>dims
>>>
>>>On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
>>><as...@cs.indiana.edu> wrote:
>>>      
>>>
>>>>now for client/server where services are hosted over very fast network
>>>>(Grid like environments):
>>>>www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
>>>>
>>>>comments about test results (or additional results) are welcome.
>>>>
>>>>thanks,
>>>>
>>>>alek
>>>>
>>>>Aleksander Slominski wrote:
>>>>
>>>>        
>>>>
>>>>>hi,
>>>>>
>>>>>hope you find those results useful in identifying areas in AXIS-Java
>>>>>(memory footprint. performance) and AXIS-C++ (working on bigger sizes)
>>>>>that needs more work and will provide the biggest payoff (bang for
>>>>>buck :) ) - benchmark driver is very flexible and allows to execute
>>>>>only subset of tests to help  timing when trying to fix one aspect only.
>>>>>
>>>>>i have update the benchmark results page [1] and added new tested
>>>>>services
>>>>>so currently there are results for AXIS-Java 1.2 streaming and non
>>>>>streaming
>>>>>(CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
>>>>>XSOAP4 1.1.6-alpha4
>>>>>
>>>>>tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
>>>>>Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
>>>>>using Java HotSpot(TM) Server VM over loopback network
>>>>>(that should eliminate any network interferences).
>>>>>
>>>>>code to reproduce tests results (except gSOAP) is available from [1].
>>>>>
>>>>>
>>>>>Observations
>>>>>----------------
>>>>>it seems that AXIS-C++ HTTP transport is very inefficient as even for
>>>>>ping (echoVoid) method
>>>>>that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
>>>>>CPU usage is 1/3 indicating
>>>>>that there is lot of IO waits or some other blocking ...) - later
>>>>>testing (i may send those results later)
>>>>>on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
>>>>>2x slower than gSOAP ...
>>>>>
>>>>>it seems that AXIS-Java has huge memory leak - test was not completed
>>>>>as JVM ran out of memory
>>>>>even though it was started with -Xmx1024m (1GB!) and it actually
>>>>>managed not only to take
>>>>>all memory but also all swap space leading to machine freezing which
>>>>>is very bad sign
>>>>>if you plans to run AXIS-Java based services for this kind of payloads
>>>>>...
>>>>>
>>>>>otherwise it seems that gSOAP is the fastest toolkit available and it
>>>>>especially shines when transferring large amount of data. XSOAP4 even
>>>>>though relatively new and in alpha stage is not yet optimized for
>>>>>performance turned out to be surprisingly stable and well performing
>>>>>(as for Java).
>>>>>
>>>>>comments are welcome.
>>>>>
>>>>>thanks,
>>>>>
>>>>>alek
>>>>>[1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>The best way to predict the future is to invent it - Alan Kay
>>>>
>>>>
>>>>        
>>>>
>>>--
>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>
>>>      
>>>
>
>
>  
>


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


Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:

>Axis Java. I am basically unable to run the tests to repro the problem
>- http://marc.theaimsgroup.com/?l=axis-c-dev&m=108795871520281&w=2
>  
>
Dims,

just a second before i leave :)

please download a whole tomcat tarball with *included* axis bench code 
and WSDD i have used for tests:
http://www.extreme.indiana.edu/~aslom/bnp/wsperf/tomcat-4_1_30_AXIS.tgz

thanks,

alek


>-- dims
>
>On Tue, 22 Jun 2004 22:20:53 -0500 (EST), Kenneth Chiu
><ch...@cs.indiana.edu> wrote:
>  
>
>>Alek is off-line till Saturday or so, so don't expect a
>>reply till then.
>>
>>By the way, were you referring to Axis C++ or Java?
>>
>>
>>On Tue, 22 Jun 2004, Davanum Srinivas wrote:
>>    
>>
>>>Alek,
>>>
>>>would you be so kind as to help us pinpoint problems in Axis? This is
>>>exactly the right time to do it as we can try and fix the problems
>>>before 1.2 release.
>>>
>>>Thanks,
>>>dims
>>>
>>>On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
>>><as...@cs.indiana.edu> wrote:
>>>      
>>>
>>>>now for client/server where services are hosted over very fast network
>>>>(Grid like environments):
>>>>www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
>>>>
>>>>comments about test results (or additional results) are welcome.
>>>>
>>>>thanks,
>>>>
>>>>alek
>>>>
>>>>Aleksander Slominski wrote:
>>>>
>>>>        
>>>>
>>>>>hi,
>>>>>
>>>>>hope you find those results useful in identifying areas in AXIS-Java
>>>>>(memory footprint. performance) and AXIS-C++ (working on bigger sizes)
>>>>>that needs more work and will provide the biggest payoff (bang for
>>>>>buck :) ) - benchmark driver is very flexible and allows to execute
>>>>>only subset of tests to help  timing when trying to fix one aspect only.
>>>>>
>>>>>i have update the benchmark results page [1] and added new tested
>>>>>services
>>>>>so currently there are results for AXIS-Java 1.2 streaming and non
>>>>>streaming
>>>>>(CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
>>>>>XSOAP4 1.1.6-alpha4
>>>>>
>>>>>tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
>>>>>Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
>>>>>using Java HotSpot(TM) Server VM over loopback network
>>>>>(that should eliminate any network interferences).
>>>>>
>>>>>code to reproduce tests results (except gSOAP) is available from [1].
>>>>>
>>>>>
>>>>>Observations
>>>>>----------------
>>>>>it seems that AXIS-C++ HTTP transport is very inefficient as even for
>>>>>ping (echoVoid) method
>>>>>that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
>>>>>CPU usage is 1/3 indicating
>>>>>that there is lot of IO waits or some other blocking ...) - later
>>>>>testing (i may send those results later)
>>>>>on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
>>>>>2x slower than gSOAP ...
>>>>>
>>>>>it seems that AXIS-Java has huge memory leak - test was not completed
>>>>>as JVM ran out of memory
>>>>>even though it was started with -Xmx1024m (1GB!) and it actually
>>>>>managed not only to take
>>>>>all memory but also all swap space leading to machine freezing which
>>>>>is very bad sign
>>>>>if you plans to run AXIS-Java based services for this kind of payloads
>>>>>...
>>>>>
>>>>>otherwise it seems that gSOAP is the fastest toolkit available and it
>>>>>especially shines when transferring large amount of data. XSOAP4 even
>>>>>though relatively new and in alpha stage is not yet optimized for
>>>>>performance turned out to be surprisingly stable and well performing
>>>>>(as for Java).
>>>>>
>>>>>comments are welcome.
>>>>>
>>>>>thanks,
>>>>>
>>>>>alek
>>>>>[1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>The best way to predict the future is to invent it - Alan Kay
>>>>
>>>>
>>>>        
>>>>
>>>--
>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>
>>>      
>>>
>
>
>  
>


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


Re: Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Davanum Srinivas <da...@gmail.com>.
Axis Java. I am basically unable to run the tests to repro the problem
- http://marc.theaimsgroup.com/?l=axis-c-dev&m=108795871520281&w=2

-- dims

On Tue, 22 Jun 2004 22:20:53 -0500 (EST), Kenneth Chiu
<ch...@cs.indiana.edu> wrote:
> 
> Alek is off-line till Saturday or so, so don't expect a
> reply till then.
> 
> By the way, were you referring to Axis C++ or Java?
> 
> 
> On Tue, 22 Jun 2004, Davanum Srinivas wrote:
> > Alek,
> >
> > would you be so kind as to help us pinpoint problems in Axis? This is
> > exactly the right time to do it as we can try and fix the problems
> > before 1.2 release.
> >
> > Thanks,
> > dims
> >
> > On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
> > <as...@cs.indiana.edu> wrote:
> > >
> > > now for client/server where services are hosted over very fast network
> > > (Grid like environments):
> > > www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> > >
> > > comments about test results (or additional results) are welcome.
> > >
> > > thanks,
> > >
> > > alek
> > >
> > > Aleksander Slominski wrote:
> > >
> > > > hi,
> > > >
> > > > hope you find those results useful in identifying areas in AXIS-Java
> > > > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > > > that needs more work and will provide the biggest payoff (bang for
> > > > buck :) ) - benchmark driver is very flexible and allows to execute
> > > > only subset of tests to help  timing when trying to fix one aspect only.
> > > >
> > > > i have update the benchmark results page [1] and added new tested
> > > > services
> > > > so currently there are results for AXIS-Java 1.2 streaming and non
> > > > streaming
> > > > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > > > XSOAP4 1.1.6-alpha4
> > > >
> > > > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > > > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > > > using Java HotSpot(TM) Server VM over loopback network
> > > > (that should eliminate any network interferences).
> > > >
> > > > code to reproduce tests results (except gSOAP) is available from [1].
> > > >
> > > >
> > > > Observations
> > > > ----------------
> > > > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > > > ping (echoVoid) method
> > > > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > > > CPU usage is 1/3 indicating
> > > > that there is lot of IO waits or some other blocking ...) - later
> > > > testing (i may send those results later)
> > > > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > > > 2x slower than gSOAP ...
> > > >
> > > > it seems that AXIS-Java has huge memory leak - test was not completed
> > > > as JVM ran out of memory
> > > > even though it was started with -Xmx1024m (1GB!) and it actually
> > > > managed not only to take
> > > > all memory but also all swap space leading to machine freezing which
> > > > is very bad sign
> > > > if you plans to run AXIS-Java based services for this kind of payloads
> > > > ...
> > > >
> > > > otherwise it seems that gSOAP is the fastest toolkit available and it
> > > > especially shines when transferring large amount of data. XSOAP4 even
> > > > though relatively new and in alpha stage is not yet optimized for
> > > > performance turned out to be surprisingly stable and well performing
> > > > (as for Java).
> > > >
> > > > comments are welcome.
> > > >
> > > > thanks,
> > > >
> > > > alek
> > > > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> > > >
> > >
> > >
> > > --
> > > The best way to predict the future is to invent it - Alan Kay
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Davanum Srinivas <da...@gmail.com>.
Axis Java. I am basically unable to run the tests to repro the problem
- http://marc.theaimsgroup.com/?l=axis-c-dev&m=108795871520281&w=2

-- dims

On Tue, 22 Jun 2004 22:20:53 -0500 (EST), Kenneth Chiu
<ch...@cs.indiana.edu> wrote:
> 
> Alek is off-line till Saturday or so, so don't expect a
> reply till then.
> 
> By the way, were you referring to Axis C++ or Java?
> 
> 
> On Tue, 22 Jun 2004, Davanum Srinivas wrote:
> > Alek,
> >
> > would you be so kind as to help us pinpoint problems in Axis? This is
> > exactly the right time to do it as we can try and fix the problems
> > before 1.2 release.
> >
> > Thanks,
> > dims
> >
> > On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
> > <as...@cs.indiana.edu> wrote:
> > >
> > > now for client/server where services are hosted over very fast network
> > > (Grid like environments):
> > > www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> > >
> > > comments about test results (or additional results) are welcome.
> > >
> > > thanks,
> > >
> > > alek
> > >
> > > Aleksander Slominski wrote:
> > >
> > > > hi,
> > > >
> > > > hope you find those results useful in identifying areas in AXIS-Java
> > > > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > > > that needs more work and will provide the biggest payoff (bang for
> > > > buck :) ) - benchmark driver is very flexible and allows to execute
> > > > only subset of tests to help  timing when trying to fix one aspect only.
> > > >
> > > > i have update the benchmark results page [1] and added new tested
> > > > services
> > > > so currently there are results for AXIS-Java 1.2 streaming and non
> > > > streaming
> > > > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > > > XSOAP4 1.1.6-alpha4
> > > >
> > > > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > > > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > > > using Java HotSpot(TM) Server VM over loopback network
> > > > (that should eliminate any network interferences).
> > > >
> > > > code to reproduce tests results (except gSOAP) is available from [1].
> > > >
> > > >
> > > > Observations
> > > > ----------------
> > > > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > > > ping (echoVoid) method
> > > > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > > > CPU usage is 1/3 indicating
> > > > that there is lot of IO waits or some other blocking ...) - later
> > > > testing (i may send those results later)
> > > > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > > > 2x slower than gSOAP ...
> > > >
> > > > it seems that AXIS-Java has huge memory leak - test was not completed
> > > > as JVM ran out of memory
> > > > even though it was started with -Xmx1024m (1GB!) and it actually
> > > > managed not only to take
> > > > all memory but also all swap space leading to machine freezing which
> > > > is very bad sign
> > > > if you plans to run AXIS-Java based services for this kind of payloads
> > > > ...
> > > >
> > > > otherwise it seems that gSOAP is the fastest toolkit available and it
> > > > especially shines when transferring large amount of data. XSOAP4 even
> > > > though relatively new and in alpha stage is not yet optimized for
> > > > performance turned out to be surprisingly stable and well performing
> > > > (as for Java).
> > > >
> > > > comments are welcome.
> > > >
> > > > thanks,
> > > >
> > > > alek
> > > > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> > > >
> > >
> > >
> > > --
> > > The best way to predict the future is to invent it - Alan Kay
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Kenneth Chiu <ch...@cs.indiana.edu>.
Alek is off-line till Saturday or so, so don't expect a
reply till then.

By the way, were you referring to Axis C++ or Java?

On Tue, 22 Jun 2004, Davanum Srinivas wrote:
> Alek,
>
> would you be so kind as to help us pinpoint problems in Axis? This is
> exactly the right time to do it as we can try and fix the problems
> before 1.2 release.
>
> Thanks,
> dims
>
> On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > now for client/server where services are hosted over very fast network
> > (Grid like environments):
> > www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> >
> > comments about test results (or additional results) are welcome.
> >
> > thanks,
> >
> > alek
> >
> > Aleksander Slominski wrote:
> >
> > > hi,
> > >
> > > hope you find those results useful in identifying areas in AXIS-Java
> > > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > > that needs more work and will provide the biggest payoff (bang for
> > > buck :) ) - benchmark driver is very flexible and allows to execute
> > > only subset of tests to help  timing when trying to fix one aspect only.
> > >
> > > i have update the benchmark results page [1] and added new tested
> > > services
> > > so currently there are results for AXIS-Java 1.2 streaming and non
> > > streaming
> > > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > > XSOAP4 1.1.6-alpha4
> > >
> > > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > > using Java HotSpot(TM) Server VM over loopback network
> > > (that should eliminate any network interferences).
> > >
> > > code to reproduce tests results (except gSOAP) is available from [1].
> > >
> > >
> > > Observations
> > > ----------------
> > > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > > ping (echoVoid) method
> > > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > > CPU usage is 1/3 indicating
> > > that there is lot of IO waits or some other blocking ...) - later
> > > testing (i may send those results later)
> > > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > > 2x slower than gSOAP ...
> > >
> > > it seems that AXIS-Java has huge memory leak - test was not completed
> > > as JVM ran out of memory
> > > even though it was started with -Xmx1024m (1GB!) and it actually
> > > managed not only to take
> > > all memory but also all swap space leading to machine freezing which
> > > is very bad sign
> > > if you plans to run AXIS-Java based services for this kind of payloads
> > > ...
> > >
> > > otherwise it seems that gSOAP is the fastest toolkit available and it
> > > especially shines when transferring large amount of data. XSOAP4 even
> > > though relatively new and in alpha stage is not yet optimized for
> > > performance turned out to be surprisingly stable and well performing
> > > (as for Java).
> > >
> > > comments are welcome.
> > >
> > > thanks,
> > >
> > > alek
> > > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> > >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>

Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Kenneth Chiu <ch...@cs.indiana.edu>.
Alek is off-line till Saturday or so, so don't expect a
reply till then.

By the way, were you referring to Axis C++ or Java?

On Tue, 22 Jun 2004, Davanum Srinivas wrote:
> Alek,
>
> would you be so kind as to help us pinpoint problems in Axis? This is
> exactly the right time to do it as we can try and fix the problems
> before 1.2 release.
>
> Thanks,
> dims
>
> On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > now for client/server where services are hosted over very fast network
> > (Grid like environments):
> > www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> >
> > comments about test results (or additional results) are welcome.
> >
> > thanks,
> >
> > alek
> >
> > Aleksander Slominski wrote:
> >
> > > hi,
> > >
> > > hope you find those results useful in identifying areas in AXIS-Java
> > > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > > that needs more work and will provide the biggest payoff (bang for
> > > buck :) ) - benchmark driver is very flexible and allows to execute
> > > only subset of tests to help  timing when trying to fix one aspect only.
> > >
> > > i have update the benchmark results page [1] and added new tested
> > > services
> > > so currently there are results for AXIS-Java 1.2 streaming and non
> > > streaming
> > > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > > XSOAP4 1.1.6-alpha4
> > >
> > > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > > using Java HotSpot(TM) Server VM over loopback network
> > > (that should eliminate any network interferences).
> > >
> > > code to reproduce tests results (except gSOAP) is available from [1].
> > >
> > >
> > > Observations
> > > ----------------
> > > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > > ping (echoVoid) method
> > > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > > CPU usage is 1/3 indicating
> > > that there is lot of IO waits or some other blocking ...) - later
> > > testing (i may send those results later)
> > > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > > 2x slower than gSOAP ...
> > >
> > > it seems that AXIS-Java has huge memory leak - test was not completed
> > > as JVM ran out of memory
> > > even though it was started with -Xmx1024m (1GB!) and it actually
> > > managed not only to take
> > > all memory but also all swap space leading to machine freezing which
> > > is very bad sign
> > > if you plans to run AXIS-Java based services for this kind of payloads
> > > ...
> > >
> > > otherwise it seems that gSOAP is the fastest toolkit available and it
> > > especially shines when transferring large amount of data. XSOAP4 even
> > > though relatively new and in alpha stage is not yet optimized for
> > > performance turned out to be surprisingly stable and well performing
> > > (as for Java).
> > >
> > > comments are welcome.
> > >
> > > thanks,
> > >
> > > alek
> > > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> > >
> >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>

Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Davanum Srinivas <da...@gmail.com>.
Alek,

would you be so kind as to help us pinpoint problems in Axis? This is
exactly the right time to do it as we can try and fix the problems
before 1.2 release.

Thanks,
dims

On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
> 
> now for client/server where services are hosted over very fast network
> (Grid like environments):
> www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> 
> comments about test results (or additional results) are welcome.
> 
> thanks,
> 
> alek
> 
> Aleksander Slominski wrote:
> 
> > hi,
> >
> > hope you find those results useful in identifying areas in AXIS-Java
> > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > that needs more work and will provide the biggest payoff (bang for
> > buck :) ) - benchmark driver is very flexible and allows to execute
> > only subset of tests to help  timing when trying to fix one aspect only.
> >
> > i have update the benchmark results page [1] and added new tested
> > services
> > so currently there are results for AXIS-Java 1.2 streaming and non
> > streaming
> > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > XSOAP4 1.1.6-alpha4
> >
> > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > using Java HotSpot(TM) Server VM over loopback network
> > (that should eliminate any network interferences).
> >
> > code to reproduce tests results (except gSOAP) is available from [1].
> >
> >
> > Observations
> > ----------------
> > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > ping (echoVoid) method
> > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > CPU usage is 1/3 indicating
> > that there is lot of IO waits or some other blocking ...) - later
> > testing (i may send those results later)
> > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > 2x slower than gSOAP ...
> >
> > it seems that AXIS-Java has huge memory leak - test was not completed
> > as JVM ran out of memory
> > even though it was started with -Xmx1024m (1GB!) and it actually
> > managed not only to take
> > all memory but also all swap space leading to machine freezing which
> > is very bad sign
> > if you plans to run AXIS-Java based services for this kind of payloads
> > ...
> >
> > otherwise it seems that gSOAP is the fastest toolkit available and it
> > especially shines when transferring large amount of data. XSOAP4 even
> > though relatively new and in alpha stage is not yet optimized for
> > performance turned out to be surprisingly stable and well performing
> > (as for Java).
> >
> > comments are welcome.
> >
> > thanks,
> >
> > alek
> > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: more results [Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback

Posted by Davanum Srinivas <da...@gmail.com>.
Alek,

would you be so kind as to help us pinpoint problems in Axis? This is
exactly the right time to do it as we can try and fix the problems
before 1.2 release.

Thanks,
dims

On Tue, 22 Jun 2004 18:01:58 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
> 
> now for client/server where services are hosted over very fast network
> (Grid like environments):
> www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_xeon_sc/
> 
> comments about test results (or additional results) are welcome.
> 
> thanks,
> 
> alek
> 
> Aleksander Slominski wrote:
> 
> > hi,
> >
> > hope you find those results useful in identifying areas in AXIS-Java
> > (memory footprint. performance) and AXIS-C++ (working on bigger sizes)
> > that needs more work and will provide the biggest payoff (bang for
> > buck :) ) - benchmark driver is very flexible and allows to execute
> > only subset of tests to help  timing when trying to fix one aspect only.
> >
> > i have update the benchmark results page [1] and added new tested
> > services
> > so currently there are results for AXIS-Java 1.2 streaming and non
> > streaming
> > (CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6,
> > XSOAP4 1.1.6-alpha4
> >
> > tests were run on Linux Red Hat 7.3, Dell Optiplex GX 260T,
> > Pentium 4 1.8 GHz 512 MB, JDK 1.4.2 (build 1.4.2_04-b05, mixed mode)
> > using Java HotSpot(TM) Server VM over loopback network
> > (that should eliminate any network interferences).
> >
> > code to reproduce tests results (except gSOAP) is available from [1].
> >
> >
> > Observations
> > ----------------
> > it seems that AXIS-C++ HTTP transport is very inefficient as even for
> > ping (echoVoid) method
> > that has no body payload it was 4x slower than gSOAP or XSOAP4 (and
> > CPU usage is 1/3 indicating
> > that there is lot of IO waits or some other blocking ...) - later
> > testing (i may send those results later)
> > on real gigabit Ethernet network showed that AXIS-C++ ping is /only/
> > 2x slower than gSOAP ...
> >
> > it seems that AXIS-Java has huge memory leak - test was not completed
> > as JVM ran out of memory
> > even though it was started with -Xmx1024m (1GB!) and it actually
> > managed not only to take
> > all memory but also all swap space leading to machine freezing which
> > is very bad sign
> > if you plans to run AXIS-Java based services for this kind of payloads
> > ...
> >
> > otherwise it seems that gSOAP is the fastest toolkit available and it
> > especially shines when transferring large amount of data. XSOAP4 even
> > though relatively new and in alpha stage is not yet optimized for
> > performance turned out to be surprisingly stable and well performing
> > (as for Java).
> >
> > comments are welcome.
> >
> > thanks,
> >
> > alek
> > [1]  http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/