tornadoの話
話題のtornadoについてちょっと書いておきます。
フレームワークについて
tornadoは一応wsgiをサポートしていますが本気で組むなら独自で持ってるAPIの方がよいでしょう。
独自のAPIの方は必要最低限な処理しかしません。
無駄なアプリケーションコードを少なくすることでパフォーマンスを得ています。
もちろんアプリケーションコード実行間はブロックしていますが、その時間をなるべく少なくしようという
観点で薄いフレームワークになっています。
（ほとんど1ファイルの小さなモジュールになっているはずです）
ここで変にwsgi対応のFWを乗せたりしようもんならパフォーマンスはかなり落ちるのでやらない方がいいでしょう。
wsgiはインターフェイスがぬるいためFW側で結構な量のコード実行することになります。
ハッキリいってpythonはそこまで速くありませんのでチリも積もれば。。。といった感じでかなり遅くなります。
（気になる方はcProfileで統計を取ってみるといいでしょう）
またtornadoはレスポンスのMD5でETagを発行します。
まあレスポンスを作るまでは通常同様呼ばれますが、MD5が一致すれば304でレスポンスには空文字を送り、少しだけ
処理を軽減します。
Non-blocking
他のリソース（DBのデータなど）を参照するときのブロックを回避するためにははHTTP経由でデータを取得します。
DBを直でNon-blockingで引くのは実質ほぼ不可能（ドライバ次第ですが）なので、DBの値を返す別サーバにNon-blockingで問い合わせます。
tornadoにはNon-blockingで処理できるコールバックスタイルなHTTP clientがついています。
HTTP経由で問い合わせるとtornadoとDBの値を返すサーバ間はlong pollingの状態になります。
但し、この間もイベントドリブンになっているため、DBの値が返ってくるまでは他の処理を実行し続けます。
DBの値が返ってくるとイベントがあがってきて元の処理へ返って処理を続行します。
少しでもスループットをあげたいのであれば別途DBの値を返すJSONRPCサーバのようなサーバを立てておくべきでしょう。
（FriendFeedはそのサーバもtornadoで書いてそうなイメージですが）
運用の話
ブロックしたらアウトな設計です。期待しても何もでてきません。
並列処理はフロントにLoad Balancerがいて、振り分けることによって処理する前提になっています。
（CPU数 -1とかでtonrnadoサーバを立て、LBで振り分ける）
静的ファイルも同様フロントでよろしくやれという前提です。
forkしてもいいんじゃね？という話もありますが、log周りがそーいう前提になっていないのでダメです。
