Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads

From: "Benjamin Browning" <bbrowning(a)redhat.com&gt; To: &quot;jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Friday, October 21, 2011 8:13:43 AM Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads

On Oct 21, 2011, at 8:43 AM, Remy Maucherat wrote:

> On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote: >> I agree with everything Andy said and absolutely needed to be able >> to >> set maxThreads in our TorqueBox benchmarks. There may be some >> hypothetical reason I shouldn't need to set maxThreads but in >> practice >> the performance before and after was night and day once a hit a >> high >> enough concurrent client load. The defaults of 512 * # of CPUs was >> way >> too high - 4096 http threads on my 8 CPU benchmark server kills >> performance and eats up way too many resources. > > If you want to run serious benchmarks and tune things, you should > be > aware of how the server works, and what are the possibilities to > solve > the problem. > > The issue with reducing the amount of threads with the default > java.io > connector (which is used unless the native libraries are installed) > is > that it will, in most case, use a lot of its threads to do > keepalive. > Keepalive is usually very important for real servers to give good > user > experience, and also can help performance a lot. However, this is a > problem since, when running a benchmark with a specific client, > keepalive might not be used, or at least much less, and all threads > could actually be in the application, so 512 * n becomes far too > high. > The problem goes away with the native libraries, since there is an > efficient way to handle keepalive, and all threads will be > dedicated to > actually running the application. The default for the native > connectors > is 32 * n threads. With native, a high number of threads is > actually > directly detrimental to performance, since it has a lot of > asynchronous > capabilities and needs a sync in one location to avoid crashing.

Thanks for the detailed explanation on keepalives and the defaults.

> > You have solutions, even with the java.io connector: > - Use an executor. This has all the configuration options you could > like, and the performance difference may not be measurable > depending on > the application. > - Use a semaphore valve or filter, which will only allow a certain > amount of threads to concurrently enter specific parts of your > application. This allows much more fine tuning and could be a good > strategy. > > As a compromise, I will propagate max-connections to maxThreads for > the > java.io connector. This shouldn't hurt too much, and this > corresponds > relatively well to the concept of connection count after all.

Thanks!

> > -- > Remy Maucherat <rmaucher(a)redhat.com&gt; > Red Hat Inc > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev