axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <cyrille.lecl...@pobox.com>
Subject Re: Generated Stub Thread-safe?
Date Tue, 24 Jan 2006 10:47:57 GMT
By the way Neil,

If you want high performance invocations, you can also have a look at
CommonsHTTPSender. It uses a pool of http persistent connections
(keep-alive).

http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP

Cyrille
PS : my first name is Cyrille, not Cedric :-)

--
Cyrille Le Clerc
cyrille.leclerc@pobox.com
cyrille.leclerc@fr.ibm.com

On 1/24/06, Ferguson, Neil, VF-NZ <Neil.Ferguson@vodafone.com> wrote:
> Hi Cedric.
>
> I've done some tests with both pooled stubs and non-pooled stubs
> (instantiating the stub object on every call), and as you say there's
> absolutely no difference (I did a test run of 1000 calls on each). This
> surprises me, but just goes to show that you should always test before
> optimising.
>
> Thanks for your help.
>
> Neil.
>
> -----Original Message-----
> From: cyrille.leclerc@gmail.com [mailto:cyrille.leclerc@gmail.com] On
> Behalf Of Cyrille Le Clerc
> Sent: Tuesday, 24 January 2006 2:01 a.m.
> To: axis-user@ws.apache.org
> Subject: Re: Generated Stub Thread-safe?
>
>
>    Hello Neil,
>
>    I agree with you on the point that if stubs are caching ser/deser
> classes, it implies that these stubs were intended to be reused.
>
>    However, I have re-run my micro benchmark with a "real life" stub (13
> types in the WSDL) and the cost of instantiating stubs still seems
> negligible. With jdk-1.5.0_06, instantiation of 1 serviceLocator + 10
> 000 complex stubs took 220 ms against 70 ms with simple helloWorld
> stubs.
>
>    I conclude that, thanks to JVM optimizations, complex Stubs remain
> lightweight objects to instantiate.
>
>    The gain of pooling stubs would be in micro seconds. I expect it to
> be negligible in front of the cost of a soap over http call.
>
>    Moreover, if you decide to pool the stubs, there is an additional
> complexity of cleaning stubs when they are returned to the pool (calling
> Stub.clearHeaders() and Stub.clearAttachments() ).
>
>    I expect that in most cases, the end-to-end gain of performances will
> not justify this increase of complexity.
>
>    On the other side, I would be interested in contributing to a
> modification of the Axis stubs architecture to optimize their
> instantiation (turning the cachedSerXXX variables into statics). If this
> can take place in the Axis 1.X roadmap (remembering that Axis 2.0 is the
> major focus nowadays) ...
>
>    Hope this helps,
>
>    Cyrille
>
> --
> Cyrille Le Clerc
> cyrille.leclerc@pobox.com
> cyrille.leclerc@fr.ibm.com
> 06.61.33.69.86
>
> On 1/22/06, Ferguson, Neil, VF-NZ <Neil.Ferguson@vodafone.com> wrote:
> > Hi guys.
> >
> > This is very useful, thanks.
> >
> > This definitely shows that I should cache the service locator. From
> > looking at the tests there doesn't seem to be any doubt about that.
> >
> > As for the stub, I haven't performed any performance tests, but from a
>
> > brief look at the source code it doesn't look like a particularly
> > lightweight object to me. It caches all of the type information for
> > the service on instantiation. Of course, the cost of instantiating the
>
> > stub will be very dependent on the complexity of the service it's
> > generated against. That could be one reason why Cyrille's tests showed
>
> > instantiating the stub to be relatively inexpensive (The stub is
> > called HelloWorldBindingStub and I'm guessing it has one method with
> > no params that returns a String -- correct me if I'm wrong!).
> >
> > Also, since the stub is doing all this caching it kind of implies that
>
> > a stub instance is meant to be reused (for purposes other than
> > maintaining a client-side session I would think).
> >
> > Perhaps the best method is for me to cache a reference to the service
> > locator, and pool my stub instances. Each thread will get a unique
> > stub instance from the pool (or create one if it's not available).
> >
> > Regards.
> >
> > Neil.
> >
> > -----Original Message-----
> > From: cyrille.leclerc@gmail.com [mailto:cyrille.leclerc@gmail.com] On
> > Behalf Of Cyrille Le Clerc
> > Sent: Saturday, 21 January 2006 12:27 a.m.
> > To: axis-user@ws.apache.org
> > Subject: Re: Generated Stub Thread-safe?
> >
> >
> >    Hello Chris,
> >
> >    I didn't see such a cost of instantiating stubs with Axis 1.3.
> >
> >
> >    I played a very simple microbenchmark against Axis 1.3 that showed
> > :
> > - instantiation of stub is really fast
> > - instantiation of the ServiceLocator is really slow
> >
> >    The benchmark was to instantiate 10 000 stubs either reusing the
> > same service locator or instantiating a new service locator each time.
>
> > The first scenario was only took 70 ms when the second took 53 000 ms
> > (700 times slower).
> >
> >    I know the limitations of micro benchmarks but it makes me feel
> > confident.
> >
> >    More over, I re-checked the 1.3 source code and I didn't see any
> > jar scanning activities.
> >
> >    Cyrille
> >
> > --
> > Cyrille Le Clerc
> > cyrille.leclerc@pobox.com
> > cyrille.leclerc@fr.ibm.com
> >
> >
> > MICRO BENCHMARK RESULT
> > =======================
> > instantiate 10 000 stubs
> > reuse servicelocator, duration in millis : 2473 => initialization
> > instantiate service locator every time, duration in millis : 55110
> > reuse servicelocator, duration in millis : 70 instantiate service
> > locator every time, duration in millis : 53727 reuse servicelocator,
> > duration in millis : 60 instantiate service locator every time,
> > duration in millis : 52766 reuse servicelocator, duration in millis :
> > 70 instantiate service locator every time, duration in millis : 53267
> > reuse servicelocator, duration in millis : 70 instantiate service
> > locator every time, duration in millis : 50132 reuse servicelocator,
> > duration in millis : 50
> >
> > MICRO BENCHMARK CODE
> > =====================
> > for (int testCounter = 0; testCounter < 10; testCounter++) {
> >    {
> >       // reuse service locator
> >       long timeBefore = System.currentTimeMillis();
> >       HelloWorldServiceLocator helloWorldServiceLocator = new
> > HelloWorldServiceLocator();
> >       for (int invocationCounter = 0; invocationCounter < 10000;
> > invocationCounter++) {
> >          HelloWorldBindingStub bindingUserTic =
> > (HelloWorldBindingStub) helloWorldServiceLocator
> >                .gethelloWorldBinding();
> >       }
> >       long timeAfter = System.currentTimeMillis();
> >       System.out.println("reuse servicelocator, duration in millis : "
> >             + (timeAfter - timeBefore));
> >    }
> >    {
> >       // instantiate service locator every time
> >       long timeBefore = System.currentTimeMillis();
> >       for (int invocationCounter = 0; invocationCounter < 10000;
> > invocationCounter++) {
> >          HelloWorldServiceLocator helloWorldServiceLocator = new
> > HelloWorldServiceLocator();
> >          HelloWorldBindingStub bindingUserTic =
> > (HelloWorldBindingStub) helloWorldServiceLocator
> >                .gethelloWorldBinding();
> >       }
> >       long timeAfter = System.currentTimeMillis();
> >       System.out.println("instantiate service locator every time,
> > duration in millis : "
> >             + (timeAfter - timeBefore));
> >    }
> > }
> >
> >
> > On 1/20/06, Ebert, Chris <chris.ebert@hp.com> wrote:
> > > Maybe this changed in 1.3, but I found instantiating stubs to be
> > > heavyweight -- it triggered a scan of all jar files on the classpath
>
> > > in 1.1... Chris
> > >
> > >
> > > -----Original Message-----
> > > From: cyrille.leclerc@gmail.com [mailto:cyrille.leclerc@gmail.com]
> > > On Behalf Of Cyrille Le Clerc
> > > Sent: Thursday, January 19, 2006 15:50
> > > To: axis-user@ws.apache.org
> > > Subject: Re: Generated Stub Thread-safe?
> > >
> > >    Hello Neil,
> > >
> > >    Axis 1.3 stubs are NOT thread safe. You will face problems if
> > > your calls involve soap headers or attachments for example.
> > >
> > >    Note that can can reuse a stub. By the way, reusing a stub is the
>
> > > pattern to maintain a client side session (you then also have to
> > > call
> > > stub.setMaintainSession(true) ).
> > >
> > >    If you use stateless soap calls, the simplest pattern is to use :
> > > - a single instance of the serviceLocator (acts as the stub factory)
> > > - to instantiate one new instance of the stub for each call and then
>
> > > throw this instance away
> > >
> > >    If you use stateful soap calls, the simplest pattern is to use :
> > > - a single instance of the serviceLocator (acts as the stub factory)
> > > - to instantiate one new instance of the stub per session, perform
> > > the
> >
> > > calls and then throw this instance away
> > >
> > >
> > >    Note that the cost of instantiating new stubs is small because
> > > the stubs are lightweight objects.
> > >    An optimization to lower this cost could be to :
> > > - reduce the initial size of the vectors variables of
> > > org.apache.axis.client.Stub : "headers" and "attachments"
> > > - change to static the instance variables of the generated stubs
> > > (com.mycompany.MyServiceBindingStub) and initialize them in a static
>
> > > block : "cachedSerClasses", "cachedSerQNames", "cachedSerFactories",
>
> > > "cachedDeserFactories"
> > >
> > >    Not that is is very important to reuse the same instance of the
> > > serviceLocator to instantiate all the stubs because :
> > > - serviceLocator is a heavyweight object (it holds its own
> > > AxisEngine)
> > > - if you use the CommonsHTTPSender, the serviceLocator holds this
> > > Sender (via the AxisEngine) and this CommonsHTTPSender MUST be
> shared
> > > among Stubs to benefit of the pooled http connections
> > >
> > >
> > >    I have deduced these points analyzing Axis source code. If
> > > somebody
> >
> > > can confirm or contradict ?
> > >
> > >    Hope this help,
> > >
> > >    Cyrille
> > >
> > > --
> > > Cyrille Le Clerc
> > > cyrille.leclerc@pobox.com
> > > cyrille.leclerc@fr.ibm.com
> > >
> > > On 1/19/06, Ferguson, Neil, VF-NZ <Neil.Ferguson@vodafone.com>
> > > wrote:
> > > >
> > > >
> > > > Hi.
> > > >
> > > > I was wondering if anybody could give me a definitive answer on
> > > > whether the stub generated by WSDL2Java (Axis 1.3) is thread-safe
> > > > (i.e. it can safely be used by multiple concurrent threads without
> > > external synchronization)?
> > > > Unfortunately "I've tried it and it works" probably won't be
> > > > enough for me, I'll probably need some documentation to back it
> > > > up.
> > > >
> > > > Also, if it is thread-safe are there any performance implications
> > > > of
> >
> > > > multiple threads using it (i.e. it does lots of synchronization
> > > internally)?
> > > >
> > > > Perhaps I should just pool my stubs to be on the safe side. Any
> > > thoughts?
> > > >
> > > > Thanks.
> > > >
> > > > Neil.
> > > >  ________________________________
> > > >
> > > >
> > > > Have you seen our website? .... www.vodafone.co.nz
> > > >
> > > > Manage Your Account, check your Vodafone Mail and send web2TXT
> > > > online: www.vodafone.co.nz/myvodafone
> > > >   ________________________________
> > > >
> > > > CAUTION: This correspondence is confidential and intended for the
> > > > named
> > > > recipient(s) only.  If you are not the named recipient and receive
>
> > > > this correspondence in error, you must not copy, distribute or
> > > > take any action in reliance on it and you should delete it from
> > > > your system
> > >
> > > > and notify the sender immediately.  Thank you.
> > > >
> > > > Unless otherwise stated, any views or opinions expressed are
> > > > solely those of the author and do not represent those of Vodafone
> > > > New Zealand
> > > Limited.
> > > >
> > > > 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030
> > > > Telephone
> > > > + 64 9 355 2000 Facsimile + 64 9 355 2001
> > > > ________________________________
> > > >
> > >
> > ----------------------------------------------------------------------
> > -------------------------
> >
> > Have you seen our website?.... http://www.vodafone.co.nz
> >
> > Manage Your Account, check your Vodafone Mail and send web2TXT online:
>
> > http://www.vodafone.co.nz/myvodafone
> >
> > CAUTION: This correspondence is confidential and intended for the
> > named recipient(s) only. If you are not the named recipient and
> > receive this correspondence in error, you must not copy, distribute or
>
> > take any action in reliance on it and you should delete it from your
> > system and notify the sender immediately.  Thank you.
> >
> > Unless otherwise stated, any views or opinions expressed are solely
> > those of the author and do not represent those of Vodafone New Zealand
>
> > Limited.
> >
> > Vodafone New Zealand Limited
> > 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030 Telephone
> > + 64 9 355 2000 Facsimile + 64 9 355 2001
> >
> -----------------------------------------------------------------------------------------------
>
> Have you seen our website?.... http://www.vodafone.co.nz
>
> Manage Your Account, check your Vodafone Mail and send web2TXT online: http://www.vodafone.co.nz/myvodafone
>
> CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
> If you are not the named recipient and receive this correspondence in error, you must
not copy,
> distribute or take any action in reliance on it and you should delete it from your system
and
> notify the sender immediately.  Thank you.
>
> Unless otherwise stated, any views or opinions expressed are solely those of the author
and do
> not represent those of Vodafone New Zealand Limited.
>
> Vodafone New Zealand Limited
> 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030
> Telephone + 64 9 355 2000
> Facsimile + 64 9 355 2001

Mime
View raw message