Hi.
There are a number of problems with your post, which make it difficult to understand
exactly what you want to know.
Dhaval Jaiswal wrote:
acceptCount variable:
Following is the current configuration in server.xml I am using version. 6.
Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
That tag is incomplete.
Resource name="jdbc/DB_NAME" auth="Container" type="javax.sql.DataSource"
driverClassName="org.
postgresql.Driver" url="jdbc:postgresql://IP:PORT/DB_NAME"
username="" password=""
maxActive="100" maxIdle="20" maxWait="30000"
validationQuery="select 1" testOnBorrow="true"
removeAbandoned="true" removeAbandonedTimeout="120"
logAbandoned="true" />
That tag is also incomplete, and it has basically nothing to do with the <Connector> tag
above (nor with acceptCount or maxThreads).
Planning to add below parameters.
maxThreads="20000"
acceptCount="500"
Where ?
The situation I got is some times i am not getting timely response from the
outsiders.
What is "the outsiders" ? The browser clients trying to get a connection to Tomcat, or
the postgres database which you seem to be using for authentication ?
In this case i need to make the bigger queue in connection pool.
What connection pool ?
As per document and forums says default queue size of acceptCount is 100.
During the time if new connection request comes in it simply refuse it.
That has nothing to do with any "connection pool".
A new connection (from a client) will be refused if :
- all Tomcat threads of the Connector are already busy handling other requests
AND
- there are already "acceptCount" previous connection requests waiting for an accept in
the "accept queue" of the Connector
1)
I just do not want to refuse the new connection, but want to keep that
connection in a pool.
That does not really make sense, as a phrase.
I want to make the queue size of 500 and if possible
more than that.
Why ?
What is your opinion on below configuration. Will it help me. Is it going
to degrade the performance if i will increase the value of acceptCount
variable along with maxThreads.
maxThreads="20000"
acceptCount="500"
These two parameters are not directly related, and each of those parameters should only be
modified (compared to the default) in very specific circumstances.
We cannot have an opinion on whether changing one or the other will help or not, before we
know
1) if you really have a problem now, or if you are just speculating without real facts. If
you have a real problem, what is it ? is your Tomcat really refusing browser connections ?
if yes, does this happen all the time, or only at specific times ?
2) what is the expected load of your server ? how many clients are expected to connect to
your server at the same time ? how many HTTP requests are you expecting to have to process
at the same time ? how long does it take, on average, to process one request ?
3) what are the characteristics of your server ? (how fast is the CPU, how much memory
does it have, how much of that is available to Tomcat)
etc..
Here are some general tips :
1) the default parameters of Tomcat are set by people who know what they are doing, in a
way that they determine is appropriate for the large majority of practical cases.
There are thousands of Tomcats which are running fine on the WWW, using these default
parameters. Changing them without knowing why, and without konwing exactly what effect
they have, is more likely to make the situation worse, than improving it.
2) to determine if you need to change a parameter, and which parameter to change and how
to change it, you need first to *measure* what is happening.
2) the "acceptCount" of the Connector is a parameter which relates to the TCP/IP stack of
your machine. Tomcat just passes this parameter to the underlying OS, when it opens the
TCP socket which is used by this Connector. It is the TCP/IP stack of the OS which is
going to refuse new client connections, if the "accept queue" fills up.
The "accept queue" fills up, when Tomcat (for any of many possible reasons) cannot handle
anymore the number of client requests which arrive over a period of time.
3) the "maxThreads" parameter of a Connector, represents how many threads maximum, this
Connector can start at the same time. Each of those threads handles one request of one
client. So, *if you know* :
a) that it takes on average 1 second for your Tomcat (and your webapp) to
process one request
b) that, sometimes, there can be 300 clients sending one request each to your Tomcat over
1 second (for a total of 300 requests over the same second)
then, you would know that you need to set the maxThreads parameter to (at
least) 300.
If processing one request takes on average 2 seconds, then if during 1 second Tomcat can
receive 300 requests, you will need to set maxThreads higher (because at the end of this
first second, the first 300 threads will still be busy; and another series of 300 requests
is coming in, and there are no available (non-busy) threads to handle them).
But of course, each running thread uses up some resources (CPU, memory), so the maximum
number of threads that you can effectively set will depend on the total resources
available on your machine.
4) when Tomcat cannot handle the volume of requests which clients are sending to it, there
can be a number of reasons, such as :
- the maximum number of threads (maxThreads) is not high enough
- the application is "too slow" (meaning: it takes longer than you think, to process one
request)
- there is not enough memory
- the CPU is too slow
- the Java JVM is not properly configured
- some parameter is not set correctly
etc.. etc.. etc..
You need to find out which one of the above is the cause, and then rectify that
cause.
Changing a parameter randomly is not the good way to go.
Changing more than one parameter at a time is even worse, because many of these parameters
have indirect effects on one another.
5) if the problem is that Tomcat cannot handle the volume of requests, then increasing the
size of the accept queue is not going to help. It will only delay a bit more the "server
busy" message that the clients will receive, which will frustrate them even more.
2)
As tomcat works on FIFO (first in first out) model. Is there any way to
override the precedence of connection.
No.
In any case, what would be the point, and how would you determine which connection request
should be handled in priority compared to any other ?
I know its quite not possible.
However, in case some one has any thought on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
