> I have that exact setup here, what are you asking?

Use top to determine the difference between the HTTPD and the webapp. Nginx is probably hovering somewhere around 0%. I don't understand why many Ruby webapp developers care so much about their reverse-proxy [Apache/Lighttpd/Nginx/whatever it is now] when it won't make a difference?

> Pick any site from Alexa's top 100 and see that the vast majority of those pages aren't customized.

I can't argue with that. At that scale everything changes -- they usually have their own custom frameworks (probably Jaaaavaaaa J2EE enterprisey), the most heavily hit pages are static, they use a CDN, and so on. Ignoring bandwidth, one reason they have to do that is because execution time matters, although it's probably their databases they're worried about.

> So what happens when we're serving 1000 Req/s and we cache 1/2 of a page in memory

A good idea, as is using memcache and the whole spiel. Your execution time will still mean something though -- the load on app servers comes from somewhere. Also, with a slower language some problems become less feasible. I saw a presentation where a person was using divide-and-conquer in a Google Maps mashup, and had to rewrite that part in C. Wouldn't it be nice if that wasn't necessary?

Actually, my biggest beef with MRI (and presumably YARV) isn't that it's slow -- the real bottlenecks in webapps lie elsewhere, particularly the problem of scaling the database. No, I take issue with the GC marking object directly, thus preventing the OS from using copy-on-write to any real effect. So you're stuck with ten or so mongrels per box because few pages are shared across processes.