You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by sanjaya gayan <sa...@yahoo.co.uk> on 2005/06/01 09:28:25 UTC

RE: Restructuring Call::initialize

this is a good improvement. 
This performance gain happens only if you are using the same stub for multiple invocations, doesn't it? It is good to improve performance of possible scenarios and I guess this will be quite a common one.
 
sanjaya
 

Samisa Abeysinghe <sa...@virtusa.com> wrote:
There is some good news on this improvement.

For the base sample with about 12 method invocations on the same stub
object, before I did the changes, it took about 0.225 seconds to get the
response. With the changes in place it now takes about 0.150 seconds.

I used the "time" command on Linux to get this data.

Please note that we got this improvement just moving the
Call::openConnection() logic to the Call constructor and thereby making
sure that logic is executed only once.

Thanks,
Samisa...


On Wed, 2005-06-01 at 11:40, Samisa Abeysinghe wrote:
> I have commited my initial changes to the CVS.
> The commit was done after running the test cycle. 
> 
> I get the SOAP header tests failing, and I am looking into the problem.
> The reason to commit the changes early is that I need some help with SSL
> related testing as I haven't got the SSL tests up and running.
> 
> Thanks,
> Samisa...
> 
> On Tue, 2005-05-31 at 11:17, Samisa Abeysinghe wrote:
> > I am in the process of moving all Call::openConnection() logic into
> > the Call class constructor.
> > 
> > So far I have been somewhat successful but some of the tests are
> > failing.
> > 
> > However, it looks to me that Call::openConnection() should not be
> > there at all (Please see the sequence diagram that I sent earlier) and
> > as I have discussed earlier, at the moment this is called multiple
> > times for each method invocation. 
> > 
> > 
> > 
> > Once I get around the problems with moving Call::openConnection() to
> > constructor, I plan to reuse the ClientAxisEngine, MessageData,
> > SOAPSerializer and SOAPDeSerializer objects, instead of destroying
> > them on each method call.
> > 
> > My feeling is that this will lead to improved performance, though I
> > have not yet planned how to measure it. 
> > 
> > 
> > 
> > Thanks,
> > 
> > Samisa…
> > 
> > 
> > 
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:SAbeysinghe@virtusa.com] 
> > Sent: Monday, May 30, 2005 4:34 PM
> > To: Apache AXIS C Developers List
> > Subject: RE: Restructuring Call::initialize
> > 
> > 
> > 
> > Yes, ClientAxisEengine is deleted for each method, despite the fact we
> > are using the same Stub object.
> > 
> > 
> > 
> > Deleting the engine every time has to be removed and move some of the
> > init logic which is one off to the constructor.
> > 
> > 
> > 
> > I have attached a sequence diagram herewith to help understanding
> > Call::initialize(). It looks to me that Call::initialize triggers a
> > deep set of method calls. Some activities like buffer clearing has to
> > be done every time before a fresh invoke. However, some activities
> > like setting the end point can be one off.
> > 
> > 
> > 
> > Thanks,
> > 
> > Samisa…
> > 
> > 
> > 
> > -----Original Message-----
> > From: sanjaya gayan [mailto:sanjayagps@yahoo.co.uk] 
> > Sent: Monday, May 30, 2005 4:01 PM
> > To: Apache AXIS C Developers List
> > Subject: Re: Restructuring Call::initialize
> > 
> > 
> > 
> > It looks to me like with each call to Call::Initialize() if a
> > ClientAxisEngine object exists it is deleted and then a new one
> > created and initialized (I am not sure whether
> > ClientAxisEngine->Initialize() caters for this).
> > 
> > 
> > Shouldn't it be that if a AxisClient object exists it should be reused
> > by intializing and a new one created only if there is no AxisClient
> > object?
> > 
> > 
> > 
> > 
> > 
> > I guess that the deleting of the existing object could be removed, in
> > which case initializing the ClientAxisEngine (which should "intialize"
> > all members of the ClientAxisEngine. not sure whether this is the
> > current behaviour) with each call to Call::Initialize has to be done.
> > 
> > 
> > 
> > 
> > 
> > sanjaya.
> > 
> > 
> > Samisa Abeysinghe wrote:
> > 
> > 
> > Hi All,
> > I am looking into the Call::initialize() method that is being
> > called within the client side generated code, 
> > prior to each method invocation.
> > 
> > Basically if we have 2 method calls that we could invoke, and
> > in the client program we execute both those methods, 
> > we will be calling initialize() on the m_pCall member of the
> > stub object twice.
> > However, having a glance into Call::initialize() it looks to
> > me that some of the activities could be made one off
> > instead of executing them multiple times for each method
> > invocation.
> > 
> > Some of the candidate calls that I want to make one off is
> > initing the AxisClientEngine once, thus reusing the 
> > serializer and deserializer objects for multiple calls.
> > It would be helpful if one of the original designers of this
> > mechanism could rationalize the initial design so that 
> > I would not miss any important points here.
> > 
> > Thanks,
> > Samisa...
> > 
> > 
> > ______________________________________________________________________
> > 
> > How much free photo storage do you get? Store your holiday snaps for
> > FREE with Yahoo! Photos. Get Yahoo! Photos
-- 
Samisa Abeysinghe 
Virtusa Corporation

		
---------------------------------
Yahoo! Messenger NEW - crystal clear PC to PCcalling worldwide with voicemail