You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by mo...@polarisFT.com on 2013/09/19 14:25:47 UTC

MaxClients and maxThreads

Hi,
        I am following the instructions in 
https://access.redhat.com/site/articles/15786 to tune MaxClients in 
httpd.conf and maxThreads in JBoss Tomcat. 

" The recommended value of maxThreads is 200 per CPU, so here we assume 
the server is a single core machine. If it had
  been quad core we could push that value to 800 or more depending on RAM 
and other machine specs. The total threads
  is an aggregate value. If Apache and JBOSS are on the same server, and 
that server has four cores, then you would halve
  the maxThreads and MaxClients to 400 each."

I have this question. Does this mean that maxThreads and MaxClients should 
both be equal to each other  ?

My configuration is this.
Machine 1 - JBoss and Apache(2 cores)
Machine 2 - JBoss(2 cores)

So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited 
by MaxClients in Machine 1 which should be only 200. Is that correct ? It 
is a bottleneck.

Thanks,
Mohan


This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

Re: MaxClients and maxThreads

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris,

On 9/21/13 9:53 AM, chris derham wrote:
>> 
>> To add to what Daniel is saying, here is a little graphic
>> representation, for one single client browser :
>> 
>> (browser) <-- HTTP --> (httpd + mod_jk) <-- AJP --> (tomcat) <-->
>> (webapp) (1) | |- (local resources) (2)
>> 
>> When the browser sends a request to httpd, one httpd child/thread
>> is allocated to process that request and return a response to the
>> client.  That child/thread is busy with this one request, from
>> the time the request is received to the time when the response
>> has been sent. 2 cases are possible : a) the request is for
>> something that can be served directly by httpd, without need to
>> involve Tomcat.  That is the (2) above.  For example, in some
>> configurations, static HTML pages, images, stylesheets etc. are
>> served directly by httpd, and only requests for "webapps" are
>> forwarded to Tomcat. b) the request is for something that has to
>> be processed and served by Tomcat (the (1) above).  In that case,
>> httpd + mod_jk will forward the request to Tomcat, and wait for
>> Tomcat's response. When Tomcat responds, httpd + mod_jk will
>> return that response to the browser client. While Tomcat is
>> processing that request, you have one Tomcat thread busy 
>> processing that request, and one httpd child/thread waiting for
>> Tomcat to respond.
>> 
>> So let's say that at the level of httpd, there are 1000 browser
>> requests coming in every minute.  The number of httpd
>> children/threads needed to handle this, depends on how long it
>> takes httpd, on average, to process each request.  If it takes on
>> average 1 second to process a request, then each httpd
>> child/thread can on average process 60 requests per minute, and
>> to handle 1000 requests per minute, you need 1000/60 = 16.66
>> children/threads in httpd. Now estimate (or better, measure) how
>> many of these requests are being forwarded to Tomcat, and how
>> long Tomcat needs on average to process such a request and send a
>> response. With the same kind of calculation, this will tell you
>> how many threads you need in Tomcat.
>> 
>> Now to be on the safe side, double these numbers (if your servers
>> support that), and try it out, /with your application/, measure
>> what happens, and rectify the configuration accordingly.
>> 
>> The main point is : nobody except yourself knows exactly how
>> your application works, how many requests are really served by
>> httpd and tomcat, or how long it takes to process one request.
>> So nobody can tell you in advance how many threads/children you
>> need in httpd or Tomcat, to serve your volume of requests.
>> 
>> The best that the Apache httpd developers, and the Tomcat
>> developers can do, is to provide some "best guess" defaults, for
>> some configuration that will, in their considerate opinion, be
>> adequate for serving some average needs and not be very
>> unbalanced. And that's what they do, and that is why you should
>> generally start with this default configuration.  And then, if
>> you can see and *measure* that there is something wrong, start
>> amending this configuration item by item carefully, and measure
>> again after each change to see if it improves or worsens the
>> situation. There is no "one size fits all". (If there was, then
>> the developers would just set it as the default, and they would
>> not need to provide any adjustable parameters).
>> 
> 
> This type of question seems to come up once every 3 months on the 
> mailing list. Given that this is a beautiful explanation, perhaps
> "we" could add this as a new section to the tomcat documentation -
> a new "Performance Tuning" section?

Anyone can edit the wiki -- after they request an account if one does
not yet exist. Feel free to put-up a wiki page.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSQDYJAAoJEBzwKT+lPKRY57oP/jhjkeQMBrmnqzlX2f90Elfn
7ll3iBeYqaZnFrEdzWXuVLtSc4YgAXYvdZmI29MNv8dI+caXrj5oywecGo5w7nn5
Tl1+gk6MO8tqxjs8mY5NjiTRL+mD9dBLYIGbztlA15+5V3oSzPyop0ydlWjtu+uk
4Sj99JAq175rvPxJB/ob9LDX0sETnM4F1fXfoZz55OkYGzaMMxcHigbSTmckdrWr
cvLwSGn2zjdYAOZW+nWEM7iVnCR4MMXJSskIo67i5wOy89vzmUjS0tt1fl38a4GW
lkf/qVLPtI8qOboLNGW1b1d6zrqYJULXovfmqEZ3h9KTcvQ1SSI9nrCxfFZZ6x2F
k5pGWCPXrlnwxP9fKswR1LgYz+y9KynHaFNH2wVaCqX6WdXzK5Vk+GtbJc/IBZHJ
pNnw4UhFFGk87tiW3wofM5wcgBQpZbQRgfkBSJ14GN/nnYHovQMVmiK+VqsvMU3m
oSCGdgyYFdfqdPqGvo5J//BMX9zg9t4mk8vkCpNlvFR9onvZD9TyDYh8/5Kjlnfb
cv96n5xV/DiLGq7gUTFnXSFouXUDLhe9bCRnH7npkY2njZcodLRnaMopVdei/Xj1
V+6H30RniIMSEDyRBfq4Db/yvGeG9XGFsHY9wl6XxOj3btp62MDWKjLdYoJ7ECWX
Mnb9lHGSaxAw/1BjiEpf
=aYEa
-----END PGP SIGNATURE-----

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


