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 <[email protected] > <mailto:[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 > -- Martin Kouba JBoss Quality Assurance Engineer CDI TCK lead Red Hat, Czech Republic _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
