improving client performance tricks

[Pavel Ausianik <Pa...@epam.com>]

Hi,

In discussion over performance improvements I also propose share tricks
which could be used in own code, without touching SOAP (or other ) libs.
Often it gives more result, that asking to improve other's code. And only
once you are sure that you used everything...

So, we had a client side application, which often accesses single SOAP
service, with a set of 5-6 different calls, working from many threads at the
same time.

Our first design was simple - when you need to make a call, just create a
new one. However creation of a Call is not so light - further it will also
require to create additional DocumentBuilder, and SOAPMappingRegistry, both
not so light.

So we cached a Call, one per thread, and also cached a SOAPMappingRegistry,
one per all Calls.  SOAPMappingRegistry created in the static method, and
filled with a set of types necessary for all calls we need (so , when used
with a particular Call is used, registry really have more mapping than
needed). When new call is created , we set up an shared registry with a
call.setSOAPMappingRegistry func. Another problem, that even in the one
thread, we my need to do different calls, so solution is simple too - set up
function name and parameters just before doing a call with functions       

	call.setMethodName(methodName);   
	call.setParams(params);

Could not provide what performance we achieved with this , but for sure it
was rather good. 

Best regards,
Pavel

--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>

Re: improving client performance tricks

[WJCarpenter <bi...@carpenter.org>]

> Our first design was simple - when you need to make a call, just create
> a new one. However creation of a Call is not so light - further it will
> also require to create additional DocumentBuilder, and
> SOAPMappingRegistry, both not so light.

I agree with this point.  Some time ago, we switched to reusing the
Call object (we also use a static shared SOAPMappingRegistry).  I don't
recall the specific performance improvement, but I think it was on
the order of 1-2 ms saved.

> So we cached a Call, one per thread, and also cached a
> SOAPMappingRegistry, one per all Calls.  SOAPMappingRegistry created in

We ran into a couple stumbling blocks with this one.  First, to do a
Call per thread, the natural implementation is to use ThreadLocal.  Alas,
our stuff gets used inside some other folks EJBs, and you can't use
ThreadLocal in that case (EJB rules of engagement).

The next attack was to use a static Call object inside one of our objects
which the caller allocated.  Unfortunately for us, the caller found it
inconvenient to avoid sharing our object, so we had to make access to the
use of the Call object thread-safe.  As Pavel noted, that's tricky because
you have multiple method calls on Call object to actually accomplish a
SOAP request/response.  You can synchronize all that, but then you end
up serializing your throughput.

Ultimately (heh, at least "ultimately so far"), we used the static Call
object but made a way to mark it "in use".  In case it was in use, we
allocated another one and then threw it away when done.  So, most of the
time the static Call object gets reused in a multithreaded environment, but
when there does happen to be a collision we don't block the other threads.
We think of this as having a sort of a connection pool that just happens
to have a single connection available.  :-)

Re: improving client performance tricks

[WJCarpenter <bi...@carpenter.org>]

> Our first design was simple - when you need to make a call, just create
> a new one. However creation of a Call is not so light - further it will
> also require to create additional DocumentBuilder, and
> SOAPMappingRegistry, both not so light.

I agree with this point.  Some time ago, we switched to reusing the
Call object (we also use a static shared SOAPMappingRegistry).  I don't
recall the specific performance improvement, but I think it was on
the order of 1-2 ms saved.

> So we cached a Call, one per thread, and also cached a
> SOAPMappingRegistry, one per all Calls.  SOAPMappingRegistry created in

We ran into a couple stumbling blocks with this one.  First, to do a
Call per thread, the natural implementation is to use ThreadLocal.  Alas,
our stuff gets used inside some other folks EJBs, and you can't use
ThreadLocal in that case (EJB rules of engagement).

The next attack was to use a static Call object inside one of our objects
which the caller allocated.  Unfortunately for us, the caller found it
inconvenient to avoid sharing our object, so we had to make access to the
use of the Call object thread-safe.  As Pavel noted, that's tricky because
you have multiple method calls on Call object to actually accomplish a
SOAP request/response.  You can synchronize all that, but then you end
up serializing your throughput.

Ultimately (heh, at least "ultimately so far"), we used the static Call
object but made a way to mark it "in use".  In case it was in use, we
allocated another one and then threw it away when done.  So, most of the
time the static Call object gets reused in a multithreaded environment, but
when there does happen to be a collision we don't block the other threads.
We think of this as having a sort of a connection pool that just happens
to have a single connection available.  :-)





--
To unsubscribe, e-mail:   <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>