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 <[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
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
