3373643 ランダム
 HOME | DIARY | PROFILE 【フォローする】 【ログイン】

傀儡師の館.Python

傀儡師の館.Python

【毎日開催】
15記事にいいね!で1ポイント
10秒滞在
いいね! --/--
おめでとうございます!
ミッションを達成しました。
※「ポイントを獲得する」ボタンを押すと広告が表示されます。
x
X

PR

Recent Posts

Calendar

Keyword Search

▼キーワード検索

Category

Archives

2025.01
2024.12
2024.11
2024.10
2024.09
2024.08
2024.07
2024.06
2024.05
2024.04

Freepage List

Profile

kugutsushi

kugutsushi

Free Space

設定されていません。
2007.07.21
XML
カテゴリ:その他
Scaling Python for High-Load Web Sites を読んでいたら、この中で Load Balancer として nginx があげられている。Perlbal を試してみようかなと思っていたところなのだが、とりあえず nginx について先に調べてみる。pound とも最終的に比べる必要ありか。

Online Security Blog によるとGoogle Web server software distribution across the Internet の 4% が nginxらしい。 Netcraft では 2007年6月時点で 0.19% と少な目。でも Zope の 0.03% より多いし、thttpd や Resin よりも多いといえば十分な数といえるだろう。絶対数では 229186 サイト。Perlbal が 25サイトなのね。で 7月を見ると、なんと 0.29% になっている(367291サイト)。Perlbal は 23サイトに減っている。

それにしても、GFE の数がすごい増え方。すでに IIS の 13.25% にまでなっている。全サーバの 4.35%。Google 強しというのは、こういうところにも現れているな。

eginx は 元々ロシアの人が作ったものなのかな。2007年3月時点のロシアのバーチャルホストのうち 20% が nginx を使っているらしい。ドキュメントもロシア語版がある。ソースは http://sysoev.ru/nginx/ だからロシア人の Igor Sysoev さんが作ったもののようだ。2002年の春から開発を始めて 2004年の秋に最初のリリースが公開されたもよう。ちなみにロシア語は分からない。。。。。でも、英語のドキュメントがあるから大丈夫。

nginx は、基本的な HTTP サーバの機能と proxy サーバの機能を持っているようだ。おもしろいのは、Mail proxy の機能も持っていること。IMAP/POP3/SMTP をバックエンドとすることができる。外側からは認証つきの HTTP で受けたものを内部のメールサーバに渡すことができる。DeleGate みたいな感じか(DeleGate の方が対応しているプロトコルは圧倒的に多いが)。

対応プラットフォームも FreeBSD, Linux, Solaris 9, 10, MacOS X と Windows 以外は主要なものには対応している。

安定版の nginx-0.5.29、開発版の nginx-0.6.4 と2系統ある。

とりあえず "./configure && make && make install" でインストールしてみる。 /usr/local/nginx にインストールされる。 /usr/local/conf/nginx.conf の中の server の port (デフォルト 80 を適当に)、charset (デフォルト koi-8 を utf-8)を変えて試してみる。オプション -t をつけると設定ファイルのチェックができる。

[root@snake conf]# /usr/local/nginx/sbin/nginx -t
2007/07/21 12:19:13 [info] 26358#0: the configuration file
/usr/local/nginx/conf/nginx.conf syntax is ok
2007/07/21 12:19:13 [info] 26358#0: the configuration file
/usr/local/nginx/conf/nginx.conf was tested successfully

syntax is ok と tested successfully で大丈夫なのが確認できたので動かしてみる。

[root@snake conf]# /usr/local/nginx/sbin/nginx
[root@snake conf]# ps aux | egrep '(PID|nginx)'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 26365 0.0 0.0 4460 876 ? Ss 12:22 0:00 nginx:
master process /usr/local/nginx/sbin/nginx
nobody 26366 0.0 0.0 4596 1084 ? S 12:22 0:00 nginx:
worker process
root 26368 0.0 0.0 5464 804 pts/1 S+ 12:22 0:00 egrep
(PID|nginx)

マスタープロセスは root で動き、ワーカープロセスは nobdy で動く。nginx.conf の中で次のように設定すれば、ワーカープロセスのユーザーやワーカー数が設定できるようだ。たとえばユーザを nginx にして、worker_process の数を 4 つにしたければ、次の行を入れるといった具合。

user nginx;
worker_processes 4;

