PhotoShareをRailsから、EventMachineベースの自作フレームワークに全面書き換えをしているのですが、大体作り終わりベンチマークを取っていると、概ね1msで処理しているのに、時々、数百ms掛かることがありました。

　初めはGCとか疑ったんですが、GC.disable実行しても状況変わらず。絞り込みをしていると、どうもEventMachineで詰まって居るっぽい。

　EC2上で動かしていたので、手元のマシンで試したり、LinuxじゃなくてFreeBSDで試しても同じように詰まる。同じEventMachineを使っているThinを使って、ベンチマーク取ってみても、100回に1回ぐらい、やたらレスポンスが遅い時間があるのを確認できました。

　ApacheBenchやhttperfは、平均値は取れるけど、個別のレスポンスタイムを出力する方法が見つからなかったので、JMeterに初挑戦。HTTPだけじゃなくて、いろいろなプロトコルに対応しているのがいいね。

　色々試してみると、HTTPに限らずTCPソケットサーバを作ると発生するらしく、こんなコードでも、1000回に1,2回、接続した後1000ms近く待たされることがあることが分かりました。

　MLとか探しても、同じような現象の話が出てきていない・・・。探し方が悪いのか、じつは誰もあまりまじめに使ってないのか・・・・。

　ここら辺まで原因がつかめたところで、takiuchi先生にご相談。

　結局カーネルまで追って、変にselectを呼び出して居ることが判明。takiuchi先生さすが！ 自分もカーネルとか追うように色々準備しておかないと駄目だなと反省。

　このコードを元に検索してみると、迷ったりしていることは分かったけど、このパッチを当てると、接続が詰まる状況が改善。

　ここ以外にも、微妙なコードが見られるので、引き続きコードを追ってみよう。

　年末の忙しい時期なのに、手伝ってくれてありがとうございました！＞takiuchi先生

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

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

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

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

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

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

　通常Railsで組むと、Feedを生成するアクションでページキャッシュを行なうようにします。こうする事で、Feedを生成する処理は一度だけ行い、あとはApacheがキャッシュファイルを返すようになり、Rails側の負荷が下がります。

　この時、ブログを更新する処理を行なうと、Sweeperによって先ほどのキャッシュが破棄され、次回Feedのアクションにページにアクセスしたときに、再度Feedが生成されるようになります。

　これでは、更新の度にキャッシュが破棄/生成され、処理待ちが発生してしまうことが考えられます。

　そこで、更新の時にキャッシュを破棄するのではなく、投稿の処理の自体を非同期にして、更新処理を行った後、Feedなど関係するページを事前に生成します。
　そして、Feedは常に事前に生成したファイルを返すようにします。こうすることで、投稿があった直後にFeedへアクセスした場合でも、キャッシュの破棄は行われずに、キャッシュ(というか非同期に生成したページ)を返します。

　この非同期処理をキューで管理するようにすれば、ページの更新が沢山あってもFeedへの反映が遅くなるだけで、Feedそのもののレスポンスは悪化しません。

Webだってアクションごとに優先順位があるよね

　重要なのは、RailsではFeedのアクションも普通のページも同じプロセス群で同じ優先度で処理されることです。

　ほとんどのFeedは人間ではなくロボットからのアクセスです。人間と違ってレスポンスが悪かったり反映が遅くても問題になりません。
　そのため、Feedアクションのレスポンスが悪化しても、それ自体は問題ないのですが、Railsが同時に処理できるのは、Feedや普通のページを含めて一定数です。(mongrelの起動数など)

　その為、Feedのアクションが重いと、処理待ちが増え、普通のページのレスポンスも悪化します。

　コントローラごとに実行するmongrelを振り分けるようなルールをリバースプロキシに書けばある程度回避できますが、どのように振り分けるのか決定するのは困難です。(Feedなら簡単だけどもっと難しいケースもあるよね)

　このように実はアクションごとに優先順位があります。Feedやランキングと言った部分は、反映が遅くてもほとんど問題になりませんが、自分の写真リストや写真そのものはすぐにアクセスできるようにしたいのです。
　現在のRailsはコントローラごとに優先順位を付けるような処理は苦手なので、これを行うには、なんらかの仕組みが必要になると思います。

でも全部を非同期にする訳にはいかないし

　もちろん、処理のうち非同期にできる部分とできない部分があります。特に問題になるのは、エラー処理です。

　ブラウザでは、一度レスポンスを返してしまうと、サーバからブラウザにメッセージを送る方法がありません。
その為、非同期処理の中でエラーがおこった場合、それをどのようにユーザに伝えるかが問題になります。

　ブログの記事を書く処理では、タイトルの有無や、添付している画像のチェックなど、処理が正しく行えるかのチェックは非同期処理にまわす前にチェックします。事前にチェックできないものについては、何らかの方法であとで通知する仕組みが必要です。

