Why Processes Scale Better Than Threads
If you’re solving problems, not building software for its own sake, then the right level of abstraction is the task. Start working with processes and you’ll discover that you can do a lot more than with one process, no matter how big it is on the inside.
The more independent processes you have, the easier they are to combine into new and interesting uses. In fact, you might be seeing an analogy here with Mashups and SOA, and you’re right.
There are different ways to measure performance. In my experience multi-threaded has higher throughput on a single machine, but there’s so much one machine can do. Eventually, you’ll have to think outside that box.
But the real measure of performance is how fast you can go from idea to working solution. Hardware is cheaper than the people who work with it. Developers who think processes have an easier time building to scale, and an easier time assembling solutions out of existing pieces of code.
It won’t show up in your profiler, but you will get better design and longer lasting code.
If you were to do multi-threaded design similar to how you do multi-process design, you’d have a good chance of reaping the gains of both worlds.
I’d sum it up by saying that focusing on throughput, instead of latency, is key.