Re: MaxClients and maxThreads

Posted by chris derham <ch...@derham.me.uk>.
>
> To add to what Daniel is saying, here is a little graphic representation,
> for one single client browser :
>
> (browser) <-- HTTP --> (httpd + mod_jk) <-- AJP --> (tomcat) <--> (webapp)
> (1)
>                              |
>                              |- (local resources) (2)
>
> When the browser sends a request to httpd, one httpd child/thread is
> allocated to process that request and return a response to the client.  That
> child/thread is busy with this one request, from the time the request is
> received to the time when the response has been sent.
> 2 cases are possible :
> a) the request is for something that can be served directly by httpd,
> without need to involve Tomcat.  That is the (2) above.  For example, in
> some configurations, static HTML pages, images, stylesheets etc. are served
> directly by httpd, and only requests for "webapps" are forwarded to Tomcat.
> b) the request is for something that has to be processed and served by
> Tomcat (the (1) above).  In that case, httpd + mod_jk will forward the
> request to Tomcat, and wait for Tomcat's response.
> When Tomcat responds, httpd + mod_jk will return that response to the
> browser client.
> While Tomcat is processing that request, you have one Tomcat thread busy
> processing that request, and one httpd child/thread waiting for Tomcat to
> respond.
>
> So let's say that at the level of httpd, there are 1000 browser requests
> coming in every minute.  The number of httpd children/threads needed to
> handle this, depends on how long it takes httpd, on average, to process each
> request.  If it takes on average 1 second to process a request, then each
> httpd child/thread can on average process 60 requests per minute, and to
> handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads
> in httpd.
> Now estimate (or better, measure) how many of these requests are being
> forwarded to Tomcat, and how long Tomcat needs on average to process such a
> request and send a response.
> With the same kind of calculation, this will tell you how many threads you
> need in Tomcat.
>
> Now to be on the safe side, double these numbers (if your servers support
> that), and try it out, /with your application/, measure what happens, and
> rectify the configuration accordingly.
>
> The main point is : nobody except yourself knows exactly how your
> application works, how many requests are really served by httpd and tomcat,
> or how long it takes to process one request.  So nobody can tell you in
> advance how many threads/children you need in httpd or Tomcat, to serve your
> volume of requests.
>
> The best that the Apache httpd developers, and the Tomcat developers can do,
> is to provide some "best guess" defaults, for some configuration that will,
> in their considerate opinion, be adequate for serving some average needs and
> not be very unbalanced.
> And that's what they do, and that is why you should generally start with
> this default configuration.  And then, if you can see and *measure* that
> there is something wrong, start amending this configuration item by item
> carefully, and measure again after each change to see if it improves or
> worsens the situation.
> There is no "one size fits all".
> (If there was, then the developers would just set it as the default, and
> they would not need to provide any adjustable parameters).
>

This type of question seems to come up once every 3 months on the
mailing list. Given that this is a beautiful explanation, perhaps "we"
could add this as a new section to the tomcat documentation - a new
"Performance Tuning" section?

Chris

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


Re: MaxClients and maxThreads

Posted by André Warnier <aw...@ice-sa.com>.
Daniel Mikusa wrote:
> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:
> 
>> Is this a hard limit ?
> 
> No.
> 
>> So if there are 4 cores there can only be 800 
>> concurrent clients. None of our banks is calculating this like this and 
>> some have Apache and JBoss on the same machine which further limits the 
>> threads.
>>
>> Appreciate any help.
>>
>> Hi,
>>        I am following the instructions in 
>> https://access.redhat.com/site/articles/15786 to tune MaxClients in 
>> httpd.conf and maxThreads in JBoss Tomcat. 
>>
>> " The recommended value of maxThreads is 200 per CPU, so here we assume 
>> the server is a single core machine. If it had
>>  been quad core we could push that value to 800 or more depending on RAM 
>> and other machine specs. The total threads
>>  is an aggregate value. If Apache and JBOSS are on the same server, and 
>> that server has four cores, then you would halve
>>  the maxThreads and MaxClients to 400 each."
> 
> Don't base your performance tuning on values you found in an article online.  The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application.  By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many.  Examine your needs, set the values you think will work and then load test to see how things perform.  Adjust the settings further based on your load testing results.
> 
> Dan
> 
>> I have this question. Does this mean that maxThreads and MaxClients should 
>>
>> both be equal to each other  ?
>>
>> My configuration is this.
>> Machine 1 - JBoss and Apache(2 cores)
>> Machine 2 - JBoss(2 cores)
>>
>> So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited 
>>
>> by MaxClients in Machine 1 which should be only 200. Is that correct ? It 
>> is a bottleneck.
>>

To add to what Daniel is saying, here is a little graphic representation, for one single 
client browser :

(browser) <-- HTTP --> (httpd + mod_jk) <-- AJP --> (tomcat) <--> (webapp) (1)
                              |
                              |- (local resources) (2)

When the browser sends a request to httpd, one httpd child/thread is allocated to process 
that request and return a response to the client.  That child/thread is busy with this one 
request, from the time the request is received to the time when the response has been sent.
2 cases are possible :
a) the request is for something that can be served directly by httpd, without need to 
involve Tomcat.  That is the (2) above.  For example, in some configurations, static HTML 
pages, images, stylesheets etc. are served directly by httpd, and only requests for 
"webapps" are forwarded to Tomcat.
b) the request is for something that has to be processed and served by Tomcat (the (1) 
above).  In that case, httpd + mod_jk will forward the request to Tomcat, and wait for 
Tomcat's response.
When Tomcat responds, httpd + mod_jk will return that response to the browser client.
While Tomcat is processing that request, you have one Tomcat thread busy processing that 
request, and one httpd child/thread waiting for Tomcat to respond.

So let's say that at the level of httpd, there are 1000 browser requests coming in every 
minute.  The number of httpd children/threads needed to handle this, depends on how long 
it takes httpd, on average, to process each request.  If it takes on average 1 second to 
process a request, then each httpd child/thread can on average process 60 requests per 
minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads 
in httpd.
Now estimate (or better, measure) how many of these requests are being forwarded to 
Tomcat, and how long Tomcat needs on average to process such a request and send a response.
With the same kind of calculation, this will tell you how many threads you need in Tomcat.

