How to process 1000 request using Thread

[niraj]

I have one problem. What is the optimal approach for handling 1000
request by using thread.there are 2 scenario. 1 create 1000 thread and
execute the program 2. create 10 thread and pool 1000 requests by some
scheduling algorithm.

 

[Eric Sosman]

I have one problem. What is the optimal approach for handling 1000
request by using thread.there are 2 scenario. 1 create 1000 thread and
execute the program 2. create 10 thread and pool 1000 requests by some
scheduling algorithm.

Too many variables, not enough detail. What is the nature
of these "requests," how much processing power does each need,
what kind of throughput and/or latency requirements exist, how
many CPUs are available, how much memory (relative to the amount
needed to process a request) is available, ...?

That said, a thousand threads is certainly far out in the
fringe of unreasonability: they will chew up "a lot" of memory
in thread stacks and other structures, they will spend "a lot"
of time performing context switches, and so on. But you have
not provided enough information for me to recommend using ten
threads, or a hundred, or one. The only thing I can suggest is
that you decouple the thread count from the request count, so
you can adjust the former to suit the resources of the machine
of the moment rather than letting the request count govern your
life.

 

[RedGrittyBrick]

I have one problem. What is the optimal approach for handling 1000
request by using thread.there are 2 scenario. 1 create 1000 thread and
execute the program 2. create 10 thread and pool 1000 requests by some
scheduling algorithm.

My guess is that of those two alternatives the second is likely to be
closer to optimal.

I imagine a more optimal solution would be a design that starts with n
threads (where n is some tunable parameter that can be selected at
program launch time). To further optimise it (if needed) I'd have some
mechanism for dropping threads that are unused for a long period and for
starting new threads when the pool becomes busy.

The above is all superficial guesswork. It shouldn't be too hard to
benchmark all three through.

 

[Oliver Wong]

Too many variables, not enough detail. What is the nature
of these "requests," how much processing power does each need,
what kind of throughput and/or latency requirements exist, how
many CPUs are available, how much memory (relative to the amount
needed to process a request) is available, ...?

That said, a thousand threads is certainly far out in the
fringe of unreasonability: they will chew up "a lot" of memory
in thread stacks and other structures, they will spend "a lot"
of time performing context switches, and so on.

Unless perhaps they're using a 1024 core CPU?
http://www.technologyreview.com/read_article.aspx?id=17076&ch=infotech

- Oliver