I skimmed over the first few posts in that thread, and I still don't know what your application actually does (or should do).

The best number of threads/processes strongly depends on the nature of your computations. For example if it's mostly CPU bound, it pays off to have exactly one worker thread/process per CPU core. For a web server that's often a very bad choice.

So tell us what kind of problem your application tries to solve. Otherwise we can't give any advice on what's "best" for you.

Hi moritz,

Here is a description of the app:-

Well i have been assigned a task to migrate a regression suite from c++ to perl. The reg suite has a task to fire queries to prod and test and then compare the results.The queries are fired to a few app servers. The no of client which must be replaced in each query is around 10K and the no of queries is around 5K.The result of the query fired can contain 10 K records at times.Firing query generally takes much less time than comparison and this is the primay reason y i want to segregate things this way. Each query must be replaced by all the clients and then fired onto the app servers

Thanks

Perhaps you could use memcached for an efficient IPC mechanism in this case.

Also look at LPW::Parallel, it might ease some of the work.

There's also httperf which seems to implement at least half of what you want to do.

(I can't give you more specific design tips, sorry; not really my area of expertise).