Hi,
My comments below, prefixed with "NM>".
Nirmal.
Aleksander
Slominski To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
.edu> Subject: Re: [WSIF] Improving
performance of WSIF stub invocation
10/08/2002 02:48
PM
Please respond to
axis-dev
hi nirmal,
i think that performance numbers both for CPU and memory utilizaton backed
by a performance test would make the most convincing arguments
- after all you have mentioned that in some situation "stu incocation
became
approximately 5 - 9 times faster" and i would think that WSIF overhead
shoudl
be _almost_ neglibable when comared with using SOAP direclty ...
NM> Yes, I think we need to set up performance tests to exercise all
providers and measure the
NM> numbers. I volunteer to do a first cut - the tests won't be NM> very
accurate but I think it will
NM> be good to have the infrastructure, we can improve on the perf testing
methodology later.
NM> Theoretically calling a SOAP service through WSIF should not be much
more expensive
NM> than using the SOAP APIs directly, that is true (and ditto for other
providers, except
NM> perhaps local java, since there WSIF is bound to add a lot of overhead,
relatively speaking).
NM> So we'll make that the goal of the perf improvements.
> There might be some cases where some state is leftover at the end of the
> invocation which might interfere with the next one. So I suggest we do
this
> the following way:
> 1. Advise developers that the intent of the close() method on
WSIFOperation
> is to give them the opportunity to do any clean up that may be required
> before the next invocation using the same object.
> 2. Write a default close() method that does nothing.
> Even to accomodate such state cleanup, it shouldn't be necssary to
discard
> the old object and create a new one for the next invocation, that is
> overkill - providers can implement close() however they like in their
> implementations of WSIFOperation and that should be sufficient.
actually couldnt WSIF be responsible to call close() in stub - so this
would
be the contract between WSIF and provider - call to close() signals
provider
implementaiton of WSIFOperation that it should release any transient state
...
NM> I agree, the stub would be the best place to call close() (at the end
of
NM> each invocation)
> To fix our code to implement the above scheme, we just need to get rid of
> the "closed" flag in WSIFDefaultOperation (then we have full reuse
enabled
> in the base implementation); next we test multiple invocations with each
> provider and make sure they work, adding a custom close() method if they
> don't. Ant, if you volunteer to make these changes (shouldn't take long,
> since I doubt you will need any custom close() implementations) it would
be
> a great independent verification of this.
this shows that it would be good to define/document what is exaclty
required
from WSIF provider (what is contract) ...
NM> Yes. Volunteers?
> I'd be a bit nervous about reusing WSIFOperations. I'd always been under
> the impression that we could assume a WSIFOperation would not be reused.
> Whether or not that's the correct design that's the way some of the
> providers may have been written. I'm out this week so don't have so much
> time to check, but things like JMS properties and the context could end
up
> with residual data. There's also the providers that others have written
> that we don't have control over. Isn't it safer to let the WSIFPort
decide
> if it wants to cache and reuse a WSIFOperation?
we are only now reaching a stable version so we should make chnages now
and not wait until later when it would be almost impossible ...
thanks,
alek
