axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Date Tue, 22 Jun 2004 05:50:00 GMT
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; 
/l/jdk1.4/bin/java -server -Xmx1024m soap_bench.BenchServer 8076



>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:
> Address already in use: connect
>        at Method)
>        at
>        at
>        at
>        at
>        at xsul.http_client.plain_impl.PlainClientSocketFactory.connect(
>        at xsul.http_client.HttpClientConnectionManager.connect(
>        at xsul.http_client.HttpClientReuseLastConnectionManager.connect(
>        at xsul.invoker.http.HttpDynamicInfosetInvoker.invokeXml(
>        at xsul.invoker.soap_over_http.SoapHttpDynamicInfosetInvoker.invokeMessage(
>        at xsul.soaprpc_client.SoapRpcInvocationHandler.invokeRemoteEndpoint(
>        at xsul.soaprpc_client.SoapRpcInvocationHandler.invoke(
>        at $Proxy0.echoVoid(Unknown Source)
>        at soap_bench.BenchClient.runOneTest(
>        at soap_bench.BenchClient.runTestsForDirection(
>        at soap_bench.BenchClient.runTestsForSize(
>        at soap_bench.BenchClient.main(
>On Mon, 21 Jun 2004 19:16:22 -0500, Aleksander Slominski
><> wrote:
>>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
>>(CVS June 11) and AXIS-C++ 1.2 pre-alpha (CVS May 28), gSOAP 2.6, XSOAP4
>>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].
>>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.
>>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

View raw message