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 10:51:25 GMT
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
<aslom@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
> ><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
> 
> 


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

Mime
View raw message