とりあえず、まだデフォルトのままで動かしている。ちなみに nginx.conf は指定しなければデフォルトの nginx/conf/nginx.conf が読み込まれるが、明示的に指定したい場合は、nginx -c ~/test/nginx.conf のように -c オプションを使う。動作中に # kill -HUP 26365 のように SIGHUP を送れば設定ファイルを再読み込みしてくれ、設定ファイルに問題がある場合は、そのまま古い設定で動き続けるようだ。

よくできていると思うのは、nginx のバイナリのアップグレードが必要になったとき。古いバイナリを動かしたまま、USR2 シグナルを送ると 自動的にnginx.pid ファイルを nginx.pid.oldbin にリネームしてくれる。ここで新しいバイナリを動かすと、2つのバイナリのプロセスが動いている状態になる。さらに WINCH シグナルを古い方のプロセスに送れば、古いバイナリで動いているワーカープロセスは既存のリクエストを処理してからきれいに終了してくれる。マスタープロセスは、すべてのワーカースレッドがちゃんと終了してから終了する。ロードバランサーが single point of failure になっているから、サービスを継続しながらアップグレードするためには、こういう心憎い配慮が嬉しいところかもしれない。

nginx を起動後、http://localhost:[nginx_portnumber]/ でブラウザから見てみると、「Welcome to nginx!」が表示された。

次に、nginx.conf の http, server の location として、次のものを追加してみる。

location /test {
proxy_pass http://127.0.0.1;
}


そうすると、http://localhost:81/test/ にブラウザからアクセスすると、port 80 で動いている Apache の /test が表示された。次のようにすれば、URL が .php で終わっているときだけ port 80 にリクエストが渡される。


location ~ \.php$ {
proxy_pass http://127.0.0.1;
}


使いよさそうなので使い込んでみることにしよう。poud や perlbal よりも負荷にも強いようだ。けど、そんなに負荷の高いところで使うわけじゃないからいいんだけど。基本的には複数のサービスを動かしておいて割り振りに使いたいだけだから。まあ、軽くて強いに越したことはない。

ちなみに Apacheを使ったときと nginx を使ったときの速さの違いを、静的HTMLを使って測ってみると下のようになった(ab -n 1000 -c 5)。1リクエストあたりの処理時間は、2.833 ms(Apache) 対 0.373 ms (nginx) で圧倒的に nginx が速かった。まあ nginx の方が機能が少ないだけに当たり前といえば当たり前なのだが。


Apache を使った静的な HTML のテスト

Total transferred: 7499000 bytes
HTML transferred: 7227000 bytes
Requests per second: 352.94 [#/sec] (mean)
Time per request: 14.167 [ms] (mean)
Time per request: 2.833 [ms] (mean, across all concurrent requests)
Transfer rate: 2584.61 [Kbytes/sec] received

nginx を使った静的な HTML のテスト

Total transferred: 7454000 bytes
HTML transferred: 7227000 bytes
Requests per second: 2679.47 [#/sec] (mean)
Time per request: 1.866 [ms] (mean)
Time per request: 0.373 [ms] (mean, across all concurrent requests)
Transfer rate: 19503.87 [Kbytes/sec] received


肝心の LoadBalancer の機能については、こんな感じで設定できる

nginx は CGI の機能は持っていないので、バックエンドのサーバーで処理するか、あるいは FASTCGI を使う。簡単なスクリプトを実行するときの例 のようにしなければプログラムが実行できない。ゆえに、悪さをするときの難易度は高くなる(簡単にのっとられにくい)。

それはある意味設定が面倒だったりするということなのだが Proxying and Load-Balancing with TurboGears とか、ドキュメントページの下の方の Example Configurations and Recipes にあるので、これを見ながらやれば問題ないだろう。設定例のドキュメントは豊富。

Pylons benchmark on various servers を見ると、cherokee との速度比較の例がある。Pylons を使った実験だが nginx をリバースプロキシーとして paster サーバを2つ動かしておくやり方の方が、nginx + FASTCGI よりパフォーマンスがよいので FASTCGI を使うよりリバースプロキシーとして使った方がいいかな。で、それと cherokee で SCGI を使ったときを比べると、同時アクセスが数十であれば nginx reverse proxy の方がいい反応。ただし、cherokee SCGI を使った方が CPU に対する負荷は低いようで、1秒間に 200 程度のアクセスだと cherokee を使った方がレスポンスもよくなるようだ。







お気に入りの記事を「いいね!」で応援しよう

Last updated  2007.07.21 19:56:36
コメント(0) | コメントを書く
[その他] カテゴリの最新記事



© Rakuten Group, Inc.
X