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 > > 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 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
