cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
Subject Re: JAX-WS client performances
Date Tue, 03 Feb 2015 22:52:51 GMT
Hi Dan,

On 03/02/15 21:02, Daniel Kulp wrote:
>> On Feb 3, 2015, at 8:11 AM, Alessio Soldano <> wrote:
>> A brief update: I've committed the workaround for http connection issue (thanks Dan
for the help on that!) as well as some other straightforward optimizations on stuff that popped
up while profiling.
>> Now, next "big" topic I found is the way we get and set properties in the message
context. We spend a relevant amount of time in creating HashMap instances and especially in
MessageImpl#calcContextCache, which copies (putAll) all the Bus, Service, Endpoint, etc. properties
into the context cache. You can see [1] the cpu hotspot view I get currently with the previously
mentioned test app. AFAICS in the source history, there used to be a different way for dealing
with message properties in the past [2], then the cache mechanism was added. So I'm wondering
if some kind of profiling / perf testing have been performed in the past and led to the changes.
I might simply be testing an edge scenario, with very few properties being looked up and hence
not justifying the caching mechanism.
>> Any comment / idea / suggestion?
> At one point, every “get” of a property would end up checking 4 or 5 hash maps which
resulted in the keys being hashCoded many times, lots of checks, etc…    When you get into
the WS-Security cases and some of the HTTP configuration cases where there are a bunch of
keys being looked up, there was a LOT of time being spent on the lookups.
OK, I see, thanks; perhaps calls to "get" became a problem when you had 
a wide range of properties that could be there in the context, but 
actually were not, so you went through all the maps to eventually figure 
out the prop was not there... I wonder if a different cache approach 
(save the cache hit and cache miss entries in 2 maps as they're 
requested) could make sense or not.

>     For the most part, at the time, the maps were relatively small and the cost to build
a single “context” map was small in comparison which is why this was done.
> That said, the size of the cache map is likely fairly small as well.   Maybe a dozen
keys?  (and I'm willing to bet most of the keys are interned where a == would catch it)  Might
be simpler to just use an Object[] or something.
I've tried printing the cache size while running the jbossws testsuite 
and on average I get values around 40~50 (with most of the stuff being 
in the exchange and message maps). So I'm not sure a plain array would 
be a better solution in terms of performances.
What I've been thinking about (but didn't actually try, at least not 
yet) is a custom HashMap extension that would work as a composition of 
multiple HashMap instances; so we'd have a get method computing the 
requested key's hash once and not for each sub-map, etc. I don't really 
know yet if this is doable, perhaps I can try providing something 
working that avoids all the maps copies (btw, I bet we have basically no 
key overlaps among the various maps for the same context).

Thanks for now

Alessio Soldano
Web Service Lead, JBoss

View raw message