Now to be on the safe side, double these numbers (if your servers support that), and try 
it out, /with your application/, measure what happens, and rectify the configuration 
accordingly.

The main point is : nobody except yourself knows exactly how your application works, how 
many requests are really served by httpd and tomcat, or how long it takes to process one 
request.  So nobody can tell you in advance how many threads/children you need in httpd or 
Tomcat, to serve your volume of requests.

The best that the Apache httpd developers, and the Tomcat developers can do, is to provide 
some "best guess" defaults, for some configuration that will, in their considerate 
opinion, be adequate for serving some average needs and not be very unbalanced.
And that's what they do, and that is why you should generally start with this default 
configuration.  And then, if you can see and *measure* that there is something wrong, 
start amending this configuration item by item carefully, and measure again after each 
change to see if it improves or worsens the situation.
There is no "one size fits all".
(If there was, then the developers would just set it as the default, and they would not 
need to provide any adjustable parameters).


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


Re: MaxClients and maxThreads

Posted by André Warnier <aw...@ice-sa.com>.
Who, moi ?

MiB wrote:
> 23 sep 2013 09.00 André Warnier:
> 
>> Do not top-post. It makes it difficult to follow the conversation, who answers to what etc.
>>
>>> From:   Daniel Mikusa <dm...@gopivotal.com>
>>> To:     "Tomcat Users List" <us...@tomcat.apache.org>
>>> Date:   09/20/2013 07:10 PM
>>> Subject:        Re: MaxClients and maxThreads
>>> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:
> 
> And that was a top post you just posted.
> 
Yes, but it was difficult to do otherwise in this case, and it was a good illustration.


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


Re: MaxClients and maxThreads

Posted by MiB <di...@gmail.com>.
23 sep 2013 09.00 André Warnier:

> Do not top-post. It makes it difficult to follow the conversation, who answers to what etc.
> 
>> From:   Daniel Mikusa <dm...@gopivotal.com>
>> To:     "Tomcat Users List" <us...@tomcat.apache.org>
>> Date:   09/20/2013 07:10 PM
>> Subject:        Re: MaxClients and maxThreads
>> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:

And that was a top post you just posted.


Re: [a bit OT] MaxClients and maxThreads

Posted by André Warnier <aw...@ice-sa.com>.
David kerber wrote:
> On 9/24/2013 12:11 AM, mohan.radhakrishnan@polarisFT.com wrote:
>> Yes. That is probably the capacity planning part that involves think time
>> analysis and concurrency.
>>
>> What Were They Thinking:
>> Modeling Think Times for Performance Testing
>> Tom Wilson
>>
>> from Computer Measurement Group is what I plan to refer to. But don't 
>> know
>> yet how to mine this from awstats.
>>
>> The Redhat link describes it like this
>>
>> MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 )
>>          mod_jk default connection pool
>> Each worker has a connection pool and by default the connection pool size
>> is equal to ThreadsPerChild( 25 )
>> In the default case each worker has 25 connections multiplexed over 12
>> processes equaling 300.   Two workers will have  300 x 2 =600
>> connections to Jboss.
>>
>> But I don't understand how one core with 2 hardware threads can support
>> 200 threads. I don't get that calculation. The problem is that when I 
>> draw
>> a throughput graph using think time analysis and concurrent connections
>> estimate I have to use 800 threads for a 4-core system if we have only
>> Apache there.
> 
> As Andre says, it all depends on what those threads are doing, and that 
> in turn depends almost entirely on your application.  In some cases, you 
> might be able to support 800 threads per core, and in others 50 per core 
> might be overloading it.  You have to benchmark your application and 
> figure out what (if anything) is limiting you.
> 

Mohan,
/yet) another way of looking at this : you are never really "overloading a core". A core 
works at a fixed speed, it executes basic instruction cycles at a speed which depends on 
the hardware clock of the system (2.3 Ghz etc..).  What happens is that if there is only 
one runnable program thread, then all the available cycles of the core can be dedicated to 
that one thread, and the series of instructions to be executed for that one thread to 
provide the desired result (for example, a HTTP response by a Tomcat webapp) will 
terminate very quickly, and the response will be "very fast".
If on the other hand there are 200 runnable threads due to Tomcat webapps being triggered 
by 200 simultaneous client requests, then this core will "time-share" between these 200 
threads, and each webapp response will take 200 times longer to finish, than in the 
previous case.  And if there are 500 runnable threads and only one core, then each 
response will just take 500 times longer than if there was only one thread.
And if there are 500 runnable threads and 2 cores available, then each response will 
possibly take only 250 times more time than if there was a single thread runnable.
(And I say "possibly" because webapp threads most probably do not only require CPU cycles 
in order to provide a response; they probably also need memory and/or disk I/O, in which 
case having more or less cores is not the main element).

And then, have a look at one of your systems, with "top" (if you are under Linux) or the 
Task Manager (under Windows), and look at how many processes are running, apart from 
Apache httpd and Tomcat.  Well, all of those processes compete with httpd and Tomcat for 
the same cores (and the same memory and the same I/O bandwidth).  So how would that ever 
combine with some preset figure of "200 Tomcat threads per core" ?  What about these other 
processes, do they not count ?

Now that can all be fine.  If you server receives 100 client requests per second, and each 
request basically needs 1.5 ms of "system time" (*) to complete, then in total over that 
second you have only used 100 x 1.5 ms = 150 ms of "system time", and during the remaining 
850 ms of that second, your system is idle and just doing nothing.
If you increase this to 500 client requests per second, then you will be using 500 x 1.5 
ms = 750 ms of system time every second, and you still have 250 ms available doing 
nothing.  But if you increase this to 1000 requests per second, then you would need 1000 x 
1.5 ms = 1.5 s second of system time every second, and then clearly you have a problem : 
only 666 of those client requests can be served in 1 second (1000 requests / 1.5 ms), so 
334 requests will have to wait.
If during the next second, there are only 200 requests coming in, then that is still fine 
: that next second of system time will be able to process 100 new requests + 334 delayed 
requests, and everything will still run smoothly, because there is some buffering in the 
system to absorb a temporary excess of requests.  But if 1000 requests per second is a 
permanent occurrence, then you have some choices :
- just decide that the clients have to wait
- improve your application to take less time
- or get a bigger system

