Daniel Mikusa wrote:
On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
