Re: JVM CPU queueing

On Wed, 2014-10-22 at 00:40 -0600, Nathan Andelin wrote:

That begs the question, what programmer would implement an interface that
would cause a thread which normally executes in .277 seconds, to run in an
environment that extends the elapsed time to 11 seconds?

Image 11 of the Profiler shows the threads alternating between "run" states
and "wait" states over a long elapsed period before the threads complete.
That's what I meant by "throttling".

If you remove the "sleep" and just let the 50 threads run serially, they
would only use 1 core and complete in approximately 15 seconds. Contrast
that with burning 8 cores over an elapsed time of 11 seconds. Who would do
that?

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,

I think the article is showing, unless I'm missing something, that while
the length of run for the 50 threads is, at a single item level, longer
the time elapsed for the total 50 threads is shorter than if each were
run one after the other.

If the speed of completion for a single thread was the most important
aspect (as other stuff was waiting for its completion so its results
could be used, ie other seperate tasks, DB writes, etc.) then single
threading would be most applicable. If however the most important factor
was the time of work for all 50 items to complete then multi threaded
would be the way to go.

If you were serving up web pages (as a very rough example) for 50 users
and used the multi threaded system then the wait "per user" would be 11
seconds. If you used a single thread the wait for the first person would
be 1.277 seconds, 2.554 for the second and so on... If however you
initiated 50 unique programs serving up 1 page per program, forgetting
about the initial start up/destruction time, then each person could be
served in 1.277 seconds.

Nathan.