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."

What kind of information do you need? I was unable to get YourKit to dump a .snapshot file for some reason. If that's what you need, I can try again. Which profile mode? This was done using tracing. Thanks! On Tue, Jan 29, 2013 at 4:32 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: The screenshot does not really tell us much. We would need to see the actual profile information. Stuart 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."

Okay, good to know. What kind of info would you need to get into things? Also, any idea why the report says that my Bootstrap.main(String[]) is called over 1000 times? Seems a bit odd to me. This method literally does a little string parsing, then calls starts Forge in a Thread (and waits for that thread to finish.) On Tue, Jan 29, 2013 at 5:33 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> wrote: Tracing is pretty useless at identifying slow parts, as the overhead it adds distorts the profile too much. The only thing it is really good for is identifying methods that are called too often. Sampling is generally much better. Stuart Lincoln Baxter, III wrote: What kind of information do you need? I was unable to get YourKit to dump a .snapshot file for some reason. If that's what you need, I can try again. Which profile mode? This was done using tracing. Thanks! On Tue, Jan 29, 2013 at 4:32 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com> <mailto:stuart.w.douglas@__gmail.com <mailto:stuart.w.douglas@gmail.com>>> wrote: The screenshot does not really tell us much. We would need to see the actual profile information. Stuart 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." -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."

IMHO both tools have their up/downsides. - instrumentation gives you a quite precise _relative_ performance indicator - sampling gives a _relatively precise_ performance indicator both have impact on the runtime, so you always have to account for the "uncertainty principle" :-) Am 29.01.2013 23:33, schrieb Stuart Douglas: > Tracing is pretty useless at identifying slow parts, as the overhead it > adds distorts the profile too much. The only thing it is really good for > is identifying methods that are called too often. > > Sampling is generally much better. > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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."

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(a)redhat.com <mailto:jharting@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... <http://docs.jboss.org/weld/reference/2.0.0.Beta3/en-US/html/configure.htm... 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev