David kerber wrote:
On 9/24/2013 12:11 AM, mohan.radhakrish...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
