しかし、そのままだとmerb 1.0.12ではエラーが出て動きません。
そのときは、下記のコードを適当な所で実行してください。

class Merb::Orms::DataMapper::Associations < Merb::BootLoader
   def self.run
     DataMapper::Model.descendants.each do |model|
       include DataMapper::Resource
       touch_child_keys(model)
     end
   end

   def self.touch_child_keys(model)
     model.relationships.each_value { |relationship| relationship.child_key }
   end
end

引用元

　いま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で使うために、高速なEvent Driven方式のネットワークライブラリ、EventMachineを調べています。

　このEventMachine、ほとんどの場合はサーバを作るときに使われていますが、HTTPクライアントの機能も実装されており、実はクローラの様な物を作るときにも利用することができます。

　今回はこっちを使いたかったのですが、ググってもほとんど情報が出てこなかったので、Seattle.rbで相談したところ、Aaronさん(RubyKaigi 2008でプレゼンしているのをustで見てコンタクトしました)からサンプルが貰えたので、それを元に、同時接続する様にしてみました。

　このコードだけだと役には立ちませんが、情報が少なかったので参考に上げておきます。

require 'rubygems'
require 'eventmachine'

CONCURRENCY = 2
TARGET_URL = 'http://localhost:3000/'

def create_connection
  puts ">>>> create"
  uri = URI.parse(TARGET_URL)
  request = Net::HTTP::Get.new(uri.request_uri)
  client = EventMachine::Protocols::HttpClient.send(:request,
                                                    :host        => uri.host,
                                                    :port        => uri.port,
                                                    :request_obj => request)
  client.callback do |result|
    $queue.delete client
    $queue << create_connection if $queue.size < CONCURRENCY

    puts ">>>> callback"
    p result
  end

  client.errback do
    # TODO
  end
  client
end

$queue = []
EventMachine.run do
  CONCURRENCY.times do
    $queue << create_connection
  end
end

　Railsで高速化するためには、Memcachedによるキャッシュが欠かせないですが、もしmemcachedが落ちてしまうと、サービス全体でエラーが発生してしまうのが、気になるところでした。

　Takiuchiさんと話をしていて、fiveruns-memcache-clientを使うことで、memcachedを再起動さえすれば自動で再接続されることはわかったのですが、やはりmemcachedが落ちている時はエラーになってしまうのが問題でした。

　どうせ、キャッシュはキャッシュなのだから、memcachedが落ちている間はキャッシュを使わない様にするパッチをmemcache-clientに組み込もうと思って作業をしていたら、実はcache_fuにその機能があるのを発見しました。

　config/memcached.ymlで、「raise_errors: false」を指定するだけで、memcachedでエラーが起こった場合には、キャッシュを無視するようになるようです。
　ちょっと気になるのは、memcachedが落ちたのではなく、ネットワークなどの障害で一時的に接続されなかった場合、キャッシュの不整合が起こることです。これは、自動再接続したときにflush_allするなどのパッチを別に作る必要があるかもしれません。

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

　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が本格的にビジネスに結びついているって事なんだろうな。

　アメリカに来て約3か月がたち、やっと生活も落ち着いてきました。

　現在、BigCanvasでは、7月のAppStoreオープンに向けてiPhone向けのアプリを中島さんと作っています。

　本当は、私もCocoaで遊ぶつもりだったのですが、このプロジェクトを始めたのが4月で時間が無いため、アメリカでも引きこもりの様にRailsのコードを書いています。早くもっとCocoaでアプリを書けるようになりたいなぁ。

　ネットへの依存度が高いので、日本に居てもアメリカに居ても生活全般、あまり違いがない気がします。
　ただ、デザイナやPR会社との打ち合わせなどが英語なので、そこが違うかな。

　これが一段落したら、自分でも書きたいiPhoneアプリがあるので、自分でも色々書いてみようと思っています。

　自分のアイディア以外でも色々作ってみたいと思っていますので、ぜひ「こんなiPhoneアプリ欲しい！」とかありましたら、メール: masuiあっとmasuidrive.jp、チャットでは、MSN:masui@hisec.co.jp、skype:masuidrive76まで呼びかけていただけると、うれしく思います。

