[weld-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/weld-dev/attachments/20130130/38273c8d/attachment.html
More information about the weld-dev
mailing list