[forge-dev] Improving the performance of weld for micro-deployments.

[Lincoln Baxter, III]

Thanks Jozef,

When will Beta3 be out?

Also, I've noticed that weld-worker threads are left hanging around after
weld has started. Is this normal? Is it possible that the weld Executor is
being left running un-intentionally?


On Tue, Jan 29, 2013 at 4:49 PM, Jozef Hartinger <jharting at redhat.com>wrote:

> I worked on Weld's bootstrap performance about 6 months ago but the focus
> was mainly on large deployments. I am not aware of any obvious bottlenecks
> that would get into the way of micro deployments. If you could do a further
> analysis that would be great.
>
> As for guava showing up in the stats, a lot of work Weld does is done
> within computing maps (e.g. reading metadata using reflection, etc.) so you
> would need to get more in depth here.
>
> Weld uses its own thread pool for concurrent loading, deployment and
> validation of beans. Furthermore, there is a service that pre-resolves
> extension observer methods in multiple additional threads. The thread pool
> sizes default to a configuration that should utilize the most of CPU in
> cases when a single Weld instance is running. However, in your environment
> where multiple Weld instances are booting at the same time this may
> actually harm performance. As a first step I would suggest disabling
> concurrent deployment and the preloader or playing with thread pool sizes
> to see if it changes anything.
>
> See http://docs.jboss.org/weld/**reference/2.0.0.Beta3/en-US/**
> html/configure.html#d0e5936<http://docs.jboss.org/weld/reference/2.0.0.Beta3/en-US/html/configure.html#d0e5936>for how this is configured. Note that you'll need to wait for Beta3 as the
> configuration options have changed recently.
>
>
> On 01/29/2013 07:19 PM, Lincoln Baxter, III wrote:
>
>> Hi Jozef, Stuart, and Weld-devs,
>>
>> In Forge 2 we are using Weld extensively, and one of the things we do is
>> start up many instances simultaneously.
>>
>> We may have anywhere from one to one-hundred or more weld instances.
>> Currently we have only seen around 10-12 instances, and performance is
>> "Okay", but in theory, we could see hundreds of instances, at which point,
>> performance starts to be a concern. We're working around this problem by
>> disabling CDI support on some internal addons, but... it's not really
>> reasonable to expect that everyone will do this.
>>
>> Which means... we need to figure out how to shave as much time off the
>> bootstrap as possible. Currently each weld instance takes anywhere from
>> 80ms to 450ms to start (not really sure why such variation yet,) and we'd
>> hopefully like to get that down even lower, around 10-20ms. Classloading
>> time only would be optimal, but obviously difficult to achieve.
>>
>>
>> How can we get the most speed out of Weld? Most of our deployments have
>> only ~15 bean classes at most. It seems like a lot of time (~30-40%) is
>> being spent in the Google concurrent collections.
>>
>> (Screenshot attached.)
>>
>> Thanks,
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130129/267566f5/attachment.html