axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: AXIS-C++ and AXIS-Java performance observations on Linux/Loopback
Date Tue, 22 Jun 2004 03:08:47 GMT
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
<aslom@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/

Mime
View raw message