There is no magic formula which will tell you in advance at which point your *system* is 
going to be overloaded (symptom: clients complain because they have to wait too long; 
other symptoms : your "top" display shows a permanent 100% CPU time, or 100% I/O wait 
time, or 100% memory usage).
You must benchmark and log, and analyse the results.


(*) that is the total of
- CPU cycle times in Tomcat and in your webapp
- CPU cycle time in the OS and in the other running processes
- disk I/O time needed by your webapp
- network I/O time needed by your webapp
- memory management time needed to provide memory to your webapp
- etc. etc.

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


Re: MaxClients and maxThreads

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David,

On 9/24/13 7:47 AM, David kerber wrote:
> On 9/24/2013 12:11 AM, mohan.radhakrishnan@polarisFT.com wrote:
>> Yes. That is probably the capacity planning part that involves
>> think time analysis and concurrency.
>> 
>> What Were They Thinking: Modeling Think Times for Performance
>> Testing Tom Wilson
>> 
>> from Computer Measurement Group is what I plan to refer to. But
>> don't know yet how to mine this from awstats.
>> 
>> The Redhat link describes it like this
>> 
>> MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 ) 
>> mod_jk default connection pool Each worker has a connection pool
>> and by default the connection pool size is equal to
>> ThreadsPerChild( 25 ) In the default case each worker has 25
>> connections multiplexed over 12 processes equaling 300.   Two
>> workers will have  300 x 2 =600 connections to Jboss.
>> 
>> But I don't understand how one core with 2 hardware threads can
>> support 200 threads. I don't get that calculation. The problem is
>> that when I draw a throughput graph using think time analysis and
>> concurrent connections estimate I have to use 800 threads for a
>> 4-core system if we have only Apache there.
> 
> As Andre says, it all depends on what those threads are doing, and
> that in turn depends almost entirely on your application.

Specifically, whether your application is CPU-bound or I/O bound. Most
web applications that I have analyzed are almost entirely I/O bound:
they spend most of their time waiting around for data to be ready
(from a disk, network resource, database, etc.). This is why a 2-core
CPU can handle 200 threads simultaneously: because at any given
moment, only a few threads have anything worthwhile to do: the rest
are sleeping waiting on an I/O event to occur.

Run "top" on your server and watch the "load average". Most *NIX
systems define load average as the average length of the run-queue.
The run-queue is the number of processes that are actively waiting for
the CPU to give them time (e.g. they are "runnable" and not waiting on
I/O). You'll see 3 numbers: usually the 1-minute average, the 5-minute
average, and the 15-minute average. On my development server right
now, those numbers are "1.82, 2.46, 2.18". That means that I have
roughly 2 processes waiting in the run queue all the time. I have a
2-core machine (well, it's virtualized so the hypervisor is probably
lying to me, but anyway...) so a run-queue of 2 is just about right.
If the run queue starts to approach something like 2x the number of
cores I have available, I have to consider whether an upgrade is in order.

Run a load-test on your hardware and watch everything: load average,
response times, etc. Response time is king, of course, but the
load-average can give you some insight into how "hard" the server is
actually working. If your response times are within your acceptable
thresholds for usability, then look to the load average for a clue as
to how much more load you might be able to take. If you have a 4-core
machine and the load average is 2 (during a load test), then you can
probably take a lot more load. Obviously, you must re-test with more
load to confirm that you can sustain that kind of load instead of just
guessing based upon a small load + favorable load average.

> In some cases, you might be able to support 800 threads per core,
> and in others 50 per core might be overloading it.  You have to
> benchmark your application and figure out what (if anything) is
> limiting you.

+1

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSQZ8uAAoJEBzwKT+lPKRY2UwP/iGoU6rGZ1cyis7rhnevRwir
bj/A3hY7XkpkOw30QrdGpbnu3qIZpPWn04rgjXjByWa1tBvheMs5+JSx8wVJoKdy
NAP0eLnMRHejEyC3ysJJP1DbsLrZ5DYZG87jXIrCb+vbL52TdklwdB3zNSLskZ+N
QuINAlHt/vFC/GwQSv6tATzuCNToKpR1BFUazw6sK+8D2QNjA98bLH2trK1Q2Vin
vSOGUMOJUCWsY7QMZxVwfaWEiwaE52HUYZws0ocZzGmQBdoXaLiMYSmdsiJvlHB6
ITb108Qwp7n1CM5ImkWTLu+/lpFWBLisM896Uh6zcNXOAmj0XU0w0p/CCyVzq2Lz
NN6GBzXOWsGC8UC8cR86bzq4EwGzQ9ck+8q3oocR/rEpIG+5BexjDcWHuuqZm9xz
KITQnMOuZV/OCjX86SO0CB9gYY/yNTrGyHOIg3nKT49wdCTMhpMArm9rWcT9UKNl
aM2rQDJQjTJG5Po5d6p9AAYcnxibjEJYRbzr0EHGGjhrPfsTOvFTYqBMLlrFDdZs
qUTi7LiOyvQpuVEAbGZTZSwEQwpBI2Bu/GuzdlU6tGUoBvApkmKt+bxK0IeZ8EW9
pNZOK832W/y4Yd0sjKAb71DqYwR06JXZykqh8I2sTJHfOmAo4xA9GcRoJ0oeN/0g
opS6qoWmKXsmQ6AjuicJ
=+Lqr
-----END PGP SIGNATURE-----

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


Re: MaxClients and maxThreads

