Re: Forking Multiple Threads

[sundialsvc4]

Wince!   500 of anything?!

Kindly consider that “adding more threads” to any soup does not speed things up:   it slows it down by some amount, except to the extent that the hardware (on both ends of a communication link) actually can overlap I/O and computation.   (And if you thereby overload resources, especially such as memory, the whole thing goes to hall in a hendbasket, very quickly.)

I suggest that you add some measurements to your request-queues.   Measure the time that a request actually sits in the queue before being sent to the host; then, measure the time the request takes to be returned.   Now, experiment with what happens as you reduce ... I suggest that you drastically reduce ... the number of processes and/or threads; the so-called “multiprogramming level” of your system.   Now, you can objectively measure the result.   Let me predict what you will find...

I suggest that what you will see is that the actual performance curve follows a “bent knee” pattern that is typical of most such situations that are subject to “thrashing.”   Processing time will rise more-or-less linearly until it hits the wall and the curve goes straight-up into a pattern of exponential(ly bad...) increase.   You are probably already there.

(Notice that I am talking about “request completion time” every bit as much as, if not more so than simply, “how much smoke is coming out of the ventilation vents of your CPUs.”)

I/O requests of this type are typically asynchronous:   you can start a lot of them but you don’t have to dedicate a thread to wait for the completion of each one.   You can use a select() type of mechanism and perhaps use only one thread for the whole shebang.   Networks run in terms of milliseconds; CPUs in terms of nano.

[BrowserUk]

Now, experiment with what happens as you reduce ... I suggest that you drastically reduce ...

How about you back up your useless diatribe by posting code that supports your contention?

Put your money fingers where your mouth is, and demonstrate you have even the vaguest notion of what you're talking about.

Bet you don't!

[sundialsvc4]

Aww, knock it off, willya?   You’re just being a pest.   If you care to, why don’t you argue the opposite case?   Demonstrate for your fellow Monks, who I am sure will be quite interested, how throwing 500 threads at this problem is justifiable and necessary.   Otherwise, good sir, please mind your own business.   Snarking the threads of fellow Monks just because you don’t happen to agree with them does not win you the XP that you seem to crave.   Good day to you.

[BrowserUk]

I knew you wouldn't. Because you obviously don't know how.

Demonstrate for your fellow Monks,

I already did 500+ times.

Meanwhile a search for your threaded code contributions turns up one hit. And there's no code in that either.

how throwing 500 threads at this problem is justifiable and necessary.

Simple math. You have 2000 SaaS servers from which to retrieve data, that takes them 10 seconds to prepare and return.

Using 4 threads: 2000*10/4 = 5000 seconds = 1hr 23 minutes elapsed.

Using 100 threads: 2000*10/100 = 200 seconds = 3.3 minutes elapsed.

Using 500 threads: 2000*10/500 = 40 seconds elapsed.

You need another demo?

[ 0:35:30.57] c:\test>t-head-urls -THREADS=4 urls.list
Processed 2040 urls
Took 424.354000 with 4 threads

c:\test>t-head-urls -THREADS=8 urls.list
Processed 2040 urls
Took 215.305000 with 8 threads

c:\test>t-head-urls -THREADS=16 urls.list
Processed 2040 urls
Took 123.232000 with 16 threads

c:\test>t-head-urls -THREADS=32 urls.list
Processed 2040 urls
Took 90.033000 with 32 threads

c:\test>t-head-urls -THREADS=64 urls.list
Processed 2040 urls
Took 88.804000 with 64 threads

You see where that's headed?

So now it is (way past) your turn. Ante up if you can.