- I beg your pardon- they are not in runtime attributes, just .xsd files 2011/5/20 Francesco Marchioni <marchioni.francesco(a)gmail.com&gt;

On 05/20/2011 04:41 PM, Andrig Miller wrote: in standalone.xml packaged with 7.0.0.Beta3 I see: <subsystem xmlns="urn:jboss:domain:threads:1.0"> <scheduled-thread-pool name="remoting"> <max-threads count="10" per-cpu="20"/> <keepalive-time time="10" unit="seconds"/> </scheduled-thread-pool> <bounded-queue-thread-pool name="jca-short-running" blocking="true"> <core-threads count="10" per-cpu="20"/> <queue-length count="10" per-cpu="20"/> <max-threads count="10" per-cpu="20"/> <keepalive-time time="10" unit="seconds"/> </bounded-queue-thread-pool> <bounded-queue-thread-pool name="jca-long-running" blocking="true"> <core-threads count="10" per-cpu="20"/> <queue-length count="10" per-cpu="20"/> <max-threads count="10" per-cpu="20"/> <keepalive-time time="10" unit="seconds"/> </bounded-queue-thread-pool> <bounded-queue-thread-pool name="ejb3-async" blocking="true"> <core-threads count="10" per-cpu="20"/> <queue-length count="10" per-cpu="20"/> <max-threads count="10" per-cpu="20"/> <keepalive-time time="10" unit="seconds"/> </bounded-queue-thread-pool> </subsystem> so you say one of them is for http connector ? -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363

On May 20, 2011, at 7:12 PM, Andrig Miller wrote: Can somebody shed some light on this? IMO some arbitrary thread pool should not be used by jboss web. I would suggest either a custom (properly named) one. Ike

On Mon, 2011-05-23 at 10:48 +0200, Francesco Marchioni wrote: I'll keep the current internal thread pool as the default, since it is faster, and, more importantly, the different connectors have different thread usage (so an executor can't provide a good default). Enable lookups is also false by default, so nothing needed here. The new max-connections attribute is different, since the previous settings were misused. As I told you, unless you are certain you know what you are doing, you're unlikely to get better performance by changing the settings. [OTOH, by default, the server displays info about installing native to get better performance. Did you do try it ?] When testing the current beta 3 AS 7 release, I'd recommend allowing a significant amount of time to let it settle to good performance (it should be improved in trunk), especially if you use the java.io connector. You did not reply about what your testing and results are, so I can only try to guess. -- Remy Maucherat <rmaucher(a)redhat.com&gt; Red Hat Inc

----- Original Message ----- I don't believe MaxConnections has ever had anything do to with thread pooling, but the number of client connections to the connector itself. Andy

On 05/22/2011 09:22 PM, Remy Maucherat wrote: OK, let's investigate EDG 5.1 http connector settings: https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/edg-51/stres... EDG 6.0 (dummy version) http connector settings: (dummy version is 7.0.0.Beta3 + Infinispan 5.0.0.CR2 REST server deployed in to it as war) https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/edg-60/stres... (the max-connections attribute is set to 10000 and network interface is set to correct one before the test) Infinispan settings are almost the same for both cases, I of course cannot eliminate the possibility that the performance differences are caused by infinispan, but in this case I really suspect the web connector. In the load test I'm doing I start 1 AS with Infinispan, load the cache with some data set, do some warm-up with 1/10th of final load and then for one minute I apply a load of 1000 http clients and measure statistics during this period. Each client does a request, waits 100ms and repeats, so theoretical maximum request throughput is 10000 ops/sec EDG 5.1 with the above settings does 9,612.8 ops/sec and average response time is 1 ms. EDG 6.0 with the above settings does 1,748.6 ops/sec and average response time is 39 ms. some clients even give me read timeout exceptions in the second case. before digging deeper I wanted to sync the settings with EDG5.1, which you discourage me from, so let's see what are the default values you wanna keep untouched ? maxThreads seems to be set to 512*number of CPUs, which on the perf17.mw.lab.eng.bos.redhat.com where I'm testing this should be 4096, which should be enough maxKeepAliveRequests seems to be set to 100, which might be enough, I'm not sure how this affects the performance, IMO shouldn't be a big factor, from what I know it's just establishing new connection every 100 requests, that's something we can survive. maxHttpHeaderSize is something that probably doesn't have effect on my test, because I'm controlling the size of the headers disableUploadTimeout, connectionTimeout -this also shouldn't affect me, because if it does I should be seeing server side timeout exceptions and I don't only thing I'm worried about is acceptCount. do you know what is the default value there ? and anyway it seems that you should be able to specify executor for your connector, I tried this and didn't work for me. Is this already implemented ? m. -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363

On 05/23/2011 11:24 AM, Remy Maucherat wrote: I'll try this out. in Beta3 it didn't. I created bounded-queue-thread-pool name="http-connector", added attribute executor="http-connector" to the connector and then tried to see if executor is injected and can be accessed in WebConnectorService.start(). But it was null. m. -- Michal Linhard Quality Assurance Engineer Red Hat Czech s.r.o. Purkynova 99 612 45 Brno, Czech Republic phone: +420 532 294 320 ext. 62320 mobile: +420 728 626 363

On Tue, 2011-05-24 at 07:40 +0200, Michal Linhard wrote: Ok, so the next release should fix this. -- Remy Maucherat <rmaucher(a)redhat.com&gt; Red Hat Inc