Ok.
Required details are as below.
current configuration.
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
>> 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 ?
It happens only at specific time. While trying to hit some api and response
did not received in time. For such request I have kept the time out of 100
seconds (that is the requirement). As the first request/thread itself is in
waiting mode new incoming request/thread will be very slow and after some
time logout issue will occur or it will slow down the performance for other
requests and resultant site will be loading very slow. Moreover, it will
start throwing below errors. Henceforth, decided to increase incoming
connection request. I am not sure whether acceptQueue or some another
parameter need to add.
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
>> The browser clients trying to get a connection to Tomcat, or the
postgres database which you seem to be using for authentication ?
We have three tier architect. It will first try to get the connection
from web server (haporxy) to tomcat and then to database.
On Mon, Aug 4, 2014 at 2:58 AM, André Warnier <a...@ice-sa.com> wrote:
> 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
>
>
