tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan_Macken...@Countrywide.Com
Subject Re: Performance tuning parameters
Date Fri, 16 Feb 2007 18:47:18 GMT
J.

This is what I've learnt in the last couple of months: 

- maxThreads
The maximum number of http worker threads that tomcat will create.  This 
is the limit of the number of concurrent http requests that the server can 
be servicing at any given moment.  If the thread is waiting for a database 
or webservice call , then the thread is just blocked but it is still part 
of the maxThreads count (750 in your example).  Tomcat will create more 
threads to do the other stuff that needs to be done.

- minSpareThreads
The number of new threads that tomcat will start when the threadpool has 
become full.    We have the number set down to 20 because it appears that 
the request that triggered the increase waits for all the threads to be 
created (i.e. the pool to get the new stock of threads), before the 
request is handed to one of those threads.

- maxSpareThreads
When the number of threads that have nothing to do in the threadpool gets 
to this number, tomcat will start removing threads from the threadpool, 
and killing them.

- acceptCount
This is the number of TCP connections that will be accepted even though 
there may not be a Thread immediately available to service them.  This 
means that in your example you could have 850 incoming request at any 
momemt, Request number 851 will be refused (received a connection 
refused).   We have the acceptCount set to half of the number of threads, 
so that there can be a "big" pile up of work, if our database suddenly 
gets a hickup.


Alan M




"Andrew Pliszka" <apliszka-public@alienforceit.com> 
02/16/2007 11:06 AM
Please respond to
"Tomcat Users List" <users@tomcat.apache.org>


To
"Tomcat Users List" <users@tomcat.apache.org>
cc

Subject
Re: Performance tuning parameters






Hi,

Do you have any load balancer? I am sorry if this is a trivial 
questions, but I have worked with cases that people have no load 
balancer and connections are just killing them.

Now, if you do not have a load balancer you might consider NetScaler, it 
might lower your number of connections considerably.

Andrew Pliszka
j r wrote:

> I am gleaning from your comments that MaxThreads is the only thing to
> tweak.  Yes I do really have a connection issue.  I have millions and
> millions of connection requests on a very small pool of servers.  The 
app
> has been tuned constantly over years.  I am either bound to buy more 
> servers
> or tweak tomcat to get more throughput.  In reality, I probably need 
> to do
> both.
>
> On a large pageview day, we will overflow the 750 MaxThreads.  This is
> noticed by the MaxThreads limit being exceeded error message.  We have
> tweaked all pieces of the tomcat config.  I was hoping a post here 
> could get
> more explanation of the parameters.  We have our experience to fall 
> back on,
> but I was hoping for more.
>
> If MaxThreads is the main thing to tweak, we will continue doing so. 
> There
> is a limit to this though.  You should create the funnel for customer
> requests (webserver limits, mod_jk limits, and tomcat limits). Exploding
> MaxThreads to a large number just to be large does not seem to fit with
> having an acceptCount value or the funnel that should be created.
>
>
> Thanks,
> J
>
> On 2/16/07, Andrew Miehs <andrew@2sheds.de> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear J,
>>
>> The focus should be on your application, and configuring everything
>> thing around that.
>>
>> If you REALLY have an out of  connection problem, increase Max
>> Threads to 10000, but I don't
>> think that will really help you. The problem is usually that each
>> individual request takes
>> tooo long, which again, points back to your application - There isn't
>> that much to tweak
>> in tomcat. Once you have configured your application, then you can
>> start looking at the
>> kernel - but these only bring small % improvements.
>>
>> Without more information - ie: current number of threads being used,
>> it is very
>> hard to answer your question.
>>
>> Cheers
>>
>> Andrew
>>
>> On 16/02/2007, at 4:43 AM, j r wrote:
>>
>> > The focus should be on the tomcat tweaking.  We get errors in the
>> > tomcat
>> > error logs that say tomcat has reached its connection limits.  I
>> > never said
>> > that it was serving slow.  It hits connection limits which means
>> > that the
>> > app will not serve any more traffic until connections clear.
>> >
>> > If a box definitely has more capacity (dual core, dual procs), then
>> > my best
>> > guess is that tomcat is not tuned perfectly to allow the max amount 
of
>> > connections in.  We have raised MaxThreads in the past to allow more
>> > connections in.  This works, but surely other knobs are important
>> > to be
>> > tweaked.
>> >
>> > I am looking for good definitions and/or best practices on which
>> > knobs to
>> > tweak to allow the max connections in before exhausting the jvm 
native
>> > memory allocation or cpu on the box.
>> >
>> >
>> >
>> > Thanks,
>> > J
>> >
>> > On 2/15/07, Andrew Miehs <andrew@2sheds.de> wrote:
>> >>
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> Dear J'
>> >>
>> >> What do you mean you are hitting connection limits?! Are you getting
>> >> errors? What are you seeing that makes you think that is slow?
>> >> Is there a database involved in this application?
>> >>
>> >> I assume you are running linux on your server, with a 2.6 kernel.
>> >>
>> >> run the following commands while your box
>> >>
>> >> 1)  ps auxH
>> >> 2)  ps auxH |grep -c java
>> >> 3)  vmstat 5 5
>> >> 4)  iostat 5 3
>> >>
>> >> Then we will have a bit of an idea what is going on.
>> >>
>> >> Andrew
>> >>
>> >>
>> >>
>> >>
>> >> On 15/02/2007, at 9:36 PM, j r wrote:
>> >>
>> >> > The reason it is hitting its limits is easy: traffic.  We easily
>> >> > get enough
>> >> > website traffic to overflow the connection limits unless I have
>> >> > many boxes
>> >> > available to serve.  I know these can be configured to handle more
>> >> > connections.  I know that we should be able to do this in the
>> >> tomcat
>> >> > server.  That is why I need those tweaking parameters defined.
>> >> >
>> >> >
>> >> >
>> >> > Thanks,
>> >> > j
>> >> >
>> >> > On 2/15/07, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
>> >> >>
>> >> >> First you should investigate why tomcat is hitting its limits.
>> >> >> Why do you think it does? Which resource is the limit?
>> >> >> Do you have/use any monitoring software? moskito? lambdaprobe?
>> >> >> tomcat-manager?
>> >> >>
>> >> >> regards
>> >> >> Leon
>> >> >>
>> >> >> On 2/15/07, j r <jreynolds11@gmail.com> wrote:
>> >> >> > I have searched for exact documentation on this, and I always
>> >> find
>> >> >> > conflicting info.  Therefore I am reaching out to this list.
 I
