tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Increasing incoming connection request in a queue
Date Sun, 03 Aug 2014 21:28:30 GMT

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>
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
- 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

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)


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 
- 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. 

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:
For additional commands, e-mail:

View raw message