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 <[email protected]>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 [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
