パフォーマンス¶
Webアプリケーションのパフォーマンスというのは、フロントエンドの性能ではなく、アーキテクチャでほとんど決まってしまいます。これは、Tornadoは他のPythonのウェブフレームワークと比べて、極めて高速であるということを意味します。
私たちは、 “Hello, World”アプリケーションを、Pythonでもっとも人気のあるウェブフレームワーク(Django, web.py, CherryPy)でそれぞれ実装し、いくつかの試験的な負荷テストを実行し、Tornadoとの相対的なパフォーマンスの基準値を測定しました。Djangoとweb.pyにはApache/mod_wsgiを利用し、CherryPyはスタンドアロンサーバとして実行しました。それぞれのフレームワークごとに、私たちが良く本番環境として使用されると予想される環境を設定してあります。Tornadoは、nginxリバースプロキシを立てて、その後ろに4つのシングルスレッドのTornadoフロントエンドを走らせました。私たちが推奨する構成としては、1つのコアごとに1つのフロントエンドを走らせて、前にnginxを立てる環境になります。今回の負荷テストでは4コアのマシンを利用しているため、4つとしました。
Apacheベンチマーク(ab)を使用して、コマンドごとにそれぞれ別のマシンを使って負荷テストを行いました。
ab -n 100000 -c 25 http://10.0.1.x/
4コアの2.4GHzのOpteronプロセッサを搭載したマシンを使用して、1秒あたりのリクエスト数を計測した結果が以下のグラフになります:
私たちのテストでは、次に高速なフレームワークと比較しても、Tornadoはコンスタントに4倍のスループットを出しています。1コアだけ使用した場合でも33%高速なスループットをたたき出しています。
このテストはそれほど科学的ではなく、大ざっぱな視点での話しになりますが、私たちがTornadoを開発するにあたって、パフォーマンスに留意して開発している、という感覚は伝わるはずです。そして、他のほとんどのPython製のウェブ開発のフレームワークと比べて、遅延が大きくなることはないという気になるでしょう。
本番環境でTornadoを実行する¶
FriendFeedでは、nginxをロードバランサーおよび静的ファイルのサーバとして使用しています。 FriendFeedでは複数のフロントエンドマシン上で、いくつかのTornadoウェブサーバのインスタンスを起動しています。私たちが通常Tornadoフロントエンドを実行するのは、マシンのコア数と同数にしています。
以下のファイルは、FriendFeedで使用されているのと、同じ構造を持つnginxの設定ファイルのひな形です。以下の設定ファイルは、nginxとTornadoサーバが同じマシン上にあり、4つのTornadoサーバが8000〜8003の4つのポートで動作することを想定しています。
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
# すべてのTornadoサーバはここに列挙します
upstream frontends {
server 127.0.0.1:8000;
server 127.0.0.1:8001;
server 127.0.0.1:8002;
server 127.0.0.1:8003;
}
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
keepalive_timeout 65;
proxy_read_timeout 200;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
gzip_min_length 1000;
gzip_proxied any;
gzip_types text/plain text/html text/css text/xml
application/x-javascript application/xml
application/atom+xml text/javascript;
# コミュニケーションエラーがあったときだけリトライします。
# Tornadoサーバのタイムアウトではリトライしません。
# すべてのフロントエンドの"queries of death"が広がるのを避けるための措置です。
proxy_next_upstream error;
server {
listen 80;
# ファイルのアップロードを許可します
client_max_body_size 50M;
location ^~ /static/ {
root /var/www;
if ($query_string) {
expires max;
}
}
location = /favicon.ico {
rewrite (.*) /static/favicon.ico;
}
location = /robots.txt {
rewrite (.*) /static/robots.txt;
}
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect false;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_pass http://frontends;
}
}
}
WSGIとGoogle AppEngine¶
Tornadoは、限定的にWSGIをサポートしています。 しかし、WSGIではノンブロッキングのリクエストをサポートしていないため、TornadoのHTTPサーバではなくWSGIを使用することを選択してしまうと、Tornadoの非同期、ノンブロッキングの機能をアプリケーションで利用することはできなくなります。@tornado.web.asynchronous(),httpclientモジュール,authモジュールといったいくつかの機能は、WSGIアプリケーションでは利用できません。
通常Tornadoアプリケーションを作成するときにリクエストハンドラとして使用する、tornado.web.Applicationの代わりに、wsgiモジュールのWSGIApplicationを使用すると有効なWSGIアプリケーションを作成することができます。以下のコードはPython組み込みのWSGIのCGIHandlerを使用するサンプルです。以下のコードはGoogle AppEngineのアプリケーションとして使用することができます:
import tornado.web
import tornado.wsgi
import wsgiref.handlers
class MainHandler(tornado.web.RequestHandler):
def get(self):
self.write("Hello, world")
if __name__ == "__main__":
application = tornado.wsgi.WSGIApplication([
(r"/", MainHandler),
])
wsgiref.handlers.CGIHandler().run(application)
完全な機能を備えたAppEngineのTornadoアプリケーションについては、appengineのサンプルを参照してください。
警告とサポート¶
Tornadoは, FriendFeedのコードをベースに、依存関係を減らすようにリファクタリングされたものです。このリファクタリングによってバグが混入された可能性があります。同様にFriendFeedのサーバはかならずnginxを立てて運用していたため、TornadoはFirefoxのHTTP/1.1クライアントでテストした以外は、十分にテストされていません。Tornadoは現在は複数行にわたるヘッダや、異常な入力扱うのを好みません。
Tornadoについての議論や、バグの報告はTornadoの開発者メーリングリスト上でお願いします。