Posted by David kerber <dc...@verizon.net>.
On 9/24/2013 12:11 AM, mohan.radhakrishnan@polarisFT.com wrote:
> Yes. That is probably the capacity planning part that involves think time
> analysis and concurrency.
>
> What Were They Thinking:
> Modeling Think Times for Performance Testing
> Tom Wilson
>
> from Computer Measurement Group is what I plan to refer to. But don't know
> yet how to mine this from awstats.
>
> The Redhat link describes it like this
>
> MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 )
>          mod_jk default connection pool
> Each worker has a connection pool and by default the connection pool size
> is equal to ThreadsPerChild( 25 )
> In the default case each worker has 25 connections multiplexed over 12
> processes equaling 300.   Two workers will have  300 x 2 =600
> connections to Jboss.
>
> But I don't understand how one core with 2 hardware threads can support
> 200 threads. I don't get that calculation. The problem is that when I draw
> a throughput graph using think time analysis and concurrent connections
> estimate I have to use 800 threads for a 4-core system if we have only
> Apache there.

As Andre says, it all depends on what those threads are doing, and that 
in turn depends almost entirely on your application.  In some cases, you 
might be able to support 800 threads per core, and in others 50 per core 
might be overloading it.  You have to benchmark your application and 
figure out what (if anything) is limiting you.

D



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


Re: MaxClients and maxThreads

Posted by André Warnier <aw...@ice-sa.com>.
mohan.radhakrishnan@polarisFT.com wrote:
> Yes. That is probably the capacity planning part that involves think time 
> analysis and concurrency.
> 
> What Were They Thinking:
> Modeling Think Times for Performance Testing
> Tom Wilson
> 
> from Computer Measurement Group is what I plan to refer to. But don't know 
> yet how to mine this from awstats.
> 
> The Redhat link describes it like this
> 
> MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 )
>         mod_jk default connection pool
> Each worker has a connection pool and by default the connection pool size 
> is equal to ThreadsPerChild( 25 )  
> In the default case each worker has 25 connections multiplexed over 12 
> processes equaling 300.   Two workers will have  300 x 2 =600
> connections to Jboss.
> 
> But I don't understand how one core with 2 hardware threads can support 
> 200 threads. I don't get that calculation. 

And you are right in not understanding it, because there is no such calculation. 200 
threads doing what ? printing "Hello World" or calculating the GDP of China ?

The problem is that when I draw
> a throughput graph using think time analysis and concurrent connections 
> estimate I have to use 800 threads for a 4-core system if we have only 
> Apache there. 
> 
Why do you not just forget about the cores. They are not really relevant here.
For the last 30 years, computers have been doing time-sharing between multiple processes. 
That means that the same CPU can handle multiple processes running "at the same time".
Having more than one core just means that the same CPU can, at certain times, be 
processing more than one task at the same time.  For all practical intents and purposes, 
it is basically the same as having one core that is twice (or 3, 4 times) as fast.

What is important here is how many client requests your chosen architecture can process in 
any chosen amount of time.  And that depends for 90% on your application(s).
So take the default values for everything (because at least they are not severely 
unbalanced), and *measure* how your system is doing under load.  If you are statisfied, 
leave it at that and do the same on another system.  If you are not satisfied, /then/ is 
the time to start looking deeper. But then you'll be doing it with some basic numbers to 
compare against, and not in the dark like now.



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


Re: MaxClients and maxThreads

Posted by mo...@polarisFT.com.
Yes. That is probably the capacity planning part that involves think time 
analysis and concurrency.

What Were They Thinking:
Modeling Think Times for Performance Testing
Tom Wilson

from Computer Measurement Group is what I plan to refer to. But don't know 
yet how to mine this from awstats.

The Redhat link describes it like this

MaxClients( 300 ) /  ThreadsPerChild( 25 ) = Processes( 12 )
        mod_jk default connection pool
Each worker has a connection pool and by default the connection pool size 
is equal to ThreadsPerChild( 25 )  
In the default case each worker has 25 connections multiplexed over 12 
processes equaling 300.   Two workers will have  300 x 2 =600
connections to Jboss.

But I don't understand how one core with 2 hardware threads can support 
200 threads. I don't get that calculation. The problem is that when I draw 
a throughput graph using think time analysis and concurrent connections 
estimate I have to use 800 threads for a 4-core system if we have only 
Apache there. 

Mohan



From:   Christopher Schultz <ch...@christopherschultz.net>
To:     Tomcat Users List <us...@tomcat.apache.org>
Date:   09/23/2013 06:14 PM
Subject:        Re: MaxClients and maxThreads



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 9/23/13 3:00 AM, André Warnier wrote:
> Do not top-post. It makes it difficult to follow the conversation,
> who answers to what etc.
> 
>> 
>> 
>> From:   Daniel Mikusa <dm...@gopivotal.com> To:     "Tomcat
>> Users List" <us...@tomcat.apache.org> Date:   09/20/2013 07:10
>> PM Subject:        Re: MaxClients and maxThreads
>> 
>> 
>> 
>> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com
>> wrote:
>> 
>>> Is this a hard limit ?
>> 
>> No.
>> 
>>> So if there are 4 cores there can only be 800 concurrent
>>> clients. None of our banks is calculating this like this and
>>> some have Apache and JBoss on the same machine which further
>>> limits the threads.
>>> 
>>> Appreciate any help.
>>> 
>>> Hi, I am following the instructions in 
>>> https://access.redhat.com/site/articles/15786 to tune
>>> MaxClients in httpd.conf and maxThreads in JBoss Tomcat. " The
>>> recommended value of maxThreads is 200 per CPU, so here we 
>>> assume the server is a single core machine. If it had been quad
>>> core we could push that value to 800 or more depending on RAM
>> 
>>> and other machine specs. The total threads is an aggregate
>>> value. If Apache and JBOSS are on the same server, and that
>>> server has four cores, then you would halve the maxThreads and
>>> MaxClients to 400 each."
>> 
>> Don't base your performance tuning on values you found in an
>> article online.  The author of this article has no idea what kind
>> of hardware you are running, what your application is doing or
>> what your needs are for the application.  By these metrics, I
>> should setup 800 threads on a quad core system, but if my
>> application is only supporting 10 users that's way too many.
>> Examine your needs, set the values you think will work and then
>> load test to see how things perform.  Adjust the settings further
>> based on your load testing results.
>> 
> mohan.radhakrishnan@polarisFT.com wrote:
>> Yes. I understand the need for capacity planning.
>> 
> 
>> It probably involves concurrency, think time analysis etc. I was 
>> wondering if maxThreads and MaxClients are the same value. In a
>> worker mpm MaxClients is the Apache setting and maxThreads is the
>> JBoss setting.
>> 
> 
> In your kind of configuration, MaxClients are maxThreads are
> related, but they are not the same.  They may be the same if every
> request received by Apache httpd is always transmitted to Tomcat.
> But then what would be the point of having httpd in front ?
> 
> 
>> Moreover how does a figure of 200 for a core justified.
>> 
>> So you mean that the figure of 200 is not based on any analysis.
>> 
> 
> Exactly.  Not all requests are equal, and not all applications are 
> equal.  And in processing a request, there is not only CPU time to
> take into account, there is memory, I/O etc.  So who, other than
> you, can tell how many of *your* requests one "core" can handle in
> any amount of time ?  It is ridiculous to provide such a number as
> if it was based on anything serious.

