On 18.01.2017 13:00, Mark Thomas wrote:
On 18/01/2017 11:34, André Warnier (tomcat) wrote:
Hi.
This is a partial recap of the theme discussed on the list, in this
thread :
http://marc.info/?l=tomcat-user&m=148473249120783&w=2
I would sugest a documentation change, basically in all pages related to
Connector's configurations, from 9.0, and I believe all the way back to
6.0.
The change relates to the "minSpareThreads" attribute of the Connectors,
such as
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
and the suggestion is based on :
http://tomcat.apache.org/migration-6.html#Connector_thread_pools
Basically, each of the Connector pages repeats the same text about this
attribute :
quote
minSpareThreads
The minimum number of threads always kept running. If not specified, the
default of 10 is used. If an executor is associated with this connector,
this attribute is ignored as the connector will execute tasks using the
executor rather than an internal thread pool. Note that if an executor
is configured any value set for this attribute will be recorded
correctly but it will be reported (e.g. via JMX) as -1 to make clear
that it is not used.
unquote
So,
- if there is an Executor, then this Connector attribute is ignored
- but according to the above migration guide, if there is no Executor,
it is also ignored.
So basically, why have it ?
Creating a thread is a relatively time consuming task.
It ensures that, up to the maximum allowed threads, there are always
minSpareThreads available to handle a spike in incoming requests.
i.e.
- Start with 10 idle threads
- 3 new connections arrive
- they each get handled by one of the threads
- Tomcat starts another 3 threads in the background to bring the spare
pool back up to 10
- the 3 connections complete
- the spare pool is now 13
If you want the spare pool to be reduced back down to 10 (or some other
setting) when threads are idle then you need to use an appropriately
configured Executor.
The best settings will depend on the load profile. Keeping a thread idle
in the background uses relatively little resources. The more 'spikey'
your load is, the less benefit you'll get from stopping idle threads. At
some point, the load caused by creating and stopping threads will cause
more problems than just leaving the threads idle.
Maybe change the first sentence to:
The number of idle threads Tomcat keeps available to handle new
requests. Note that excess idle threads are not stopped. The total
number of threads will therefore increase over time with an upper limit
of maxThreads. If you require excess idle threads to be stopped, use an
Executor.
Mark
So what you are saying above, is that the "minSpareThreads" attribute in a Connector
(without Executor) is not really being ignored.
It is just the "shrinking" part of it that is not being done anymore, since
tomcat 6.0.
Is that the correct interpretation ?
A different question : how would one go about determining how many resources /are/ being
used by an idle thread ? (or more relevantly, by a couple of hundred of them)
And yet another :
Above, you say that "Tomcat starts another 3 threads in the background".
When does that actually happen, in relation to "3 new connections arrive" ?
(or maybe without a direct relation, on some separate time schedule)
I realise that these are probably somewhat pernickety questions, and maybe without much
real-world practical importance. But I figure that we may as well get to the bottom of
this, while we have your expert attention.
Of course, I don't know if there is some deeper code reason to keep
mentioning it in the Connectors' documentations. Which is why this is a
suggestion.
Maybe instead, it could be made clearer that if there is no Executor,
the number of threads associated to a Connector may keep on growing over
time, up to the maxThreads value, and never go down again.
(And the nefarious/beneficial/neutral effects thereof ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
