On 5/4/2013 1:24 PM, Mark Thomas wrote:
On 04/05/2013 16:01, Yogesh wrote:
Well my question is Is it a common design practice from your experiences to
configure one node (maxthreads) for the scenario where all other nodes amongst
which the load was distribued fail ?
You design for whatever level of resilience you need to meet the
availability requirements.
Mark
Which IME means allow for either one or two of the cluster nodes to
fail, depending on how many you have to start with. Never all but one,
unless you only have two to begin with.
On the cluster part, wrt tomcats talking to each other do you mean the session
replication feature or something else ?
Sent from my iPhone
On May 4, 2013, at 9:26 AM, André Warnier <a...@ice-sa.com> wrote:
yogesh hingmire wrote:
On Sat, May 4, 2013 at 7:07 AM, André Warnier <a...@ice-sa.com> wrote:
yogesh hingmire wrote:
While planning / designing to build a web app that must scale to 2000
concurrent users, distributed across 5 Tomcat nodes in a cluster, Apache
at
the front of course and the ability to serve 20 concurrent requests per
seconds during business hours, with a page response time of 5 seconds, how
would we go about the ask ? What Apache / Tomcat / System (CPU/JVM)
parameters should be considered for this design ?
I will provide the ABC, and leave the details for someone else.
You have 20 requests arriving per second, and it takes 5 seconds to
process one request and return the response.
So, over time, it will look like this
Time new requests requests in-process requests terminated
0 20 20 0
+1s 20 40 0
+2s 20 60 0
+3s 20 80 0
+4s 20 100 0
+5s 20 100 20
+6s 20 100 40
+7s 20 100 60
etc...
So, in principle, and assuming nothing else is going on, you need 100
concurrent threads in Tomcat to process these requests.
(I would take a healthy margin of security and double that).
Whether for that you need a cluster of Tomcats is another discussion.
And how much memory you need to allocate to your Tomcat(s) JVM(s) is a
function of what your webapp needs, to process one request.
The numer of concurrent users should be relatively irrelevant, if all you
mean by that is that some of these requests come from the same user, but
they are otherwise independent of one another.
Note that I have a suspicion that what you describe as "requests" above
probably only count the requests to your webapp code, and do not count the
additional requests for stylesheets, images, etc.. which may be embedded in
any page that the user's browser eventually displays.
So unless you plan on serving those directly from the Apache httpd
front-end, you should take them into account too.
Thanks Andre and sorry for not mentioning about the other content that are
actually requested by http get's from the jsp served.,
There is quite a lot of ajax calls and static content and that can be
served out of httpd, but as of now it is not. I know not the best way,
but you can read the on-line documentation, I presume ?
so i
assume i have to increment my thread count correspondingly..
Well yes, because then you do not have 20 requests per second, you have more.
Only you would know how many more, and how long they take to serve, but the
calculation is similar.
While planning to threads on a single node, do i have to take into account
the failure scenario where say all other 4 nodes fail and just this one
node has to serve out the entire web app load. For that, do i have to
provision the thread count as many as 4 times what i arrive for a single
node ?
Your thoughts?
I think that you can figure that one out by yourself, no ?
One more thing, to avoid you looking in the wrong direction : having one Apache httpd front-end
distributing calls to several back-end Tomcats, does not make it so that the Tomcat servers
constitute a "cluster". A "cluster" is a name more usually used when the
Tomcats are talking to eachother. In this case, they would not be. It would just be the
connector, on the Apache httpd side, which distributes the load between the back-end Tomcats, and
detects when one or more is not working anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
