Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm currently using Visual Studio Test Suite load tester to simulate a load against on of our web apps on a different server. (No, I'm not testing against production). I believe it is creating a thread per simulated user.

While I was doing this, I experienced a blue screen which may have been unrelated.

But that brought up the question.

How many threads can I use before my CPU can't handle GENERATING that many requests?

Specs:

Intel Core 2 Duo CPU T7700 @ 2.40 GHz 2.40 GHz (32 bit)

Is there any other information or context I need to provide?

share|improve this question

3 Answers 3

Some limiting factors to consider:

  1. Time spent context switching between threads can outweigh benefit of having multiple threads. Generally, unless your threads spend a lot of time waiting, the benefit of more threads per core is a degredation, not improvement, in performance - see next point:
  2. Is there any point in having more than one thread? Unless each thread spends a lot of time waiting for something to happen - if you have one core - then you can only do one thing at once. Throwing more threads at it is not going to help. For 2 cores 2 threads...
  3. Running out of stack memory is a possibility - as the os can no longer keep track of all your threads.
share|improve this answer
    
Well, because it is hitting an external web server, and then just waiting for a response, yeah, the thread is basically doing nothing for 95% of it's duration –  user8122 Jul 6 '09 at 17:48
    
How many threads did you create before the blue screen? At a guess you either ran out of memory, or the cpu was thrashing / context switching. –  Joel Jul 6 '09 at 19:03

It depends on the version of .NET you're running. You can 250 worker thread for processor on .NET 3.5.

Check out this MSDN article.

share|improve this answer

You can monitor these performance counters while you're running this test. It'll give you an idea of what your practical limits are as you increase the concurrency:

  • System \ "Processor Queue Length".

Processor Queue Length is the number of threads in the processor queue. Unlike the disk counters, this counter counters, this counter shows ready threads only, not threads that are running. There is a single queue for processor time even on computers with multiple processors. Therefore, if a computer has multiple processors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than 10 threads per processor is normally acceptable, dependent of the workload.

This is similar to the Unix load average, in that it indicates threads waiting to execute. This is not the same as CPU utilization %, which only tells you how much time is spent working vs. idling.

  • System \ "Context Switches/sec".

Context Switches/sec is the combined rate at which all processors on the computer are switched from one thread to another. Context switches occur when a running thread voluntarily relinquishes the processor, is preempted by a higher priority ready thread, or switches between user-mode and privileged (kernel) mode to use an Executive or subsystem service. It is the sum of Thread\Context Switches/sec for all threads running on all processors in the computer and is measured in numbers of switches. There are context switch counters on the System and Thread objects. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.

This number is relative to each system. But, with some benchmarking you can use this counter to correlate to the upper limits of your processing capacity.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.