>> >> >> have the
>> >> >> > following info and questions:
>> >> >> >
>> >> >> > - we are running tomcat 5.5.20
>> >> >> > - we have the following configs in server.xml:
>> >> >> >            <Connector port="8009"
>> >> >> >                enableLookups="false" redirectPort="8443"
>> >> debug="0"
>> >> >> >                maxThreads="750" minSpareThreads="100"
>> >> >> maxSpareThreads="250"
>> >> >> >                acceptCount="100" connectionTimeout="5000"
>> >> >> > tomcatAuthentication="
>> >> >> >                false"
>> >> >> >
>> >> >> > - we have extra capacity (mem, cpu, etc.) on the servers,
yet
>> >> >> tomcat is
>> >> >> > hitting connection limits
>> >> >> > - we feel that tomcat can serve more, so what do we tune to

make
>> >> >> it do
>> >> >> so?
>> >> >> >     - maxThreads?
>> >> >> >     - minSpareThreads?
>> >> >> >     - maxSpareThreads?
>> >> >> >     - acceptCount?
>> >> >> >
>> >> >> >
>> >> >> > Honestly, I would rather love an exact definition of what
each
>> >> >> of those
>> >> >> > would do to the tomcat server if tweaked.  Knowing that would

be
>> >> >> nirvana
>> >> >> for
>> >> >> > tuning.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > -j
>> >> >> >
>> >> >>
>> >> >>
>> >> 
---------------------------------------------------------------------
>> >> >> To start a new topic, e-mail: users@tomcat.apache.org
>> >> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >> >> For additional commands, e-mail: users-help@tomcat.apache.org
>> >> >>
>> >> >>
>> >>
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.4.1 (Darwin)
>> >>
>> >> iD8DBQFF1NaFW126qUNSzvURAuxZAJ4ugkLObXKHJZsSIfX3SWzZzv5vlQCdHXeV
>> >> jSPVOQqZXoxvlQc7Q94vMlA=
>> >> =YSSz
>> >> -----END PGP SIGNATURE-----
>> >>
>> >> 
---------------------------------------------------------------------
>> >> To start a new topic, e-mail: users@tomcat.apache.org
>> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: users-help@tomcat.apache.org
>> >>
>> >>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Darwin)
>>
>> iD8DBQFF1XNhW126qUNSzvURAtjIAJsHhDX6gXQFPi9UFnFgCPHqB0yGCgCeM7mg
>> e41/HBE3bGRaol1JAJh81ds=
>> =5ZBO
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




======================================================================
Confidentiality Notice: The information contained in and transmitted with this communication
is strictly confidential, is intended only for the use of the intended recipient, and is the
property of Countrywide Financial Corporation or its affiliates and subsidiaries.  If you
are not the intended recipient, you are hereby notified that any use of the information contained
in or transmitted with the communication or dissemination, distribution, or copying of this
communication is strictly prohibited by law.  If you have received this communication in error,
please immediately return this communication to the sender and delete the original message
and any copy of it in your possession.
======================================================================

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message