ページ

2009年9月28日

Tornadoってシングルスレッドのままなのかな?

前回は、パフォーマンスにちょっと疑問があるって書きました。で、その解決として、Tornadoのプロセスをたくさん立ち上げるのかなー、と夢想しました。でも、プロセスをたくさん立ち上げると、管理が大変です。でも、その辺は自動化すれば何とかなるかもしれません。で、プロセスやスレッドのスイッチングコストは無視するとして、プロセスでやる場合、メモリの使用量はどうなるんでしょう?まあ、数十のプロセスなら問題ないし、現状のアプリも数十個か数百個のスレッドでしかほとんど動いていないので、プロセスモデルで数十か数百のプロセスを作っても、問題なのかもしれません。まあ、プロセスはスレッドを作るよりさらにメモリを食うのですが、そこそこのサーバを使えば心配いらないのかも。

で、結局、Tornadoってロングポーリングに特化したWebアプリケーションサーバにしかならないんじゃないの?というのが今のところの僕の印象。結局、WSGIのアプリケーションを動かすにはC10K問題を解決していないんじゃないかなー。で、ほとんどのアプリがその恩恵にあやかれないので、現状はapache + mod_wsgi(現在のインフラを変える必要はないと言うこと)とかで十分かと。

2 件のコメント:

tag さんのコメント...

python か ruby でできた軽い web フレームワークを探して、tornado (と、このサイト)を知りました。外部プロセスを起動する重たい処理をすることになるので、シングルスレッド云々という記事が大変参考になりました。ありがとうございます。
昨日あたり helloworld を基にテストプログラムを書いてみましたところ、やはりハンドラで重い処理を想定して wait を置くと全体がブロックされる模様。tornado 内部を覗いてちょっと弄ってみましたが、self._auto_finish = False というようにハンドラ自体を非同期にして、処理本体を別スレッドで動かさないと、後続のリクエストが捌けてくれないみたいですね。ブラウザの pipelining の挙動がいろいろ分かって面白かったです。
tornado 流行るかな?小さくて馴染む感がありますね。

liris さんのコメント...

> tornado 流行るかな?

僕はロングポーリングのアプリケーションでないかぎり、使うべきじゃないと思っています。

はやるかどうかだと、多分はやらないかなー。