On 16.01.2017 09:50, smith wrote:
Busy one is process customer request, do not know what non-busy one is doing,
always keep 120 for many days. I don't think 20s timeout will not cause so long
connection
-smith
And did you actually try it ?
We do not know your website or your application, so we cannot tell how many clients there
are, what these clients are really requesting, how many requests each client is sending
before going away, etc.
KeepAlive means that when a client has sent its /last/ request and received the response,
one thread is going to remain "not free" (but doing nothing) for the duration of the
KeepAlive timeout. This thread will keep waiting, for KeepAliveTimeout seconds, just in
case the client would still send another request (which it may never do, depending on the
application).
Imagine that your application is so that the average client
- connects to your site
- sends a single HTTP request, which gets processed in 0.1 s
- receives the response
- and then goes away
and that the above sequence happens once every second, from different clients.
After one second, there will be one thread waiting for another 19 seconds before becoming
free (and potentially destroyed or re-used). After 2 seconds, there will be 2 such
threads. After 3 seconds, 3 threads. And so on. After 20 seconds, the first thread will be
freed, but there will be 19 other threads still waiting, and one new thread just created.
If everything stays perfectly regular like that, your will have /permanently/ 20 threads
in existence, even if the minimum is 10.
If you change the above so that there is a new client every 0.5 s, you will have
permanently 40 threads (of which only 2 maximum are really doing something).
The point is : KeepAlive is not "bad", and in some cases having a relatively long
KeepAliveTimeout is the right thing to do. Also, having a high number of threads sitting
idle is not necessarily a problem.
Your own scenario is probably not like the above perfectly regular and irrealistic one
above. But there may be a perfectly logical reason why you have so many threads on
average, and I am just trying to give you ideas for finding out the reason.
-----Original Message-----
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Monday, January 16, 2017 8:33 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 16.01.2017 03:41, Smith Hua wrote:
actually there is not much busy threads, less tahn 10,so i think this
parameter may has nothing to do with this
It depends on what you call "busy". What are the busy ones doing ? and what are
the non-busy ones doing ?
--
从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00 发件人 André Warnier
(tomcat) a...@ice-sa.com :
Hi.
I can find nothing really wrong in your configuration below.
But, what happens if in this section :
> <Connector port="8080" protocol="HTTP/1.1"
> maxThreads="300" connectionTimeout="20000"
> redirectPort="8443" />
you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20
seconds) ?
Do you still see the number of threads remaining at the maximum ?
See :
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
--> connectionTimeout
and the fact that it is also the default for
keepAliveTimeout
On 14.01.2017 07:30, smith wrote:
The server.xml:
<?xml version='1.0' encoding='utf-8'?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" at this level.
Documentation at /docs/config/server.html
-->
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<!-- Security listener. Documentation at /docs/config/listeners.html
<Listener className="org.apache.catalina.security.SecurityListener" />
-->
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener
className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener
className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener
className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<!-- Global JNDI resources
Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" Note: A "Service" is not itself a "Container",
so you may not define subcomponents such as "Valves" at this level.
Documentation at /docs/config/service.html
-->
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more
named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking &
non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="300" connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation that requires the JSSE
style configuration. When using the APR/native implementation, the
OpenSSL style configuration is required as described in the
APR/native
documentation -->
<!--
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https"
secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that
processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web
applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common"
-->
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
<Context path="" allowLinking="true" crossContext="true" docBase="/****/t"
sessionCookieName="****" />
</Host>
</Engine>
</Service>
</Server>
-----Original Message-----
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Friday, January 13, 2017 10:42 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 13.01.2017 09:38, smith wrote:
From: smith [mailto:smith....@zoom.us]
Sent: Tuesday, January 10, 2017 9:57 AM
To: 'users'
Subject: tomcat 8080 thread not reduced
Hi,
We have installed Apache Tomcat/8.0.14, and found that after one period of
time, the thread count for 8080(our port published) goes to 120 and never
reduced even the busy count is only 3-4.
Why? Tomcat8 not reduced the thread pool even the thread is idle, and the
minSpareThreads for tomcat8 default is only 10.
When will the thread reduce?
Best regards
Smith
Hi.
Please copy/paste your complete server.xml configuration file (confidential
things removed), so that we could have a useful look at it.
Please edit *only* the confidential things, not entire sections. Often, the
issue is in the details.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