There is one more wrinkle, here, too. Suppose you have more than one
fronting server running httpd and a single back-end server running
Tomcat. If you have each of your front-end servers with 200 threads,
that means its possible to have 400 simultaneous requests being sent
to Tomcat. If Tomcat can't handle that many simultaneous requests,
you'll get timeouts, disconnects, etc.

The most pathological case is when you have N httpd instances and M
Tomcat instances but M-1 Tomcat instances have failed and so
N*MaxClients httpd requests are being sent to a single Tomcat
instance. You just need to make sure you plan for that kind of
situation and understand what will happen in those cases.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSQDcaAAoJEBzwKT+lPKRYOecQAJWY4H3BACTlBc9rApSZFd79
9xOz/2m7WGc45xRXsTED3katdtTu13ZkDxHB3iHK9jUzZ5LKlOE2npw9V7WaqyQF
kQphbBcSIbG5fr5rWN73Hbt5laYOcSXdgSd1k7WyCjzThFre7zDeDy6A9GSXnzYI
MH+C9Ddxy9wvujYdXnOACkXqck1vxJk19QlCGQrsWHYTdmmEEvahNYHjCSliaPVE
Jz+Z/ZemP74fvi3RmFa9Mm350zyamnOvOEQeDTmwd87VxbvrRaRlAmuhnjSf16SA
4p94xF0Z1ppNbVnFoPL2qKQNmVDDXtbp7oTFpFtXa9Gc51KzGltP55y1zZqvTK+7
XmakjOpwRL6n/4xRBkuWKpCqXfzv+XTq8DPeHWfPeX3gWnbbZrbc4Dv+LlY/usyY
to0uwQHsJ0aCzvLXfzMdXImGhCos09OpKE0f3RiAqRGJw+TdHZIFQJYiL92Lu37C
1Q5Nx1H7T4US6v8D9Ayl/6m7htj1wxOtqt00LxBXuNVJP1Y0sG3XzSZ1zW93eiSn
ThfLKxKhmDhWWv4DYXHfZsWi+iueLM/zwthV8hiGtX9dcCvRndUhM2GViIHybP2O
hBcqFQA7KZQu6f1JI2viIycw5kluQJNU/Iaugb/lNBMIuNKCEPv73K56aLnbycZF
Ctvmo+SkUoYwMt2p29yi
=c87Z
-----END PGP SIGNATURE-----

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





This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

Re: MaxClients and maxThreads

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 9/23/13 3:00 AM, André Warnier wrote:
> Do not top-post. It makes it difficult to follow the conversation,
> who answers to what etc.
> 
>> 
>> 
>> From:   Daniel Mikusa <dm...@gopivotal.com> To:     "Tomcat
>> Users List" <us...@tomcat.apache.org> Date:   09/20/2013 07:10
>> PM Subject:        Re: MaxClients and maxThreads
>> 
>> 
>> 
>> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com
>> wrote:
>> 
>>> Is this a hard limit ?
>> 
>> No.
>> 
>>> So if there are 4 cores there can only be 800 concurrent
>>> clients. None of our banks is calculating this like this and
>>> some have Apache and JBoss on the same machine which further
>>> limits the threads.
>>> 
>>> Appreciate any help.
>>> 
>>> Hi, I am following the instructions in 
>>> https://access.redhat.com/site/articles/15786 to tune
>>> MaxClients in httpd.conf and maxThreads in JBoss Tomcat. " The
>>> recommended value of maxThreads is 200 per CPU, so here we 
>>> assume the server is a single core machine. If it had been quad
>>> core we could push that value to 800 or more depending on RAM
>> 
>>> and other machine specs. The total threads is an aggregate
>>> value. If Apache and JBOSS are on the same server, and that
>>> server has four cores, then you would halve the maxThreads and
>>> MaxClients to 400 each."
>> 
>> Don't base your performance tuning on values you found in an
>> article online.  The author of this article has no idea what kind
>> of hardware you are running, what your application is doing or
>> what your needs are for the application.  By these metrics, I
>> should setup 800 threads on a quad core system, but if my
>> application is only supporting 10 users that's way too many.
>> Examine your needs, set the values you think will work and then
>> load test to see how things perform.  Adjust the settings further
>> based on your load testing results.
>> 
> mohan.radhakrishnan@polarisFT.com wrote:
>> Yes. I understand the need for capacity planning.
>> 
> 
>> It probably involves concurrency, think time analysis etc. I was 
>> wondering if maxThreads and MaxClients are the same value. In a
>> worker mpm MaxClients is the Apache setting and maxThreads is the
>> JBoss setting.
>> 
> 
> In your kind of configuration, MaxClients are maxThreads are
> related, but they are not the same.  They may be the same if every
> request received by Apache httpd is always transmitted to Tomcat.
> But then what would be the point of having httpd in front ?
> 
> 
>> Moreover how does a figure of 200 for a core justified.
>> 
>> So you mean that the figure of 200 is not based on any analysis.
>> 
> 
> Exactly.  Not all requests are equal, and not all applications are 
> equal.  And in processing a request, there is not only CPU time to
> take into account, there is memory, I/O etc.  So who, other than
> you, can tell how many of *your* requests one "core" can handle in
> any amount of time ?  It is ridiculous to provide such a number as
> if it was based on anything serious.

