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

Jozef Hartinger jharting at redhat.com
Wed Jan 30 06:33:59 EST 2013


Later this week. It is staged actually already so you can try it if you 
do not mind using the staging repository.

On 01/29/2013 11:33 PM, Lincoln Baxter, III wrote:
> 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 
> <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
>     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/20130130/38273c8d/attachment-0001.html 


More information about the forge-dev mailing list