How are you testing that? minSpareThreads means number of threads that are kept running but you must run over to that number of simultaneous requests to check the behaviour additionaly having minSpareThreads=maxThreads looks weird to me.
Those numbers are only for test. I'm testing this using a load test done with JMeter.
I thought the point of minSpareThreads was to have that number of threads at startup. But if I got you right, it's the number of threads that won't be destroyed once created. Is that right? Because that was what I thought maxSpareThreads would do..
Also, which version of Tomcat is JBoss Web (shipped with JBoss EAP 4.3_CP06) based on? Tomcat 6 has these shared thread pools (executors) notion and no maxSpareThreads, only minSpareThreads. As you can see I mixed the old and new configuration in my configuration.
The reason I want some threads created at startup is precisely because of my load tests. Creating threads is expensive and impacts on my tests' results.
"Creating threads is expensive and impacts on my tests' results."
I agree wholeheartedly - why JMeter does not have the notion of a "steady state" has always bugged me. But you can simulate one. Here is how I do it. I either run from the command line, specifying the file to contains the response time data:
jmeter -n -t thesrcipttorun.jmx -j logfile.log -l response-timings.csv
Or I use only the Simple Data Writer listener and have it write all data to a CSV file.
Let's say I want a 30 second warmup. I look at the timestamps in the CSV file to determine which entry is 30 seconds into the run and delete all lines before that entry. Then I use the grpThreads entry to determine when the threads go away. For example, if I run 50 threads, then when I see grpThreads drop from 50 to 49, I know that one of the threads is done. I either delete from that line to the end of the file, or perhaps back up a second or two (base on the timestamp entry) and delete from there. The remaining lines are the steady state entries. This way I never have to worry about the results being skewed due to warmup or cooldown issues.
Thanks for your answer Peter. I was actually concerned about JBoss AS warm-up that would change my average response time.. Now you made me think and probably there are more impressions.. Throughput for example.
In my tests I have 20 slave jmeters running 1000 threads each. JBoss had 0 threads then. When I start the test threads in JBoss go gradually (from 0 threads) up to 5000. I can tell this test is distorted because if I run it again it will perform better (since there are already 5000 created threads).
I want to tell JBoss to start with 5000 threads, that's why I wanted a minSpareThread behaviour (or the idea I had about it's behaviour). But Jean is telling me minSpareThreads won't create threads at startup, only maintain already created threads...
I already gave you one suggestion - extract the steady-state data and use only that in your performance analysis.
Even if you could convince JBoss AS to start with 5000 threads, you would still have to filter out the warmup and shutdown data because they will skew your results because during that time not all of the JMeter threads are active.
Now I understood what you said Peter =)
JMeter should have a way to do this. But that maxSpareThreads would server not only test purposes, but also would be useful in production environment. Do you know if that's possible?
Anyway, thanks for the tip about JMeter, I'll give it a try.