<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'><br><br><hr id="zwchr"><blockquote id="DWT610" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Benjamin Browning" <bbrowning@redhat.com><br><b>To: </b>"jboss-as7-dev@lists.jboss.org Development" <jboss-as7-dev@lists.jboss.org><br><b>Sent: </b>Friday, October 21, 2011 8:13:43 AM<br><b>Subject: </b>Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads<br><br><br>On Oct 21, 2011, at 8:43 AM, Remy Maucherat wrote:<br><br>> On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote:<br>>> I agree with everything Andy said and absolutely needed to be able to<br>>> set maxThreads in our TorqueBox benchmarks. There may be some<br>>> hypothetical reason I shouldn't need to set maxThreads but in practice<br>>> the performance before and after was night and day once a hit a high<br>>> enough concurrent client load. The defaults of 512 * # of CPUs was way<br>>> too high - 4096 http threads on my 8 CPU benchmark server kills<br>>> performance and eats up way too many resources.<br>> <br>> If you want to run serious benchmarks and tune things, you should be<br>> aware of how the server works, and what are the possibilities to solve<br>> the problem.<br>> <br>> The issue with reducing the amount of threads with the default java.io<br>> connector (which is used unless the native libraries are installed) is<br>> that it will, in most case, use a lot of its threads to do keepalive.<br>> Keepalive is usually very important for real servers to give good user<br>> experience, and also can help performance a lot. However, this is a<br>> problem since, when running a benchmark with a specific client,<br>> keepalive might not be used, or at least much less, and all threads<br>> could actually be in the application, so 512 * n becomes far too high.<br>> The problem goes away with the native libraries, since there is an<br>> efficient way to handle keepalive, and all threads will be dedicated to<br>> actually running the application. The default for the native connectors<br>> is 32 * n threads. With native, a high number of threads is actually<br>> directly detrimental to performance, since it has a lot of asynchronous<br>> capabilities and needs a sync in one location to avoid crashing.<br><br>Thanks for the detailed explanation on keepalives and the defaults. <br></blockquote>In terms of keep alives, I had opened a JIRA to add the maxKeepAlive parameter to the schema and expose that for tuning. Is there an issue you have with exposing that? It's another key tuning parameter for benchmarking.<br><br>Andy<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><br>> <br>> You have solutions, even with the java.io connector:<br>> - Use an executor. This has all the configuration options you could<br>> like, and the performance difference may not be measurable depending on<br>> the application.<br>> - Use a semaphore valve or filter, which will only allow a certain<br>> amount of threads to concurrently enter specific parts of your<br>> application. This allows much more fine tuning and could be a good<br>> strategy.<br>> <br>> As a compromise, I will propagate max-connections to maxThreads for the<br>> java.io connector. This shouldn't hurt too much, and this corresponds<br>> relatively well to the concept of connection count after all.<br><br><br>Thanks!<br><br><br>> <br>> -- <br>> Remy Maucherat <rmaucher@redhat.com><br>> Red Hat Inc<br>> <br>> _______________________________________________<br>> jboss-as7-dev mailing list<br>> jboss-as7-dev@lists.jboss.org<br>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br><br>_______________________________________________<br>jboss-as7-dev mailing list<br>jboss-as7-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></blockquote><br></div></body></html>