277 karma · joined September 25, 2008
[ my public key: https://keybase.io/waloeiii; my proof: https://keybase.io/waloeiii/sigs/YA7PZUiF1uBYwXHp5NaXW6-noq_6l5IGSJxVxnCacqY ]
This does kind of beg the question, why use nginx at all? It provides you with a lot of protection against malformed requests and general fuckery. If you need it you can push the middle layer back into nginx as a module which would be screaming fast.
This reminds me of Heroku who do something like this with their 'routing mesh.' client -> nginx -> routing mesh (erlang) -> thin (ruby app server). The erlang process knows which ec2 instance has the ruby process to serve the request and initiates and is basically a smart proxy. You could quite easily query 6 backends simultaneously for each pagelet and pipe the JSON out to the client then throw in the footer as well.
I think this deserves some experimentation.
nginx + erlang + rails (serving JSON).
ESI is really cool for caching inside your infrastructure, but it doesn't help the client as much because they have to download the entire page again even if only the time changed in the top bar. I've always dreamed of a way of cutting up my HTML page to have different pieces 'cached' by the browser. A logical next step from this style (which helps you load a client with a cold cache) is to have the client cache each of these pagelets. On subsequent requests you could return JS (and actually you could check a cookie and recycle the JS too!) look in the client's HTML5 storage or some other crafty mechanism which will reduce strain on FB's infrastructure and make it faster for the user.
EE is simply a patched MRI, so it will be faster on strings (known issues with rbx), but rbx has generation GC and JIT which can only improve.
Right now in my limited testing the performance is a wash, but if your app is memory hungry the improved GC is worth it alone. If your app is CPU heavy the JIT becomes your friend. The only way to be sure its to test it (how about running your test suite on it?), but I suspect rbx is going to get very fast as soon as a few big players shift on to it and the sweet spots for the tuning knobs are discovered.
TRIM is only enabled on the G2 Intel SSDs and newer competing models, the original G1 does not have the instruction.
As a young (26) libertarian/liberal I don't even own a TV, I get my news from nytimes.com, BBC and NPR driving around and links from my social circles. I think if I had a TV I would watch CNN. My father on the other hand has a TV, and its on Fox.
98102 ftw.
It works best in Thin (EventMachine) or Rainbows! (Fibers).
If you are doing I/O you should use NeverBlock (http://www.espace.com.eg/neverblock/) they've even implemented a MySQL driver, the best part is they're 'drop-in' so you don't have to learn a new API, they just hide the async calls from you.
Fibers I think are closer to Erlang style than the event loop, and much more straight forward to program.
Go Rubinius!
edit - 5.1 (recent releases) scales better mostly due to InnoDB 1.0.4 which incorporates a number of patches from Google (Mark Callagan), Percona and more.
Crawl and Fuzz locally:
http://news.ycombinator.com/saved?id=WALoeIII - mine http://news.ycombinator.com/saved?id=bhrgunatha - yours