　Capistranoではdeployしても、前のソースが残っているために、すぐに前のバージョンに戻せますが、データベースはそうはいきません。

　そこで、deploy:migrationsを実行する前に自動でDBのバックアップを取るようなタスクを探してみました。
MySQL専用ですが、これでローカルのbackupsというディレクトリに、migration実行前のダンプがダウンロードされます。

require 'yaml'

desc "Backup the remote production database"
task :backup, :roles => :db, :only => { :primary => true } do
  filename = "#{application}.dump.#{Time.now.to_i}.sql.bz2"
  file = "/tmp/#{filename}"
  on_rollback { delete file }
  db = YAML::load(ERB.new(IO.read(File.join(File.dirname(__FILE__), 'database.yml'))).result)['production']
  run "mysqldump -u #{db['username']} --password=#{db['password']} #{db['database']} | bzip2 -c > #{file}"  do |ch, stream, data|
    puts data
  end
  backup_dir = File.dirname(__FILE__) + "/../backups/"
  `mkdir -p #{backup_dir}` unless File.exists?(backup_dir)
  get file, "#{backup_dir}/#{filename}"
  run "rm #{file}"
end

desc "Backup the database before running migrations"
task :before_migrate do
  backup
end

元ネタ

　Rails側でNet::HTTPなどを使ってS3からデータを取ってくる方法もあるのですが、それだとパフォーマンスが悪すぎです。
　負荷分散することを考えると、これはApacheモジュールか、リバースプロキシ側でやって欲しい作業です。自分で書こうと思ったけど、調べてみたらやっぱり同じようなのがありました。

　リバースプロキシなどの中には、X-REPROXY-URLというヘッダをサポートしているものがあり、これを戻すとリバースプロキシが代わりにこのURLにアクセスしてデータを返してくれます。

　Perlbalが始めにサポートしたらしいですが、lightlyやapacheもパッチが出ているようです。Perlbalはリバースプロキシとしても、性能が高いらしいので、これを評価してみようと思います。

メモリンク

• X-SendFile, X-REPROXY-FILE, X-REPROXY-URLを試してみる – Yet Another Hackadelic
• X-REPROXY-CACHE-CLEAR もあわせて使いたい人向けショート BK

Carbon Emacsをフルスクリーンで使う – Sooeyで、2008年春版のCarbon Emacsが、フルスクリーンに対応したことを知ったので、早速、ダウンロードしてインストール。

(mac-toggle-max-window)を.emacsで指定するだけのはずなんだけど、なぜか下に1,2行隙間が出たので適当にheightを指定。

(mac-toggle-max-window)
(setq default-frame-alist
      (append (list
		    '(height . 63)
)))

いつの間にかemacs-w3mが、標準添付されなくなっていたので、自分でインストールした。

　bobchinさんの日記から「やっぱRESTは厳しいのかな？」。

　RESTでは、リソースに対して一意のURLに、これって結局データストレージとして使えるっていうだけなんだと思います。MVCでいうmodelの部分。
　これは、これでとても大切な部分なのですが、モデルを検索したり、いろいろ機能をRESTで提供するのは、うまくいかないと思います。

　Railsだと、create, show, update, destroyメソッドはいいのですが、index(list)メソッドをXMLで返すようにしても、あまりうまくいかないケースが多いと思います。１画面に出る情報が多岐にわたるので、きれいに表現できないんですよね。

　１つのコントローラでHTMLとXMLを返す上での最大の問題は、メソッド名の変更が出来なくなることだと思います。APIとして外部に公開してしまうと、メソッドの変更も気軽にできません。

　しかし、RESTfulにすることで、URLやコントローラの設計がきれいになる、Javascriptなど密結合な環境に限定されますが、外部からデータ参照できるなど、利点は多々あります。

　RESTの最大の利点は、デザインパターンと同じで、「このシステムはRESTfulになってるから」っていうと、詳しく話さなくても、全体の把握をしやすくなります。

　なので、システムをRESTfulにすることはいいことだと思います。RESTfulにして考えると、１つのコントローラにアクションを詰め込むのを止めようとか気がつきますし。

　ただ、外部へサイトの機能を公開するためには、別途WebAPIを作る必要があり、それぞれは補完関係にあると思います。