　投稿ボタンを押した後、処理中画面を出して、Ajaxを使って数秒おきにサーバへ確認にいくか、別のページに遷移したときに通知する方法で行けるかなと思ってます。

　また事前に生成しにくいページもあります。PhotoShareの「すべての共有写真」では、100人フォローしている場合、100人分の写真リストがマージされてきます。
　逆に、100人にフォローされている人がいる場合には、その人が写真をアップするたびに100人分の「すべての共有写真」を更新する必要があります。
　これでは、写真をアップすることに100人分のXMLを生成する事になります。
しかし、ほとんどのユーザは誰かがアップする度に写真を見るわけではありません。このようなケースの場合は、いままでと同じように同期で処理をした方がよいでしょう。

　このような処理の場合は、通常のキャッシュやDBのチューニングなどが有効だと思います。

Rails捨てちゃおうか

　こんな風に非同期処理を行う為のRails向けのライブラリはいくつかリリースされていて、BackgroundFuやAP4Rなんかがメジャーです。

Photo by robotgirl

　非同期処理をさせるためにRailsとこれらのソフトを使う方法もあるのですが、キャッシュの事前生成などを考えると、Railsのメリットがないので、メッセージキューとviewの事前生成を中心にしたフレームワークっぽいものを自作しようかなと思っています。

　ユーザ登録、管理画面などRailsを残したい部分もあるので、データベースはActiveRecordのままで、ActionPackに相当する部分をRackの上で自作しようかと考えています。

　実際の構造についてはなるべく早く次のエントリで書く予定です。

　まだ漠然とした話なんですが、もし、お知恵がありましたら、コメントをもらえると幸いです。

　PhotoShareは誰でも簡単に使えることに力点を置いているので、ユーザ登録なしで利用できる、というのを特徴にしています。

　しかし、新しいiPhoneを買った場合など、PhotoShareで新しいiPhoneにデータを移行したい場合、通常のサービスであれば、アカウントを入力するのですが、PhotoShareではアカウントがありません。

　そこで、PhotoShareでは、登録したメールアドレスによってデータの移行ができる様になっています。

1. 旧iPhone: メールアドレスを登録する (メールアドレスの登録は、トップメニューの「設定」から行えます。
   )
2. 旧iPhone: PhotoShareを削除する
3. 新iPhone: PhotoShareをインストールする
4. 新iPhone: 旧iPhoneと同じメールアドレスを登録する

　iPod touchからiPhoneに移行する場合は、「旧iPhone」を「iPod touch」に読み替えてください。

　これで旧iPhoneから情報が削除されたので、旧iPhoneにPhotoShareをインストールすると、また新しいアカウントとして使うことができます。

　PhotoShareでは端末IDを元にしているので、修理などで端末が交換された場合にも、アップした写真などが見えなくなってしまうことがあります。その場合にも、メールアドレスを登録することで前の情報が新しいiPhoneにも引き継がれます。

　データの移行には、メールアドレスの登録が必須になりますので、なるべく登録するようにしてもらえると助かります。

　旧iPhoneでは、データ移行後、アプリを一度削除すれば、すべての情報は削除されますので、譲渡などを行ってもPhotoShareの情報が渡ることはありません。

　　中島さんと立ち上げた、Big Canvasのファーストプロダクト、Big Canvas PhotoShare (www.bcphotoshare.com)をリリースしました。AppStoreでのダウンロードは、こちらから。

　このアプリケーションは、何よりも手軽に写真を使ったコミュニケーションが出来ることを目指したアプリです。

　煩雑なユーザ登録などせずに、写真をサーバへアップロードし、友人や家族と共有できます。誰かを指定して写メするのと違い、自分の日常を流していくTwitterのようなユルいコミュニケーションを目指してます。

　すでに取った写真をアップロードしたい場合には、右下の四角のアイコンを、その場で写真を撮りたい場合はその隣の、カメラのアイコンをクリックします。写真をアップロードするときには、「非公開」「家族と共有」「友人と共有」「全員に公開」を選んでください。

　「友達と共有」とした写真を友達に見せたい場合は、メインメニューを下にずらし、「友人」や「家族」を選択し、「招待する」をクリックします。これで、メールの作成画面に移りますので、そのメールを友達に送りましょう。

　招待された人が、iPhoneを持っていない場合は、Webでも写真を見ることができます。

　iPhoneのアプリの日本語化はされていますが、まだWeb側の方は英語版のみになっています。Webの日本語版は近日中にリリースします。

　また、この週末は過負荷により、サーバとの通信が重い可能性があります。チューニングやサーバ強化は順次行っていきますので、ゆっくり楽しんでください。

Typoだとアンチスパムが弱かったり、コメントを消す動作が結構めんどうだったので、さっくりと乗り換えることに。

なお、過去のコンテンツは、そのまま残してあります。

前のトップページは、ここにありますので、古い情報を探しに来た方はそちらからどうぞ。