performance

Photo by harry harris

　いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２)

　Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。

　Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。

　PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。
　しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処理ができないので、この処理は別途プラグインを作って実現しています。

高速化の為にはキャッシュを使おう

　Railsで高速化を考えていくと、特にキャッシュが重要になります。たとえばブログエンジンで、RSS Feedを生成するアクションがあったとします。

Continue reading

Photo by Riverman72

　あとで自分メモを書こうと思うけど、先に一言。

　37signalsも使っているといううたい文句に惹かれて試してみた、Railsのパフォーマンス記録ツール/サービスNew Relic RPM(Rails Performance Management)が、すばらしい。

　RPMは開発時用のDeveloperと、実機用のProductionのが二つあり、まだ開発時用のDeveloperモードしか試してはいないんだけど、専用の管理画面で、アクションを実行時のメソッド単位の実行時間、生成されるSQL、SQLの実行時間やインデックスの利用状況などが非常に簡単に把握できます。

　Railsで開発している人なら、下のムービーを見れば、そのすごさが分かるはず。

　RPM developerのデモ動画 | RPM production のデモ動画

　いまこれを使って、PhotoShareのチューニングをしていますが、非常に快適。これは超おすすめです。

　ひととおりチューニングが終わったら、RPM Productionのagentをインストールして実際に稼働しているRailsのデータを元にさらにチューニングを進められるって言うところがまたすごいなぁ。いい連携だ。

　しかしこのソフトもすごいけど、Railsもこういった周辺マーケットが育ってきている事実も見逃せないなぁ。

　同種のサービスでは、FiveRunsもあるし、単なるホスティングではないサービスを提供する会社が増えてきていることは、Railsが本格的にビジネスに結びついているって事なんだろうな。

　Rails運用時で気になるのは、安定性とパフォーマンス。安定性はいろいろ負荷テストをして時間が経たないと分からないので、まずはメモリのパフォーマンスから調べてみます。

　とりあえず、ちょっとしたサンプルをmongrelで動かしてみると、44Mほどメモリを確保しています。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1003     14412  0.0  2.2  44316 23556 ?        Sl   Apr10   0:01 /usr/bin/ruby1.8 /var/lib/gems/1.8/bin/mongrel_rails start

　んで、同じプロセスをmod_rails(passenger)で起動すると、143Mほど確保されます。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     23423  0.0  0.5  21720  9172 ?        Sl   06:24   0:00 Passenger spawn server
root     25426  9.0  1.2  34796 20944 ?        S    17:01   0:00 Passenger FrameworkSpawner: 2.0.2
1000     25427  4.1  1.2  43204 22560 ?        S    17:01   0:00 Passenger ApplicationSpawner: /u/app/test/releases/20080413134312
1000     25429  0.3  1.2  43288 22316 ?        S    17:01   0:00 Rails: /u/app/test/releases/20080413134312

　まだ詳しく追ってないんですが、”Passenger spawn server”は、Apache起動時に同時に起動されるプロセスで、Apache稼働中は常駐しています。これは稼働しているアプリの数に関わらず1個です。

　Railsアプリがインストールされているアドレスにアクセスすると、Railsアプリのプロセスが起動されます。
“FrameworkSpawner”がgemにインストールされたRails本体です。これは同じバージョンのRailsを使っていれば、複数プロセスで共有されます。
　”ApplicationSpawner”と”Rails”が、プログラム本体です。想像ですが、”ApplicationSpawner”は待機中のプロセスで、”Rails”が稼働中のプロセスの様です。負荷が増えた場合は、”ApplicationSpawner”をcloneして起動するんじゃないかと思います。

　そして、一定時間(RailsPoolIdleTimeで指定した値、デフォルトで120秒)、アプリへのアクセスがないと、”ApplicationSpawner”と”Rails”は終了させられます。少し遅れて”FrameworkSpawner”も終了される様です。終了しないかも。

　なので、一つのサーバでさほどアクセスのないアプリを多数上げる場合には、mod_railsが向いているようです。１つのサーバで複数のアプリは上げない、メモリを余計に食いたくないというときは、mongrelの方が良いかもしれません。

　ただ今のマシンはメモリが多いので、この程度は気にしなくても良いかもしれませんが。