[jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads
Benjamin Browning
bbrowning at redhat.com
Fri Oct 21 07:57:57 EDT 2011
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.
Ben
On Oct 20, 2011, at 5:41 PM, Andrig Miller wrote:
> Well, right now based on my testing, if you use the JBoss Threads executor, then you get a performance degradation. It's not big, but its still there.
>
> If you cannot set maxThreads, then I don't see how we can get the best possible performance on our benchmark efforts. As you increase the injection rate, and run on the large scale hardware we have planned, we will have to be able to set that.
>
> So, I understand it can be abused, but so can a lot of settings. That's why we have the administration and performance tuning guides (which I will be updating for EAP 6).
>
> Andy
>
> From: "Jason T. Greene" <jason.greene at redhat.com>
> To: "Brian Stansberry" <brian.stansberry at redhat.com>
> Cc: "Andrig Miller" <anmiller at redhat.com>, jboss-as7-dev at lists.jboss.org
> Sent: Thursday, October 20, 2011 3:27:58 PM
> Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads
>
> Remy has indicated in the past that he does not want to expose that
> level of tuning in the default jbossweb pool because of common
> misuse/misconception about the settings. (IIRC he was against maxthreads
> for example)
>
> On 10/20/11 4:16 PM, Brian Stansberry wrote:
> > I don't know; I'd need the JBoss Web guys to answer that.
> >
> > On 10/20/11 4:00 PM, Andrig Miller wrote:
> >> Do the configuration elements align with the default executor in JBoss
> >> Web, which is not the JBoss Threads implementation?
> >>
> >> Andy
> >>
> >> ------------------------------------------------------------------------
> >>
> >> *From: *"Brian Stansberry"<brian.stansberry at redhat.com>
> >> *To: *jboss-as7-dev at lists.jboss.org
> >> *Sent: *Thursday, October 20, 2011 1:24:41 PM
> >> *Subject: *Re: [jboss-as7-dev] Controlling Maximum Number of JBoss
> >> Web HTTP Threads
> >>
> >> If the web subsystem config is going to change, I'd like to see if it
> >> can be made to work the way JCA does[1] -- a config element aligned
> >> with
> >> the appropriate pool type in the jboss-as-threads.xsd.
> >>
> >> [1]
> >> https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-jca_1_0.xsd#L120
> >>
> >> On 10/20/11 2:17 PM, Andrig Miller wrote:
> >> > Good thing you looked at the code. I assumed that it impacted the
> >> > threads. I guess the defaults have always been big enough for all the
> >> > tests I have done then. We should open a JIRA on JBoss Web to add the
> >> > maxThreads attribute to the XML schema that goes into domain.xml and
> >> > standalone.xml, and have it defined as read-write, so this can be
> >> changed.
> >> >
> >> > Andy
> >> >
> >> >
> >> ------------------------------------------------------------------------
> >> >
> >> > *From: *"Benjamin Browning"<bbrowning at redhat.com>
> >> > *To: *"Andrig Miller"<anmiller at redhat.com>
> >> > *Cc: *"jboss-as7-dev at lists.jboss.org Development"
> >> > <jboss-as7-dev at lists.jboss.org>
> >> > *Sent: *Thursday, October 20, 2011 12:02:56 PM
> >> > *Subject: *Re: Controlling Maximum Number of JBoss Web HTTP Threads
> >> >
> >> > The max-connections attribute has no impact on the maximum http
> >> > threads. If you look at the code, all it does is set the maximum
> >> > poller size and sendfile size for the underlying JIoEndpoint.
> >> >
> >> > To control the threads you either have to use an external executor
> >> > or set the maxThreads attribute on the protocol handler (which in
> >> > turn sets it on the underlying JIoEndpoint).
> >> >
> >> > Ben
> >> >
> >> > On Oct 20, 2011, at 1:47 PM, Andrig Miller wrote:
> >> >
> >> > Ben,
> >> >
> >> > I think all you have to do is set max-connections="n" to the
> >> > number of threads you want. That's what I have been doing, and
> >> > based on looking at the running threads through JConsole, it
> >> > seems to work just fine. In terms of the executor attribute, and
> >> > setting up a pool using JBoss Threads, I have done extensive
> >> > testing. I usually see only a small degradation between the two,
> >> > like around 1% or so.
> >> >
> >> > Of course, that may vary based on what executor you choose to
> >> > use, but I was using the unbounded queue thread thread pool with
> >> > good success. I also changed the keepalive time, to keep the
> >> > threads around for at least an hour, so to avoid churn in my
> >> > testing between executions.
> >> >
> >> > Andy
> >> >
> >> >
> >> ------------------------------------------------------------------------
> >> >
> >> > *From:*"Benjamin Browning"<bbrowning at redhat.com
> >> > <mailto:bbrowning at redhat.com>>
> >> > *To:*"Andrig Miller"<anmiller at redhat.com
> >> > <mailto:anmiller at redhat.com>>
> >> > *Cc:*"jboss-as7-dev at lists.jboss.org
> >> > <mailto:jboss-as7-dev at lists.jboss.org>Development"
> >> > <jboss-as7-dev at lists.jboss.org
> >> > <mailto:jboss-as7-dev at lists.jboss.org>>
> >> > *Sent:*Thursday, October 20, 2011 10:32:01 AM
> >> > *Subject:*Controlling Maximum Number of JBoss Web HTTP Threads
> >> >
> >> > I split this thread off from "Two thread pools section in
> >> > management API" since it's not directly related.
> >> >
> >> > In my testing I was never able to create an executor for
> >> > JBoss Web that didn't have dismal performance. Since
> >> > TorqueBox needs to be able to easily control the maximum
> >> > number of http threads we've written a simple service that
> >> > reads a system property and sets the http connector's
> >> > protocol handler's maxThreads. This works great and doesn't
> >> > incur the performance hit of using a separate executor. If
> >> > there's interest, we could submit a patch upstream to accept
> >> > a max-threads attribute on the connector definitions.
> >> >
> >> > Ben
> >> >
> >> > On Oct 20, 2011, at 12:15 PM, Andrig Miller wrote:
> >> >
> >> > One thing that I have found with playing around with the
> >> > various subsystems, is JBoss Web. JBoss Web doesn't
> >> > expose a thread pool configuration, just a single
> >> > attribute called max-connections. It also then has an
> >> > "executor" attribute, which just takes a thread pool
> >> > name from the JBoss Threads configuration.
> >> >
> >> > So, this one is inconsistent with the other subsystems,
> >> > and I'm not sure if it should be changed to be
> >> > consistent or not, since the default doesn't use JBoss
> >> > Threads. This would also complicate any "global" view in
> >> > the console.
> >> >
> >> > Andy
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > jboss-as7-dev mailing list
> >> > jboss-as7-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Principal Software Engineer
> >> JBoss by Red Hat
> >> _______________________________________________
> >> jboss-as7-dev mailing list
> >> jboss-as7-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
> >>
> >
> >
>
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111021/6fe50d2c/attachment.html
More information about the jboss-as7-dev
mailing list