The idea of process-per-interface is an interesting one. My first thought was that this has the "PHP problem" which is to say that if you have a bunch of useful

The idea of process-per-interface is an interesting one. My first thought was that this has the "PHP problem" which is to say that if you have a bunch of useful utility classes and helper code you have to optimize those to minimize loading. In a framework like Django where an app is reused between requests, you can have a lot of useful framework available at your fingertips. My second thought was more interesting than the first, though: Tir shows the value of Mongrel2 (or, at least, Mongrel2's approach). You can use the process-per-interface structure in places that make sense, and use Django-esque structures elsewhere. Of course, Mongrel2 is not the only way to do it and there are sites like Amazon where they take the approach of packing the results of many requests to separate services into a single page, rather than having a single process be responsible for the page. I find that these days the hardware's good enough that most apps that people create never make it to the "scaling problem" anyhow.