Re: JVM CPU queueing

On Wed, Oct 22, 2014 at 10:31 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

You also have to remove the sleep from the second test, which would
reduce the elapsed time accordingly.

From my understanding the "sleep" is just to simulate the threads "doing
other stuff" such as waiting for a DB/disk/etc. to respond,

No, if you review the code in the Task class, you'll see that sleep() is
run only once at the entry point of the call() method - just prior to
executing the 20K loop.

What you have said is exactly correct, but it sounds like you've
interpreted it completely wrong. Each and every task has to wait 1
second, and then do the loop.

Individually, each task averages less than 22% CPU utilization (about
1 second spent at 0% and about .28 seconds spent at nearly 100%).

If the wait were inside the loop, then the normal runtime for each
task (taken in isolation) would be about 20,000.28 seconds. Run
serially, 50 such tasks would take about 1,000,014 seconds. Clearly,
that's an impractical (and unrealistic) test.

A Java nut might say, "Look ma, I can take a multi-threaded CPU bound
workload that would normally use 60% of one core for 15 seconds and force
it to use 100% of 8 cores for 11 seconds, and accomplish the same thing."

I didn't see where he did any test which used only 60% of one core for
15 seconds. He did tests which used about 60% of all 8 cores for
16.73, 16.21, and 15.756 seconds. This was to complete all 50 tasks.

Then he said "hey, let's try to use more than 60%" and that's when he
got it down to 10.92 seconds, again to complete all 50 tasks. In this
configuration, each task took longer (about 10.9 seconds from start to
finish), but they *all* ran in parallel, with a combination of
multiprocessing (the tasks were distributed over 8 processors) and
multitasking (each processor was swapping tasks in and out).

Note that this last configuration gets the entire workload of 50 tasks
done quicker, but each task is less efficient (not just
longer-running). The reason is that this last test forced the
greatest degree of multitasking. Multitasking incurs the overhead of
saving the state of a job being swapped out and restoring the state of
a job being swapped in.

John Y.