Layering 10 levels of java crap on top of each other is a standard way of approaching business applications too, that doesn’t mean its a good idea. Again, in this example seperating file download part out of your app just moves the problem. You still have to impliment the file download, and you are either going to do it nicely using an event driven or userland thread/task approach, or you are going to do it poorly using a process per request approach (or a little less poorly using a thread per process approach). Admitting that there is no way to do this with PHP/rails doesn’t exactly support the claim that a process per request model is ideal.

“I grant that you could have one process doing all that stuff, and that’s a nifty technological feat — I just don’t see a lot of practical gain out of it.”

Scaling and performance are the practical gains. A well architected app server will scale and perform signficantly better than a process per request server will in some cases, and it will perform slightly better in other cases. There’s no trade off where its worse for anything, so why not do it this way? Compare ocsigen to apache+php, there’s a whole slew cases where php just can’t do things effeciently because of its process per request model, where ocsigen will handle it just fine.

“Sure, Rails scales using process-per-request…but the only problem with that is that the process is being too many things at once (user communication tool, database communication tool, file system communication tool).”

The other problems are it makes caching far more complex and slower, it is terrible for handling large numbers of simultaneous connections, it makes persistant connections for long lived multi-request processing so complex that its simply not done, it makes you either waste tons of db connections, start and tear down db connections on every request, or add yet another layer to handle db connection pooling for you because rails can’t since its architected wrong, and I’m sure there’s other problems I am not thinking of off the top of my head. Considering the fact that there is no downside to using an effecient architecture, why would you want to use a poor one like process per request?

“I’ve got nothing against cool tricks per se — I’ve done more of them in my time than I probably should have — I just don’t see this one as a revolutionary new capability.”

Its not supposed to be a revolutionary new capability, or a cool trick. Its just demonstrating one way to create a nicer abstraction that gives you the architectural benefits of event driven servers, while being simpler and easier to understand/debug/code than using an event driven style directly.

This is why DHH’s hand-waving dismissal of rails poor scalability is so pathetic. He pretends that “its just like every other shared nothing architecture so it scales perfectly”, while completely ignoring the practical implications of using such a bad architecture in reality.

Brian: Does jocaml actually use heavyweight threads/processes that would force a context switch? Having not looked at the code, I would have hoped it was implimented using a single threaded userland scheduler like erlang does, allowing for tens of thousands of “processes” (tasks) with very low context switch costs. How useful jocaml will be depends a lot on the implimentation details.

Also guys, you’ve got a PHP warning on the bottom of the page.

Kirit: That’s the big advantage Deferreds have over Futures- you can’t express circular dependencies. Which is good, because circular dependencies are always deadlocks. If monad B depends upon monad A, monad A can’t depend upon monad B. Also note that we’re doing functional programming’s approach of having lots of immutable objects- the deferred monad for reading line n and the deferred monad for reading line n+1 are different objects. So you can express that some computation requires line n to be read, but must be completed before line n+1 is read.

Chris Khoo, Brit Butler: I’m learning Haskell at the moment. Primarily because the lack of static typing is annoying. Both have interesting things to say about asynchronous programming. Also, I’d recommend this post of mine for more indepth discussion of functional programming and parallelism.

Chia: You’re right- it’s a good sign when a web server takes a full minute to process your query because then you know the web server is making full utilization of it’s I/O capabilities. More seriously: simply because that is what people people are optimizing for doesn’t mean it’s what they should be optimizing for. They may just be making lemonaid from the lemons they’ve built. Note that the monad implementation has the same performance as the naive implementation in the loaded case (the monad implementation will simply devolve into doing everything synchronously). The big advantage the monad implementation will have is that it will be signifigantly more responsive in the common case where the server is unloaded, and I/O can be done in parallel.

As for Jocaml, I’m not sure the two are completely contiguous. Most of the computations being deferred are really, really small (a few dozen, maybe a few hundred, clock cycles). Forcing a task switch costing thousands to tens of thousands of clock cycles to perform a few hundred clock cycles is just silly.

code17: a more accurate comparison would be with old-style big event loops. The heart of the deferred monad is a big ol’ select call.

Check into the advantages of service-oriented architectures for information on why you would want to break them apart. It is a standard way of approaching business applications, particularly those on the net, and the advantages are primarily advantages of scale, resiliency, and maintainability.

I grant that you could have one process doing all that stuff, and that’s a nifty technological feat — I just don’t see a lot of practical gain out of it. Sure, Rails scales using process-per-request…but the only problem with that is that the process is being too many things at once (user communication tool, database communication tool, file system communication tool). I’d rather fix the underlying problem (have the request handler do one thing and do it well) than gloss over it with a cool trick.

I’ve got nothing against cool tricks per se — I’ve done more of them in my time than I probably should have — I just don’t see this one as a revolutionary new capability.

And there is nothing fancy or complicated about this architecture, its perfectly normal. In C/C++ land its done using callbacks in an event driven style (notice how all the high performance webservers are like this?), but for the sake of making it easier for programmers, using a lightweight thread/task abstraction is nicer (although equivilent).

As for why not jocaml, there is no real reason why not. Its the same idea, just using an existing implimentation vs writing your own. In practical “I am writing this as we speak” terms, jocaml may or may not perform adequately, or offer the flexibility needed, I haven’t looked into it much yet. But in the big picture “can’t jocaml do this now or at some point in the future?”, yes it can/will.

My point was that 1) I’m not sure if I buy the complexity/benefit trade-off of using futures to have one single-threaded process going to town on all these things, and 2) if you are already heading this direction, why not just just go to JoCaml?

You didn’t approach #2, so let’s focus on #1, and specifically, let’s consider your case. To handle that situation in the process-per-request Rails implementation, you could provide a service sitting on that file which the actual request handling would call out to (see REST). That way, you don’t have to even think about (or fork) the big file munging code while you’re working on the user management code. And if your user management or file service goes down, it doesn’t take the other with it. Plus you get enhanced and more targetable scalability, generally cleaner code, a versioning balwark, etc., etc. — all the normal service-oriented architecture goodness.

Even if I had a fancy single-process-multiple-request structure, I would probably structure things that way. So your example doesn’t have any architecture consequence.

A single process application server using userland threading and non-blocking I/O is much faster and more effecient than a process per request model, and it allows for much easier caching and sharing data. This allows you to write your app in a better performing way instead of being forced into using a bad implimentation by the architecture limitations.

Lets say I want to have in my ruby on rails or PHP app a page that opens an 8MB file and sends its contents to clients while doing a search and replace on its contents (the replaced value varies per user). There is no good way to do this using a process per request model like rails or PHP, you have to do it a bad way just because of the limitations imposed by the multi process architecture. In a good app server you can read in the file on startup, search for the value and split the file contents on that in advance, and then when serving each request it can share that data and just plug in the per-user replacement data along the way.

And if you’re digging at this spot, I’m not sure why you don’t just go to JoCaml, particularly considering its recent resurrection and the increased interest.

(BTW, Java technically has a Future, with some implementations, but I’ve never seen a particularly good use of them. Does anyone have an example with code?)

Out of curiosity, what do you think of Haskell & Erlang? They both seem similar from my newbie perspective other than the fact that one is static/dynamic typing, and I know Haskell has a thing called type classes which is apparently a pretty good thing.

Chris