Strategy for great number of threads to be scheduled

Discussions

Performance and scalability: Strategy for great number of threads to be scheduled

  1. hi , buddy, i need ur guys expertise. Lets say, we have a website, which provides each registered user one thread. with this thread, it runs every 5 seconds(do something , like 1+1)(the task can definitely be done within 5 seconds). If I really design the architecture of generating one thread for each user... i think it will suffer, and actually the os can not support so many concurrent threads ,say over 1000000 . So...could u give me some advice on it. or some good arrangement strategy on how to schedule each user to run the task once in 5 seconds. any reply is appreciated! thx
  2. Consider using a thread pool (refer java.util.concurrent package). I recommend using cached thread pool because threads can be lazily initialized. The only disadvantage with thread pool (as opposed to starting a new thread everytime) is that, once all the threads in the pool are created, they will be running all the time (waiting for a task to be submitted when idle). Each thread is a system resource and so the disadvantage. If you create a thread on need basis, the system resource will be freed after the job is done.
  3. thank u guys,first. the requirement is each user's task should be done every 5s as precisely as possible. we can use thread pool to control the amount number of threads..but who can take care of each user's timer? should there be a thread per each user(or one thread for all users) to fetch the available thread from the pool? let me think it over: 1)one thread for detecting all users, when timeis up, go to the pool get the thread to do the task? 2)one thread per user for detecting, this is bad design...! 3)one detecting thread for certain number of users any other suggestions?
  4. the requirement is each user's task should be done every 5s as precisely as possible.
    Then use a thread pool with at least as many threads as there are CPUs/cores. If the processing involves I/O, increase the number of threads until you bottleneck on the I/O or until the CPU utilization goes to 100%. You will not be able to spin up one thread for each user. That architecture cannot work, because you cannot have an infinite number of threads. Furthermore, after a certain number of threads, your throughput will _decrease_ because of the cost of thread scheduling and management.
    we can use thread pool to control the amount number of threads..but who can take care of each user's timer?
    Your question is answered by the documentation for the concurrent package. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  5. Bad design. Why not use a thread pool to constantly process "expired" (last process time >= 5s ago) user data? Partition the chunks of users across threads, and then across machines, until you reach your performance requirements.
  6. Multiplexing[ Go to top ]

    Hi, Over 1000000 concurrent threads? You should definitely consider a multiplexing approach. Googling on "java threads multiplexing servlet" lead me to the following article; http://www-128.ibm.com/developerworks/library/j-nioserver/ The article and referenced resources will tell you what multiplexing is, how you can do it in Java, and how to combine it with Servlets. Good luck, Ivor
  7. Interesting design problem. What did you ultimately choose? How did it scale?