There is one more wrinkle, here, too. Suppose you have more than one
fronting server running httpd and a single back-end server running
Tomcat. If you have each of your front-end servers with 200 threads,
that means its possible to have 400 simultaneous requests being sent
to Tomcat. If Tomcat can't handle that many simultaneous requests,
you'll get timeouts, disconnects, etc.

The most pathological case is when you have N httpd instances and M
Tomcat instances but M-1 Tomcat instances have failed and so
N*MaxClients httpd requests are being sent to a single Tomcat
instance. You just need to make sure you plan for that kind of
situation and understand what will happen in those cases.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSQDcaAAoJEBzwKT+lPKRYOecQAJWY4H3BACTlBc9rApSZFd79
9xOz/2m7WGc45xRXsTED3katdtTu13ZkDxHB3iHK9jUzZ5LKlOE2npw9V7WaqyQF
kQphbBcSIbG5fr5rWN73Hbt5laYOcSXdgSd1k7WyCjzThFre7zDeDy6A9GSXnzYI
MH+C9Ddxy9wvujYdXnOACkXqck1vxJk19QlCGQrsWHYTdmmEEvahNYHjCSliaPVE
Jz+Z/ZemP74fvi3RmFa9Mm350zyamnOvOEQeDTmwd87VxbvrRaRlAmuhnjSf16SA
4p94xF0Z1ppNbVnFoPL2qKQNmVDDXtbp7oTFpFtXa9Gc51KzGltP55y1zZqvTK+7
XmakjOpwRL6n/4xRBkuWKpCqXfzv+XTq8DPeHWfPeX3gWnbbZrbc4Dv+LlY/usyY
to0uwQHsJ0aCzvLXfzMdXImGhCos09OpKE0f3RiAqRGJw+TdHZIFQJYiL92Lu37C
1Q5Nx1H7T4US6v8D9Ayl/6m7htj1wxOtqt00LxBXuNVJP1Y0sG3XzSZ1zW93eiSn
ThfLKxKhmDhWWv4DYXHfZsWi+iueLM/zwthV8hiGtX9dcCvRndUhM2GViIHybP2O
hBcqFQA7KZQu6f1JI2viIycw5kluQJNU/Iaugb/lNBMIuNKCEPv73K56aLnbycZF
Ctvmo+SkUoYwMt2p29yi
=c87Z
-----END PGP SIGNATURE-----

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


Re: MaxClients and maxThreads

Posted by André Warnier <aw...@ice-sa.com>.
Do not top-post. It makes it difficult to follow the conversation, who answers to what etc.

> 
> 
> From:   Daniel Mikusa <dm...@gopivotal.com>
> To:     "Tomcat Users List" <us...@tomcat.apache.org>
> Date:   09/20/2013 07:10 PM
> Subject:        Re: MaxClients and maxThreads
> 
> 
> 
> On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:
> 
>> Is this a hard limit ?
> 
> No.
> 
>> So if there are 4 cores there can only be 800 
>> concurrent clients. None of our banks is calculating this like this and 
>> some have Apache and JBoss on the same machine which further limits the 
>> threads.
>>
>> Appreciate any help.
>>
>> Hi,
>>        I am following the instructions in 
>> https://access.redhat.com/site/articles/15786 to tune MaxClients in 
>> httpd.conf and maxThreads in JBoss Tomcat. 
>>
>> " The recommended value of maxThreads is 200 per CPU, so here we assume 
>> the server is a single core machine. If it had
>>  been quad core we could push that value to 800 or more depending on RAM 
> 
>> and other machine specs. The total threads
>>  is an aggregate value. If Apache and JBOSS are on the same server, and 
>> that server has four cores, then you would halve
>>  the maxThreads and MaxClients to 400 each."
> 
> Don't base your performance tuning on values you found in an article 
> online.  The author of this article has no idea what kind of hardware you 
> are running, what your application is doing or what your needs are for the 
> application.  By these metrics, I should setup 800 threads on a quad core 
> system, but if my application is only supporting 10 users that's way too 
> many.  Examine your needs, set the values you think will work and then 
> load test to see how things perform.  Adjust the settings further based on 
> your load testing results.
> 
mohan.radhakrishnan@polarisFT.com wrote:
> Yes. I understand the need for capacity planning.
> 

> It probably involves concurrency, think time analysis etc. I was wondering 
> if maxThreads and MaxClients are the same value. In a worker mpm 
> MaxClients is the Apache setting and maxThreads is the JBoss setting.
>

In your kind of configuration, MaxClients are maxThreads are related, but they are not the 
same.  They may be the same if every request received by Apache httpd is always 
transmitted to Tomcat. But then what would be the point of having httpd in front ?


> Moreover how does a figure of 200 for a core justified.
> 
> So you mean that the figure of 200 is not based on any analysis.
> 

Exactly.  Not all requests are equal, and not all applications are equal.  And in 
processing a request, there is not only CPU time to take into account, there is memory, 
I/O etc.  So who, other than you, can tell how many of *your* requests one "core" can 
handle in any amount of time ?  It is ridiculous to provide such a number as if it was 
based on anything serious.



> Thanks.
> 





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


Re: MaxClients and maxThreads

Posted by mo...@polarisFT.com.
Yes. I understand the need for capacity planning.

It probably involves concurrency, think time analysis etc. I was wondering 
if maxThreads and MaxClients are the same value. In a worker mpm 
MaxClients is the Apache setting and maxThreads is the JBoss setting.

Moreover how does a figure of 200 for a core justified.

So you mean that the figure of 200 is not based on any analysis.

Thanks.



From:   Daniel Mikusa <dm...@gopivotal.com>
To:     "Tomcat Users List" <us...@tomcat.apache.org>
Date:   09/20/2013 07:10 PM
Subject:        Re: MaxClients and maxThreads



On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:

> Is this a hard limit ?

No.

> So if there are 4 cores there can only be 800 
> concurrent clients. None of our banks is calculating this like this and 
> some have Apache and JBoss on the same machine which further limits the 
> threads.
> 
> Appreciate any help.
> 
> Hi,
>        I am following the instructions in 
> https://access.redhat.com/site/articles/15786 to tune MaxClients in 
> httpd.conf and maxThreads in JBoss Tomcat. 
> 
> " The recommended value of maxThreads is 200 per CPU, so here we assume 
> the server is a single core machine. If it had
>  been quad core we could push that value to 800 or more depending on RAM 

