As a first pass estimate, consider your chokepoints. Is the program mostly doing disk IO, number crunching, using a lot of memory, network bandwidth, special devices, or just idle?

If disk I/O is the bottleneck, then adding a second thread would be likely to cause the disk to thrash and slow down.

If math is the bottleneck, then the number of cores in your box is likely to be the sweet spot. Something for each core to do, without making it context switch too often.

Memory limitations are pretty easy. If your task takes up a lot of RAM, limit your threads to a number that won't use up all the RAM. Once your threads start having to swap to disk, performance will drop through the floor.

If network traffic is filling up, then choose a number that is enough threads to get a good % utilization without saturating the link. (Also keep in mind that the local bandwidth on your network card is very different from the bandwidth you'll get through your final connection to the internet. Percentages will vary, and be sure to divide by 8 when you see speeds measured in megabits per second)

If you've got a bank of special devices to operate, then you may want one for each device to keep them busy without being wasteful. Depending on the task, one thread may be enough if it can deal with each device occasionally in a loop, such as a bank of printers.

If you are idly waiting for something, then a single other thread is handy to do a blocking wait while your main thread putters around keeping a GUI responsive.