Assaf Arkin's recent blog post, Why Processes Scale Better Than Threads, contrasts the ways in which LAMP developers and Java developers build complex applications:

In the LAMP world, processes are everything. If you want to pull out data from a file, sort it, and e-mail the result, you pipe several programs together. You’re building a solution by assembling processes.

And for more complex tasks you add even more processes. Want to do things on a schedule? Fire them up with cron. Need to improve throughput? Start up a cache process. Monitor uptime? That’s another process for you.

By contrast, Java developers would run just one JVM process, and call into various APIs to accomplish those same tasks:

In Java you don’t scan files with grep, you use a library. You don’t pipe e-mails to sendmail, you use a library. All the features you need are folded into the VM.

Which turned a snappy VM into a huge behemoth that takes a couple of minutes to boot, as it’s setting up libraries, frameworks and containers. You don’t want to startup the JVM more than once.

To accomplish multiple concurrent tasks, Java developers would use threads, not independent processes. Arkin believes that these approaches result in different scalability characteristics of an application:

Multi-threaded developers tend to scale through objects, libraries and frameworks. When you focus on the components around you, you don’t pay much attention to anything outside the sandbox. The level of abstraction is the API.

Multi-process developers scale by assembling programs together, chaining them or running them in parallel. If it’s not in the framework, you look for a program (or combination of) that does what you need. The level of abstraction is the task...

The more independent processes you have, the easier they are to combine into new and interesting uses.

Because processes can easily be distributed across multiple servers, Arkin believes that solutions that center around the multi-process approach scale better horizontally (incorporating more servers), whereas the multithreading solution scales better vertically, and is able to take better advantage of a more powerful server.

Arkin's concluding point is that horizontal scaling—distributing workload across many less powerful servers—can result in more overall scale than distributing load to more threads in a single process on one powerful server. Potentially, the horizontal scaling approach is also more economical.

Do you agree with Arkin's conclusion that the multi-process approach scales better? And, if so, how do you architect Java applications to distribute workload among multiple processes?

To offer another analogy, a folk definition of insanity is 
to do the same thing over and over again and expect the 
results to be different. By this definition, we in fact 
require that programmers of multithreaded systems be insane. 
Were they sane, they could not understand their programs.

ulimit -c 0