> and other machine specs. The total threads
>  is an aggregate value. If Apache and JBOSS are on the same server, and 
> that server has four cores, then you would halve
>  the maxThreads and MaxClients to 400 each."

Don't base your performance tuning on values you found in an article 
online.  The author of this article has no idea what kind of hardware you 
are running, what your application is doing or what your needs are for the 
application.  By these metrics, I should setup 800 threads on a quad core 
system, but if my application is only supporting 10 users that's way too 
many.  Examine your needs, set the values you think will work and then 
load test to see how things perform.  Adjust the settings further based on 
your load testing results.

Dan

> 
> I have this question. Does this mean that maxThreads and MaxClients 
should 
> 
> both be equal to each other  ?
> 
> My configuration is this.
> Machine 1 - JBoss and Apache(2 cores)
> Machine 2 - JBoss(2 cores)
> 
> So even though Machine 2 can use about 400 threads(200 x 2 ) it is 
limited 
> 
> by MaxClients in Machine 1 which should be only 200. Is that correct ? 
It 
> is a bottleneck.
> 
> Thanks,
> Mohan
> 
> 
> This e-Mail may contain proprietary and confidential information and is 
> sent for the intended recipient(s) only.  If by an addressing or 
> transmission error this mail has been misdirected to you, you are 
> requested to delete this mail immediately. You are also hereby notified 
> that any use, any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and/or publication of this e-mail 

> message, contents or its attachment other than by its intended 
recipient/s 
> is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com
> 
> 
> 
> 
> This e-Mail may contain proprietary and confidential information and is 
sent for the intended recipient(s) only.  If by an addressing or 
transmission error this mail has been misdirected to you, you are 
requested to delete this mail immediately. You are also hereby notified 
that any use, any form of reproduction, dissemination, copying, 
disclosure, modification, distribution and/or publication of this e-mail 
message, contents or its attachment other than by its intended recipient/s 
is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com


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





This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com

Re: MaxClients and maxThreads

Posted by Daniel Mikusa <dm...@gopivotal.com>.
On Sep 20, 2013, at 9:27 AM, mohan.radhakrishnan@polarisFT.com wrote:

> Is this a hard limit ?

No.

> So if there are 4 cores there can only be 800 
> concurrent clients. None of our banks is calculating this like this and 
> some have Apache and JBoss on the same machine which further limits the 
> threads.
> 
> Appreciate any help.
> 
> Hi,
>        I am following the instructions in 
> https://access.redhat.com/site/articles/15786 to tune MaxClients in 
> httpd.conf and maxThreads in JBoss Tomcat. 
> 
> " The recommended value of maxThreads is 200 per CPU, so here we assume 
> the server is a single core machine. If it had
>  been quad core we could push that value to 800 or more depending on RAM 
> and other machine specs. The total threads
>  is an aggregate value. If Apache and JBOSS are on the same server, and 
> that server has four cores, then you would halve
>  the maxThreads and MaxClients to 400 each."

Don't base your performance tuning on values you found in an article online.  The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application.  By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many.  Examine your needs, set the values you think will work and then load test to see how things perform.  Adjust the settings further based on your load testing results.

Dan

> 
> I have this question. Does this mean that maxThreads and MaxClients should 
> 
> both be equal to each other  ?
> 
> My configuration is this.
> Machine 1 - JBoss and Apache(2 cores)
> Machine 2 - JBoss(2 cores)
> 
> So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited 
> 
> by MaxClients in Machine 1 which should be only 200. Is that correct ? It 
> is a bottleneck.
> 
> Thanks,
> Mohan
> 
> 
> This e-Mail may contain proprietary and confidential information and is 
> sent for the intended recipient(s) only.  If by an addressing or 
> transmission error this mail has been misdirected to you, you are 
> requested to delete this mail immediately. You are also hereby notified 
> that any use, any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and/or publication of this e-mail 
> message, contents or its attachment other than by its intended recipient/s 
> is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com
> 
> 
> 
> 
> This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
> 
> Visit us at http://www.polarisFT.com


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


Re: MaxClients and maxThreads

Posted by mo...@polarisFT.com.
Is this a hard limit ? So if there are 4 cores there can only be 800 
concurrent clients. None of our banks is calculating this like this and 
some have Apache and JBoss on the same machine which further limits the 
threads.

Appreciate any help.


Thanks,
Mohan



From:   mohan.radhakrishnan@polarisFT.com
To:     users@tomcat.apache.org
Date:   09/19/2013 05:56 PM
Subject:        MaxClients and maxThreads



Hi,
        I am following the instructions in 
https://access.redhat.com/site/articles/15786 to tune MaxClients in 
httpd.conf and maxThreads in JBoss Tomcat. 

" The recommended value of maxThreads is 200 per CPU, so here we assume 
the server is a single core machine. If it had
  been quad core we could push that value to 800 or more depending on RAM 
and other machine specs. The total threads
  is an aggregate value. If Apache and JBOSS are on the same server, and 
that server has four cores, then you would halve
  the maxThreads and MaxClients to 400 each."

I have this question. Does this mean that maxThreads and MaxClients should 

both be equal to each other  ?

My configuration is this.
Machine 1 - JBoss and Apache(2 cores)
Machine 2 - JBoss(2 cores)

So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited 

by MaxClients in Machine 1 which should be only 200. Is that correct ? It 
is a bottleneck.

Thanks,
Mohan


This e-Mail may contain proprietary and confidential information and is 
sent for the intended recipient(s) only.  If by an addressing or 
transmission error this mail has been misdirected to you, you are 
requested to delete this mail immediately. You are also hereby notified 
that any use, any form of reproduction, dissemination, copying, 
disclosure, modification, distribution and/or publication of this e-mail 
message, contents or its attachment other than by its intended recipient/s 
is strictly prohibited.

Visit us at http://www.polarisFT.com




This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only.  If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit us at http://www.polarisFT.com