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

[Martin Kouba]

Dne 29.1.2013 23:33, Lincoln Baxter, III napsal(a):
> 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?

This is normal for the default ExecutorServices impl
(org.jboss.weld.executor.FixedThreadPoolExecutorServices). You can
change the impl - set the "threadPoolType" option either to
SINGLE_THREAD or FIXED_TIMEOUT (see the doc link Jozef's pointing at).

> 
> 
> On Tue, Jan 29, 2013 at 4:49 PM, Jozef Hartinger <jharting at redhat.com
> <mailto: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."
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
JBoss Quality Assurance Engineer
CDI TCK lead
Red Hat, Czech Republic