You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/06/22 02:16:22 UTC
AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
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: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
It looks like the code is trying to open a server socket at
port 8080 for some reason.
Sanjiva.
----- Original Message -----
From: "Davanum Srinivas" <da...@gmail.com>
To: <ax...@ws.apache.org>
Cc: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Wednesday, June 23, 2004 8:44 AM
Subject: Re: AXIS-C++ and AXIS-Java performance observations on
Linux/Loopback
> No luck with that either :(
>
> C:\bench>run
> B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
> $) at Tue Jun 22 22:43:15 EDT 2004
> B1> connecting to http://localhost:8080/axis/services/Benchmark1
> runnig test with size=10 Tue Jun 22 22:43:15 EDT 2004
> invoking 3 (SMOKE TEST) times for test v arraysSize=10 Tue Jun 22
> 22:43:15 EDT 2004
> Exception in thread "main" HTTP related exception: could not open
> connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
> java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
> MLogger $Revision: 1.2 $ $Date: 2004/03/16 11:09:19 $ (GMT) configured as
':ALL'
> B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
> $) at Tue Jun 22 22:43:16 EDT 2004
> B1> connecting to http://localhost:8080/axis/services/Benchmark1
> runnig test with size=10 Tue Jun 22 22:43:16 EDT 2004
> invoking 20000 times for test v arraysSize=10 Tue Jun 22 22:43:16 EDT 2004
> [ 02:43:16.605 main:
> xsul.invoker.http.HttpDynamicInfosetInvoker.java:179 invokeXml 1]
> host=localhost port=8080 secure=false
> Exception in thread "main" HTTP related exception: could not open
> connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
> java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
>
> On Tue, 22 Jun 2004 14:27:30 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > Davanum Srinivas wrote:
> >
> > >Alex,
> > >
> > >my axis server is already running at
> > >http://localhost:8080/axis/services/Benchmark1. i don't want to start
> > >a XSOAP4 server. What's the magic incantation? Isn't the following
> > >sufficient?
> > >
> > >
> > that should be sufficient ad it worked for me (but that is not enough
> > of proof)!
> >
> > what is the error you get? can you verify with TCPMon that connection
> > happens and SOAP message is sent?
> >
> > also if you use option -Dlog=:ALL you will see all that is happeening in
> > driver including SOAP message sent, try:
> >
> > java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
> > -Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
> > http://localhost:8080/axis/services/Benchmark1 200000 aa
> > 10,100,1000,5000,10000,25000,50000,75000,100000
> >
> > thanks,
> >
> > alek
> >
> >
> >
> > >
> > >
> > >>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
> > >>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
> > >>http://localhost:8080/axis/services/Benchmark1 200000 aa
> > >>10,100,1000,5000,10000,25000,50000,75000,100000
> > >>
> > >>
> > >
> > >-- dims
> > >
> > >On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
> > ><as...@cs.indiana.edu> wrote:
> > >
> > >
> > >>Davanum Srinivas wrote:
> > >>
> > >>
> > >>
> > >>>Bad News Alex....see stack trace below.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>you will need to specify parameter with the location of running
service
> > >>(in this case it tried to contact localhost:8080)
> > >>
> > >>you can start contained XSOAP4 test service for example by doing this:
> > >>
> > >>cd <place_where_driver_was_unpacked>; source classpath.sh;
> > >>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
> > >>
> > >>thanks,
> > >>
> > >>alek
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> > >>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT
2004
> > >>>Exception in thread "main" HTTP related exception: could not open
> > >>>connection to localhost:8080; nested exception is:
> > >>> Address already in use: connect; nested exception is:
> > >>>java.net.BindException: Address already in use: connect
> > >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
> > >>> at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> > >>> at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> > >>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> > >>> at java.net.Socket.connect(Socket.java:452)
> > >>> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> > >>> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> > >>> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> > >>> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> > >>> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> > >>> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> > >>> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> > >>> at $Proxy0.echoVoid(Unknown Source)
> > >>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> > >>> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> > >>> at
soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> > >>> at soap_bench.BenchClient.main(BenchClient.java:92)
> > >>>
> > >>>
> > >>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> > >>><as...@cs.indiana.edu> 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
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>--
> > >>The best way to predict the future is to invent it - Alan Kay
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
It looks like the code is trying to open a server socket at
port 8080 for some reason.
Sanjiva.
----- Original Message -----
From: "Davanum Srinivas" <da...@gmail.com>
To: <ax...@ws.apache.org>
Cc: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Wednesday, June 23, 2004 8:44 AM
Subject: Re: AXIS-C++ and AXIS-Java performance observations on
Linux/Loopback
> No luck with that either :(
>
> C:\bench>run
> B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
> $) at Tue Jun 22 22:43:15 EDT 2004
> B1> connecting to http://localhost:8080/axis/services/Benchmark1
> runnig test with size=10 Tue Jun 22 22:43:15 EDT 2004
> invoking 3 (SMOKE TEST) times for test v arraysSize=10 Tue Jun 22
> 22:43:15 EDT 2004
> Exception in thread "main" HTTP related exception: could not open
> connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
> java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
> MLogger $Revision: 1.2 $ $Date: 2004/03/16 11:09:19 $ (GMT) configured as
':ALL'
> B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
> $) at Tue Jun 22 22:43:16 EDT 2004
> B1> connecting to http://localhost:8080/axis/services/Benchmark1
> runnig test with size=10 Tue Jun 22 22:43:16 EDT 2004
> invoking 20000 times for test v arraysSize=10 Tue Jun 22 22:43:16 EDT 2004
> [ 02:43:16.605 main:
> xsul.invoker.http.HttpDynamicInfosetInvoker.java:179 invokeXml 1]
> host=localhost port=8080 secure=false
> Exception in thread "main" HTTP related exception: could not open
> connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
> java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
>
> On Tue, 22 Jun 2004 14:27:30 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > Davanum Srinivas wrote:
> >
> > >Alex,
> > >
> > >my axis server is already running at
> > >http://localhost:8080/axis/services/Benchmark1. i don't want to start
> > >a XSOAP4 server. What's the magic incantation? Isn't the following
> > >sufficient?
> > >
> > >
> > that should be sufficient ad it worked for me (but that is not enough
> > of proof)!
> >
> > what is the error you get? can you verify with TCPMon that connection
> > happens and SOAP message is sent?
> >
> > also if you use option -Dlog=:ALL you will see all that is happeening in
> > driver including SOAP message sent, try:
> >
> > java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
> > -Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
> > http://localhost:8080/axis/services/Benchmark1 200000 aa
> > 10,100,1000,5000,10000,25000,50000,75000,100000
> >
> > thanks,
> >
> > alek
> >
> >
> >
> > >
> > >
> > >>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
> > >>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
> > >>http://localhost:8080/axis/services/Benchmark1 200000 aa
> > >>10,100,1000,5000,10000,25000,50000,75000,100000
> > >>
> > >>
> > >
> > >-- dims
> > >
> > >On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
> > ><as...@cs.indiana.edu> wrote:
> > >
> > >
> > >>Davanum Srinivas wrote:
> > >>
> > >>
> > >>
> > >>>Bad News Alex....see stack trace below.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>you will need to specify parameter with the location of running
service
> > >>(in this case it tried to contact localhost:8080)
> > >>
> > >>you can start contained XSOAP4 test service for example by doing this:
> > >>
> > >>cd <place_where_driver_was_unpacked>; source classpath.sh;
> > >>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
> > >>
> > >>thanks,
> > >>
> > >>alek
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> > >>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT
2004
> > >>>Exception in thread "main" HTTP related exception: could not open
> > >>>connection to localhost:8080; nested exception is:
> > >>> Address already in use: connect; nested exception is:
> > >>>java.net.BindException: Address already in use: connect
> > >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
> > >>> at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> > >>> at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> > >>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> > >>> at java.net.Socket.connect(Socket.java:452)
> > >>> at
xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSock
etFactory.java:48)
> > >>> at
xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionMan
ager.java:58)
> > >>> at
xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReus
eLastConnectionManager.java:97)
> > >>> at
xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvo
ker.java:190)
> > >>> at
xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(Soap
HttpDynamicInfosetInvoker.java:122)
> > >>> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInv
ocationHandler.java:170)
> > >>> at
xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler
.java:101)
> > >>> at $Proxy0.echoVoid(Unknown Source)
> > >>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> > >>> at
soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> > >>> at
soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> > >>> at soap_bench.BenchClient.main(BenchClient.java:92)
> > >>>
> > >>>
> > >>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> > >>><as...@cs.indiana.edu> 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
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>--
> > >>The best way to predict the future is to invent it - Alan Kay
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
No luck with that either :(
C:\bench>run
B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
$) at Tue Jun 22 22:43:15 EDT 2004
B1> connecting to http://localhost:8080/axis/services/Benchmark1
runnig test with size=10 Tue Jun 22 22:43:15 EDT 2004
invoking 3 (SMOKE TEST) times for test v arraysSize=10 Tue Jun 22
22:43:15 EDT 2004
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
MLogger $Revision: 1.2 $ $Date: 2004/03/16 11:09:19 $ (GMT) configured as ':ALL'
B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
$) at Tue Jun 22 22:43:16 EDT 2004
B1> connecting to http://localhost:8080/axis/services/Benchmark1
runnig test with size=10 Tue Jun 22 22:43:16 EDT 2004
invoking 20000 times for test v arraysSize=10 Tue Jun 22 22:43:16 EDT 2004
[ 02:43:16.605 main:
xsul.invoker.http.HttpDynamicInfosetInvoker.java:179 invokeXml 1]
host=localhost port=8080 secure=false
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
On Tue, 22 Jun 2004 14:27:30 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Alex,
> >
> >my axis server is already running at
> >http://localhost:8080/axis/services/Benchmark1. i don't want to start
> >a XSOAP4 server. What's the magic incantation? Isn't the following
> >sufficient?
> >
> >
> that should be sufficient ad it worked for me (but that is not enough
> of proof)!
>
> what is the error you get? can you verify with TCPMon that connection
> happens and SOAP message is sent?
>
> also if you use option -Dlog=:ALL you will see all that is happeening in
> driver including SOAP message sent, try:
>
> java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
> -Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
> http://localhost:8080/axis/services/Benchmark1 200000 aa
> 10,100,1000,5000,10000,25000,50000,75000,100000
>
> thanks,
>
> alek
>
>
>
> >
> >
> >>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
> >>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
> >>http://localhost:8080/axis/services/Benchmark1 200000 aa
> >>10,100,1000,5000,10000,25000,50000,75000,100000
> >>
> >>
> >
> >-- dims
> >
> >On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Davanum Srinivas wrote:
> >>
> >>
> >>
> >>>Bad News Alex....see stack trace below.
> >>>
> >>>
> >>>
> >>>
> >>you will need to specify parameter with the location of running service
> >>(in this case it tried to contact localhost:8080)
> >>
> >>you can start contained XSOAP4 test service for example by doing this:
> >>
> >>cd <place_where_driver_was_unpacked>; source classpath.sh;
> >>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
> >>
> >>thanks,
> >>
> >>alek
> >>
> >>
> >>
> >>
> >>
> >>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> >>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
> >>>Exception in thread "main" HTTP related exception: could not open
> >>>connection to localhost:8080; nested exception is:
> >>> Address already in use: connect; nested exception is:
> >>>java.net.BindException: Address already in use: connect
> >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
> >>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> >>> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> >>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> >>> at java.net.Socket.connect(Socket.java:452)
> >>> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> >>> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> >>> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> >>> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> >>> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> >>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> >>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> >>> at $Proxy0.echoVoid(Unknown Source)
> >>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> >>> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> >>> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> >>> at soap_bench.BenchClient.main(BenchClient.java:92)
> >>>
> >>>
> >>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> >>><as...@cs.indiana.edu> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
No luck with that either :(
C:\bench>run
B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
$) at Tue Jun 22 22:43:15 EDT 2004
B1> connecting to http://localhost:8080/axis/services/Benchmark1
runnig test with size=10 Tue Jun 22 22:43:15 EDT 2004
invoking 3 (SMOKE TEST) times for test v arraysSize=10 Tue Jun 22
22:43:15 EDT 2004
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
MLogger $Revision: 1.2 $ $Date: 2004/03/16 11:09:19 $ (GMT) configured as ':ALL'
B1> Starting Benchmark1 Driver Version 1.0 ($Date: 2004/06/17 12:09:59
$) at Tue Jun 22 22:43:16 EDT 2004
B1> connecting to http://localhost:8080/axis/services/Benchmark1
runnig test with size=10 Tue Jun 22 22:43:16 EDT 2004
invoking 20000 times for test v arraysSize=10 Tue Jun 22 22:43:16 EDT 2004
[ 02:43:16.605 main:
xsul.invoker.http.HttpDynamicInfosetInvoker.java:179 invokeXml 1]
host=localhost port=8080 secure=false
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
On Tue, 22 Jun 2004 14:27:30 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Alex,
> >
> >my axis server is already running at
> >http://localhost:8080/axis/services/Benchmark1. i don't want to start
> >a XSOAP4 server. What's the magic incantation? Isn't the following
> >sufficient?
> >
> >
> that should be sufficient ad it worked for me (but that is not enough
> of proof)!
>
> what is the error you get? can you verify with TCPMon that connection
> happens and SOAP message is sent?
>
> also if you use option -Dlog=:ALL you will see all that is happeening in
> driver including SOAP message sent, try:
>
> java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
> -Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
> http://localhost:8080/axis/services/Benchmark1 200000 aa
> 10,100,1000,5000,10000,25000,50000,75000,100000
>
> thanks,
>
> alek
>
>
>
> >
> >
> >>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
> >>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
> >>http://localhost:8080/axis/services/Benchmark1 200000 aa
> >>10,100,1000,5000,10000,25000,50000,75000,100000
> >>
> >>
> >
> >-- dims
> >
> >On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Davanum Srinivas wrote:
> >>
> >>
> >>
> >>>Bad News Alex....see stack trace below.
> >>>
> >>>
> >>>
> >>>
> >>you will need to specify parameter with the location of running service
> >>(in this case it tried to contact localhost:8080)
> >>
> >>you can start contained XSOAP4 test service for example by doing this:
> >>
> >>cd <place_where_driver_was_unpacked>; source classpath.sh;
> >>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
> >>
> >>thanks,
> >>
> >>alek
> >>
> >>
> >>
> >>
> >>
> >>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> >>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
> >>>Exception in thread "main" HTTP related exception: could not open
> >>>connection to localhost:8080; nested exception is:
> >>> Address already in use: connect; nested exception is:
> >>>java.net.BindException: Address already in use: connect
> >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
> >>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> >>> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> >>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> >>> at java.net.Socket.connect(Socket.java:452)
> >>> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> >>> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> >>> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> >>> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> >>> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> >>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> >>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> >>> at $Proxy0.echoVoid(Unknown Source)
> >>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> >>> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> >>> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> >>> at soap_bench.BenchClient.main(BenchClient.java:92)
> >>>
> >>>
> >>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> >>><as...@cs.indiana.edu> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Release date for Axis c++ 1.2 Beta
Posted by sanjaya singharage <sa...@opensource.lk>.
The Axis C++ team is planning to Release Axis C++ 1.2 Beta on the coming
Tuesday of 29th June 2004.
Rounds of testing are being carried out on the Alpha and so far bugs found
have been fixed and the code looks pretty stable.
Additionally, in the 1.2 Beta release xsd:any types in WSDL will be
supported.
02nd July has been decided as the tentative date for the 1.2 final release.
The Axis C++ team.
Release date for Axis c++ 1.2 Beta
Posted by sanjaya singharage <sa...@opensource.lk>.
The Axis C++ team is planning to Release Axis C++ 1.2 Beta on the coming
Tuesday of 29th June 2004.
Rounds of testing are being carried out on the Alpha and so far bugs found
have been fixed and the code looks pretty stable.
Additionally, in the 1.2 Beta release xsd:any types in WSDL will be
supported.
02nd July has been decided as the tentative date for the 1.2 final release.
The Axis C++ team.
Re: seperate generated code in samples/tests
Posted by damitha kumarage <da...@opensource.lk>.
Hi Samisa,
I did this for some of the new test cases I developed.
<sample_folder>/gen_src contains all the tool generated code.
But the deveper may change code in the generated files. Yet he
can only put his own files in <sample_folder>(or any other sub folder)
Let's change to this structure in the existing samples as well.
damitha
On Wed, 2004-06-23 at 08:52, Samisa Abeysinghe wrote:
> Hi All,
> It would be nice to seperate generated source from the written code in samples and tests.
> I used gen_src folder (-o./gen_src option to WSDL2Ws) for some tests.
>
> This would help users to easilty understand what they have to write and what are generated by
> the tool.
>
> Thanks,
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
>
RE: seperate generated code in samples/tests
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Well, why not start with new samles and tests now itself?
Can reoganize existing ones for 1.3. (even doing this for 1.2 makes sence as it improves user
understanding, specially for new users)
Samisa...
--- Susantha Kumara <su...@opensource.lk> wrote:
> Yes This makes it easier to do automated testing. Lets do this for next
> release (1.3) ;)
>
> Susantha
> ---
>
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > Sent: Wednesday, June 23, 2004 8:53 AM
> > To: Apache AXIS C Developers List
> > Subject: seperate generated code in samples/tests
> >
> > Hi All,
> > It would be nice to seperate generated source from the written
> code in
> > samples and tests.
> > I used gen_src folder (-o./gen_src option to WSDL2Ws) for some
> tests.
> >
> > This would help users to easilty understand what they have to
> write
> > and what are generated by
> > the tool.
> >
> > Thanks,
> > Samisa...
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Address AutoComplete - You start. We finish.
> > http://promotions.yahoo.com/new_mail
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
RE: seperate generated code in samples/tests
Posted by Susantha Kumara <su...@opensource.lk>.
Yes This makes it easier to do automated testing. Lets do this for next
release (1.3) ;)
Susantha
---
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Wednesday, June 23, 2004 8:53 AM
> To: Apache AXIS C Developers List
> Subject: seperate generated code in samples/tests
>
> Hi All,
> It would be nice to seperate generated source from the written
code in
> samples and tests.
> I used gen_src folder (-o./gen_src option to WSDL2Ws) for some
tests.
>
> This would help users to easilty understand what they have to
write
> and what are generated by
> the tool.
>
> Thanks,
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
seperate generated code in samples/tests
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi All,
It would be nice to seperate generated source from the written code in samples and tests.
I used gen_src folder (-o./gen_src option to WSDL2Ws) for some tests.
This would help users to easilty understand what they have to write and what are generated by
the tool.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Alex,
>
>my axis server is already running at
>http://localhost:8080/axis/services/Benchmark1. i don't want to start
>a XSOAP4 server. What's the magic incantation? Isn't the following
>sufficient?
>
>
that should be sufficient ad it worked for me (but that is not enough
of proof)!
what is the error you get? can you verify with TCPMon that connection
happens and SOAP message is sent?
also if you use option -Dlog=:ALL you will see all that is happeening in
driver including SOAP message sent, try:
java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
-Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
http://localhost:8080/axis/services/Benchmark1 200000 aa
10,100,1000,5000,10000,25000,50000,75000,100000
thanks,
alek
>
>
>>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
>>http://localhost:8080/axis/services/Benchmark1 200000 aa
>>10,100,1000,5000,10000,25000,50000,75000,100000
>>
>>
>
>-- dims
>
>On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>
>
>>Davanum Srinivas wrote:
>>
>>
>>
>>>Bad News Alex....see stack trace below.
>>>
>>>
>>>
>>>
>>you will need to specify parameter with the location of running service
>>(in this case it tried to contact localhost:8080)
>>
>>you can start contained XSOAP4 test service for example by doing this:
>>
>>cd <place_where_driver_was_unpacked>; source classpath.sh;
>>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
>>
>>thanks,
>>
>>alek
>>
>>
>>
>>
>>
>>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
>>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
>>>Exception in thread "main" HTTP related exception: could not open
>>>connection to localhost:8080; nested exception is:
>>> Address already in use: connect; nested exception is:
>>>java.net.BindException: Address already in use: connect
>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
>>> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
>>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
>>> at java.net.Socket.connect(Socket.java:452)
>>> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
>>> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
>>> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
>>> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
>>> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
>>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
>>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
>>> at $Proxy0.echoVoid(Unknown Source)
>>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
>>> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
>>> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
>>> at soap_bench.BenchClient.main(BenchClient.java:92)
>>>
>>>
>>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
>>><as...@cs.indiana.edu> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Alex,
>
>my axis server is already running at
>http://localhost:8080/axis/services/Benchmark1. i don't want to start
>a XSOAP4 server. What's the magic incantation? Isn't the following
>sufficient?
>
>
that should be sufficient ad it worked for me (but that is not enough
of proof)!
what is the error you get? can you verify with TCPMon that connection
happens and SOAP message is sent?
also if you use option -Dlog=:ALL you will see all that is happeening in
driver including SOAP message sent, try:
java -server -Xmx1024m -Dlog=:ALL -Dtest.setup=YOUR_SETUP_NAME
-Dserver.name=AXIS_JAVA_1_2 soap_bench.BenchClient
http://localhost:8080/axis/services/Benchmark1 200000 aa
10,100,1000,5000,10000,25000,50000,75000,100000
thanks,
alek
>
>
>>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
>>http://localhost:8080/axis/services/Benchmark1 200000 aa
>>10,100,1000,5000,10000,25000,50000,75000,100000
>>
>>
>
>-- dims
>
>On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>
>
>>Davanum Srinivas wrote:
>>
>>
>>
>>>Bad News Alex....see stack trace below.
>>>
>>>
>>>
>>>
>>you will need to specify parameter with the location of running service
>>(in this case it tried to contact localhost:8080)
>>
>>you can start contained XSOAP4 test service for example by doing this:
>>
>>cd <place_where_driver_was_unpacked>; source classpath.sh;
>>/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
>>
>>thanks,
>>
>>alek
>>
>>
>>
>>
>>
>>>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
>>>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
>>>Exception in thread "main" HTTP related exception: could not open
>>>connection to localhost:8080; nested exception is:
>>> Address already in use: connect; nested exception is:
>>>java.net.BindException: Address already in use: connect
>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
>>> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
>>> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
>>> at java.net.Socket.connect(Socket.java:452)
>>> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
>>> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
>>> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
>>> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
>>> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
>>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
>>> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
>>> at $Proxy0.echoVoid(Unknown Source)
>>> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
>>> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
>>> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
>>> at soap_bench.BenchClient.main(BenchClient.java:92)
>>>
>>>
>>>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
>>><as...@cs.indiana.edu> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
Alex,
my axis server is already running at
http://localhost:8080/axis/services/Benchmark1. i don't want to start
a XSOAP4 server. What's the magic incantation? Isn't the following
sufficient?
>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
>http://localhost:8080/axis/services/Benchmark1 200000 aa
>10,100,1000,5000,10000,25000,50000,75000,100000
-- dims
On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Bad News Alex....see stack trace below.
> >
> >
> you will need to specify parameter with the location of running service
> (in this case it tried to contact localhost:8080)
>
> you can start contained XSOAP4 test service for example by doing this:
>
> cd <place_where_driver_was_unpacked>; source classpath.sh;
> /l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
>
> thanks,
>
> alek
>
>
>
> >runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> >invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
> >Exception in thread "main" HTTP related exception: could not open
> >connection to localhost:8080; nested exception is:
> > Address already in use: connect; nested exception is:
> >java.net.BindException: Address already in use: connect
> > at java.net.PlainSocketImpl.socketConnect(Native Method)
> > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> > at java.net.Socket.connect(Socket.java:452)
> > at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> > at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> > at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> > at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> > at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> > at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> > at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> > at $Proxy0.echoVoid(Unknown Source)
> > at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> > at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> > at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> > at soap_bench.BenchClient.main(BenchClient.java:92)
> >
> >
> >On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> 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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
Alex,
my axis server is already running at
http://localhost:8080/axis/services/Benchmark1. i don't want to start
a XSOAP4 server. What's the magic incantation? Isn't the following
sufficient?
>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
>http://localhost:8080/axis/services/Benchmark1 200000 aa
>10,100,1000,5000,10000,25000,50000,75000,100000
-- dims
On Tue, 22 Jun 2004 00:50:00 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Bad News Alex....see stack trace below.
> >
> >
> you will need to specify parameter with the location of running service
> (in this case it tried to contact localhost:8080)
>
> you can start contained XSOAP4 test service for example by doing this:
>
> cd <place_where_driver_was_unpacked>; source classpath.sh;
> /l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
>
> thanks,
>
> alek
>
>
>
> >runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> >invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
> >Exception in thread "main" HTTP related exception: could not open
> >connection to localhost:8080; nested exception is:
> > Address already in use: connect; nested exception is:
> >java.net.BindException: Address already in use: connect
> > at java.net.PlainSocketImpl.socketConnect(Native Method)
> > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> > at java.net.Socket.connect(Socket.java:452)
> > at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> > at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> > at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> > at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> > at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> > at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> > at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> > at $Proxy0.echoVoid(Unknown Source)
> > at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> > at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> > at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> > at soap_bench.BenchClient.main(BenchClient.java:92)
> >
> >
> >On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> 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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Bad News Alex....see stack trace below.
>
>
you will need to specify parameter with the location of running service
(in this case it tried to contact localhost:8080)
you can start contained XSOAP4 test service for example by doing this:
cd <place_where_driver_was_unpacked>; source classpath.sh;
/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
thanks,
alek
>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
>Exception in thread "main" HTTP related exception: could not open
>connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
>java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> at java.net.Socket.connect(Socket.java:452)
> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
>
>
>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
><as...@cs.indiana.edu> 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
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Bad News Alex....see stack trace below.
>
>
you will need to specify parameter with the location of running service
(in this case it tried to contact localhost:8080)
you can start contained XSOAP4 test service for example by doing this:
cd <place_where_driver_was_unpacked>; source classpath.sh;
/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076
thanks,
alek
>runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
>invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
>Exception in thread "main" HTTP related exception: could not open
>connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
>java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> at java.net.Socket.connect(Socket.java:452)
> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
>
>
>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
><as...@cs.indiana.edu> 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
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>smoke test command line:
>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>-Dserver.name=AXIS_JAVA_STREAMING_1_2 -Dsmoke_test
>soap_bench.BenchClient http://localhost:8080/axis/services/Benchmark1
>
>
yes - this "smoke test" is used to determine if service works as
expected (it calls service 3 times and verified results)
>test case command line:
>java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
>-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
>http://localhost:8080/axis/services/Benchmark1 200000 aa
>10,100,1000,5000,10000,25000,50000,75000,100000
>
>
this is real test - complete lis tof test commands used in one run (we
did multiple runs) is in
http://www.extreme.indiana.edu/~aslom/bnp/wsperf/linux_loopback/soapscb_loopback.sh
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
smoke test command line:
java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
-Dserver.name=AXIS_JAVA_STREAMING_1_2 -Dsmoke_test
soap_bench.BenchClient http://localhost:8080/axis/services/Benchmark1
test case command line:
java -server -Xmx1024m -Dtest.setup=RH73_VERONICA_LOOPBACK
-Dserver.name=AXIS_JAVA_STREAMING_1_2 soap_bench.BenchClient
http://localhost:8080/axis/services/Benchmark1 200000 aa
10,100,1000,5000,10000,25000,50000,75000,100000
On Mon, 21 Jun 2004 23:08:47 -0400, Davanum Srinivas <da...@gmail.com> wrote:
>
> Bad News Alex....see stack trace below.
>
> runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
> invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
> Exception in thread "main" HTTP related exception: could not open
> connection to localhost:8080; nested exception is:
> Address already in use: connect; nested exception is:
> java.net.BindException: Address already in use: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> at java.net.Socket.connect(Socket.java:452)
> at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
> at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
> at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
> at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
> at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
> at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
> at $Proxy0.echoVoid(Unknown Source)
> at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
> at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
> at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
> at soap_bench.BenchClient.main(BenchClient.java:92)
>
>
>
>
> On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> 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: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
Bad News Alex....see stack trace below.
runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:452)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
<as...@cs.indiana.edu> 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 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/
more results [Re: AXIS-C++ and AXIS-Java performance observations
on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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
more results [Re: AXIS-C++ and AXIS-Java performance observations
on Linux/Loopback
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Posted by Davanum Srinivas <da...@gmail.com>.
Bad News Alex....see stack trace below.
runnig test with size=10 Mon Jun 21 23:05:56 EDT 2004
invoking 20000 times for test v arraysSize=10 Mon Jun 21 23:05:57 EDT 2004
Exception in thread "main" HTTP related exception: could not open
connection to localhost:8080; nested exception is:
Address already in use: connect; nested exception is:
java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:452)
at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(PlainClientSocketFactory.java:48)
at xsul.http_client.HttpClientConnectionManager.connect(HttpClientConnectionManager.java:58)
at xsul.http_client.HttpClientReuseLastConnectionManager.connect(HttpClientReuseLastConnectionManager.java:97)
at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(HttpDynamicInfosetInvoker.java:190)
at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(SoapHttpDynamicInfosetInvoker.java:122)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(SoapRpcInvocationHandler.java:170)
at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(SoapRpcInvocationHandler.java:101)
at $Proxy0.echoVoid(Unknown Source)
at soap_bench.BenchClient.runOneTest(BenchClient.java:292)
at soap_bench.BenchClient.runTestsForDirection(BenchClient.java:146)
at soap_bench.BenchClient.runTestsForSize(BenchClient.java:125)
at soap_bench.BenchClient.main(BenchClient.java:92)
On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
<as...@cs.indiana.edu> 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/