[jrockway]

The thing is, I need those database results -- I can't do anything else until I have them.

You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.

Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory.

If you only have one user using your site at a time, then this isn't a concern. But for everyone else, blocked processes are wasteful.

but require too much fiddling when doing traditional stateless web work

Well, yeah, because you don't have threads. When you do, everything is handled by libraries for you; you can think you're blocking, but actually not block the process.

[wvenable]

> You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.

That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded).

> but your blocked-for-DB-results-process is sitting idle using system resources, like memory.

Either way it will need to use system resources. I can't throw away the resources of the user waiting for results, I need that once the results come in! Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.

> If you only have one user using your site at a time, then this isn't a concern.

If somebody is blocked then someone else's request gets a turn at the CPU. Blocking a single process is completely inconsequential to multi-process web server serving multiple users.

[jrockway]

Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.

They take up several orders of magnitude more memory than lightweight threads. I did some benchmarks a few months ago showing this; check searchyc if you care. Edit: here you are: http://news.ycombinator.com/item?id=794409

Anyway, when you start thinking about "web applications" instead of "web pages", lightweight threads make a lot more sense. And, you'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road. (Performance is the least of your worries.)

Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.

[wvenable]

> They take up several orders of magnitude more memory than lightweight threads.

Premature optimization; when a 1st grader can count to the number of processes you need for large scale web application optimizing it any more is a waste of time and effort.

> You'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road.

Really? I find it refreshingly helpful. Instead of your large application being a large application, it actually just a series of very small applications. If a page crashes, it's pretty much no harm at all. If your whole application crashes, you're screwed. You want to add some functionality, just add it on.

> Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.

"Oooh shiny" is also dangerous thinking. Is it really better to waste your time using up as many threads as possible or actually solving real problems for a few hundred processes?

Sidebar: Why is always you, Jonathan Rockway? Just how many posts do you make on Hacker news in a day? :)