axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
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 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
><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
>>
>>
>>    
>>
>
>
>  
>


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


Mime
View raw message