Hi Dan,
On 03/02/15 21:02, Daniel Kulp wrote:
On Feb 3, 2015, at 8:11 AM, Alessio Soldano <[email protected]> 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
--
Alessio Soldano
Web Service Lead, JBoss
