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