<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Later this week. It is staged actually
      already so you can try it if you do not mind using the staging
      repository.<br>
      <br>
      On 01/29/2013 11:33 PM, Lincoln Baxter, III wrote:<br>
    </div>
    <blockquote
cite="mid:CAEp_U4G4koNcoHY4ydCMCdkO8hw=y_AxhPGWxuPzMTmsmfgBRA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Thanks Jozef,<br>
        <br>
        When will Beta3 be out?<br>
        <br>
        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?<br>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Jan 29, 2013 at 4:49 PM, Jozef
          Hartinger <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
            <br>
            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.<br>
            <br>
            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.<br>
            <br>
            See <a moz-do-not-send="true"
href="http://docs.jboss.org/weld/reference/2.0.0.Beta3/en-US/html/configure.html#d0e5936"
              target="_blank">http://docs.jboss.org/weld/reference/2.0.0.Beta3/en-US/html/configure.html#d0e5936</a>
            for how this is configured. Note that you'll need to wait
            for Beta3 as the configuration options have changed
            recently.
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                On 01/29/2013 07:19 PM, Lincoln Baxter, III wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Hi Jozef, Stuart, and Weld-devs,<br>
                  <br>
                  In Forge 2 we are using Weld extensively, and one of
                  the things we do is start up many instances
                  simultaneously.<br>
                  <br>
                  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.<br>
                  <br>
                  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.<br>
                  <br>
                  <br>
                  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.<br>
                  <br>
                  (Screenshot attached.)<br>
                  <br>
                  Thanks,<br>
                  <br>
                  -- <br>
                  Lincoln Baxter, III<br>
                  <a moz-do-not-send="true" href="http://ocpsoft.org"
                    target="_blank">http://ocpsoft.org</a><br>
                  "Simpler is better."<br>
                </blockquote>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        Lincoln Baxter, III<br>
        <a moz-do-not-send="true" href="http://ocpsoft.org"
          target="_blank">http://ocpsoft.org</a><br>
        "Simpler is better."
      </div>
    </blockquote>
    <br>
  </body>
</html>