In a earlier post I wrote about how to monitor performance, but how do you plan for great throughput from the start? In the modern world of distributed services and multicore computers you can improve performance considerably by careful use of threading. Before jumping in and firing off threads for everything however, consider when they can actually be of most use.
First, if you fire off a larger number of threads than the cores on the client, multiple threads don't really gain you any advantage. Even with multiple threads started, the processor can only have a fixed number of processors "alive" at any given instant. You won't gain much from multiple threads on processes heavily dependent on SQL back ends either: the database engine already multithreads its queries. But other situations could be good candidates for threading.
If you need to repeatedly call external services for example, or are waiting for data back from remote servers, then using multiple threads can be a lifesaver.
Earlier I wrote more about what to stay alert for to keep your processes threadsafe, but regardless, a general guideline is to tightly manage the quantity of threads that you allow to execute simultaneously.
When you encounter an error in a thread's initiator you need to remember to safely bail out all of the threaded children from their initiator, something that I also discussed in this post. Threads can be tremendous performance enhancers if used carefully and artfully.
