Rails3.2のプロジェクトを作成し、適当なモデルを作ってconsoleでSQLの実行時間を見る。
サンプルコードはgithubに置いた。
モデルはUser -< Item -< Extraで、Userは100、Itemは10ずつで1000、Extraは10ずつで合計10000のレコードを作成することにする。
seed_fuのフィクスチャを使い、rake db:seed_fuで一気にレコードが作成されるようにした。

この状態（commit:830f6dae26189d4ea83b8753471a166712d50568）で全てのエントリを取得させてみた。

User全件(100件)

> User.all.count
# SELECT `users`.* FROM `users`
=> 1.0ms

Item全件(100*10件)
1.JOINした場合

> User.joins(:items).all.count
# SELECT `users`.* FROM `users` INNER JOIN `items` ON `items`.`user_id` = `users`.`id`
=> 3.2ms

2.JOINせず複数回SQLした場合

> Item.where(:user_id => User.where(:id => {:not => nil}).pluck(:id)).all.count
# SELECT id FROM `users` WHERE (`users`.`id` IS NOT NULL)
# SELECT `items`.* FROM `items` WHERE `items`.`user_id` IN (1..100)
=> 0.6ms + 4.5ms = 5.1ms

Extra全件(100*10*10件)
1.JOINした場合

> User.joins(:items => :extras).all.count
# SELECT `users`.* FROM `users` INNER JOIN `items` ON `items`.`user_id` = `users`.`id` INNER JOIN `extras` ON `extras`.`item_id` = `items`.`id`
=> 35.4ms

2.JOINせず複数回SQLした場合

> Extra.where(:item_id => (Item.where(:user_id => User.where(:id => {:not => nil}).pluck(:id)).pluck(:id))).all.count
# SELECT id FROM `users` WHERE (`users`.`id` IS NOT NULL)
# SELECT id FROM `items` WHERE `items`.`user_id` IN (1..100)
# SELECT `extras`.* FROM `extras` WHERE `extras`.`item_id` IN (1..1000)
=> 0.6ms + 1.8ms + 30.9ms = 33.3ms

このケースだとあまり差が出ないので、Extraの件数を10倍にしてみた。（commit:96ee43e9319a363666033ac725950283bb80fab8）

Extra全件(100*10*100件)
1.JOINした場合

> User.joins(:items => :extras).all.count
# SELECT `users`.* FROM `users` INNER JOIN `items` ON `items`.`user_id` = `users`.`id` INNER JOIN `extras` ON `extras`.`item_id` = `items`.`id`
=> 358.9ms

2.JOINせず複数回SQLした場合

> Extra.where(:item_id => (Item.where(:user_id => User.where(:id => {:not => nil}).pluck(:id)).pluck(:id))).all.count
# SELECT id FROM `users` WHERE (`users`.`id` IS NOT NULL)
# SELECT id FROM `items` WHERE `items`.`user_id` IN (1..100)
# SELECT `extras`.* FROM `extras` WHERE `extras`.`item_id` IN (1..1000)
=> 0.7ms + 1.9ms + 303.0ms = 305.6ms

件数が増えるほど差が広がっている。件数が多い時はJOINしない方が良さそうではある。
まぁ、300msもかかるようだと他の高速化手段を取るべきだろうけど。

ついでにindexを追加してみた。（commit:bac53fb2569b5a681a6bacad3e8c13535e4aa141）

Item全件(100*10件)
1.JOINした場合

> User.joins(:items).all.count
# SELECT `users`.* FROM `users` INNER JOIN `items` ON `items`.`user_id` = `users`.`id`
=> 4.0ms

2.JOINせず複数回SQLした場合

> Item.where(:user_id => User.where(:id => {:not => nil}).pluck(:id)).all.count
# SELECT id FROM `users` WHERE (`users`.`id` IS NOT NULL)
# SELECT `items`.* FROM `items` WHERE `items`.`user_id` IN (1..100)
=> 0.7ms + 4.7ms = 5.4ms

Extra全件(100*10*100件)
1.JOINした場合

> User.joins(:items => :extras).all.count
# SELECT `users`.* FROM `users` INNER JOIN `items` ON `items`.`user_id` = `users`.`id` INNER JOIN `extras` ON `extras`.`item_id` = `items`.`id`
=> 212.1ms

2.JOINせず複数回SQLした場合

> Extra.where(:item_id => (Item.where(:user_id => User.where(:id => {:not => nil}).pluck(:id)).pluck(:id))).all.count
# SELECT id FROM `users` WHERE (`users`.`id` IS NOT NULL)
# SELECT id FROM `items` WHERE `items`.`user_id` IN (1..100)
# SELECT `extras`.* FROM `extras` WHERE `extras`.`item_id` IN (1..1000)
=> 0.6ms + 3.3ms + 556.9ms = 560.8ms

む、逆転した。

以上はローカル環境で適当にやっただけなので、そのうちAWSのインスタンスでも立ててちゃんと調べよう。

追記：分かりやすいようにSQL入れました。

具体的には、rake assets:precompileを実行すると以下のようなエラーで中断する。

rake aborted!
undefined method `[]' for nil:NilClass
  (in /path/to/rails_app/app/assets/stylesheets/application.css)
/path/to/.rvm/gems/ruby-1.9.3-p125/gems/sass-rails-3.2.5/lib/sass/rails/helpers.rb:32:in `resolver'
/path/to/.rvm/gems/ruby-1.9.3-p125/gems/sass-rails-3.2.5/lib/sass/rails/helpers.rb:22:in `image_path'
/path/to/.rvm/gems/ruby-1.9.3-p125/gems/sass-3.1.15/lib/sass/script/funcall.rb:88:in `_perform'
以下略

railsをstableにすると発生しなくなったり3.2.3で復活したり長らく原因不明だったが、githubのこのissueを追っかけてようやく原因が分かった。

cssのurlをassetsに対応させるため、erbを埋め込んで以下のようにしていた。

.bgimage {
background: #fffff url("<%= asset_path 'css/background.png' %>") repeat-x;
}

これはprecompileしない環境（development）だとうまく行くが、assets:precompileを実行すると上記のエラーになる。
どうやらasset_pathヘルパが[:custom]オプションを要求するのに対し、sassエンジンが[:custom]オプションなしで初期化されるのが原因らしい。
erbのasset_pathを諦め、styles.css.scssにリネームした上で、以下のように書き換えて解決。

.bgimage {
background: #fffff url(asset-path('css/background.png', image)) repeat-x;
}

asset_pathがsassではasset-pathになるのが分からなくてハマった。RailsGuideに書いてはあるんだけど例が分かりづらい。
sprocketのドキュメントの方が分かりやすいかも。
なお、asset-pathだとimageオプションが必要だが、文字列を生で書くのが気持ち悪い場合、image-pathにするとオプションが不要になる。

.bgimage {
background: #fffff url(image-path('css/background.png')) repeat-x;
}

胸のつかえが取れたー。

久しぶりにinline patchを当ててみたが、やはりauto-saveとぶつかった時に落ちる。
（auto-save-buffersは使っていないんだけど）
これを回避するパッチがmacemacs-jpで流れていたので当てる。

一応、patch -p0で当てられるパッチを作ったので置いておく。

--- a/src/nsterm.m	2012-03-20 12:48:57.000000000 +0900
+++ b/src/nsterm.m	2012-03-20 13:22:16.000000000 +0900
@@ -4708,9 +4708,7 @@
   if (NS_KEYLOG)
     NSLog (@"firstRectForCharRange request");
     
-  if (NILP (Feval (Fcons (intern ("ns-in-echo-area"), Qnil))))
-    win = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe));
-  else if (WINDOWP (echo_area_window))
+  if (WINDOWP (echo_area_window))
     win = XWINDOW (echo_area_window);
   else
     win = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe));

一通りパッチを揃えたら以下の手順でビルド。

patch -p1 < ../emacs-23-lion-fullscreen-test.patch
patch -p0 < ../inline_patch-svn/emacs-inline.patch
patch -p1 < ../fix-shiftmodifier-patch-for-emacs-inline-patch.diff
patch -p0 < ../fix-auto-save-crash.patch
./configure --with-ns --without-x
make bootstrap
make install

Mac Mini(Core2Duo 2.4GHz/8G/SSD)でビルド所要時間13分くらい。
思ったよりも速くなってないけど、まぁCore2Duoだしこんなもんか。i7のMiniかiMac出たら欲しいな。

具体的には以下の通り。

旧構成:LB→varnish→nginx→unicorn

新構成:nginx→varnish→unicorn

varnishはUNIX socketに対応していないので（予定はあるようだが）、unicornを適当なポートで待ち受けさせてやらなければならない。
静的ファイルはフロントエンドのnginxで直接捌くためvarnishにキャッシュさせることはできなくなるが、nginx単体で充分なパフォーマンスが出るので考えなくていいだろう。

nginxを80で待ち受けさせて、静的ファイル以外をバックエンドのvarnishに投げ、varnishがさらにバックエンドのunicornに投げる。
これで問題なく動作しているかに見えたが、実は大きな罠があった。
varnishはGETリクエストしかキャッシュしないため、POSTについてはそのままバックエンドに丸投げになるはずが、間にnginxが挟まったことで全てのリクエストがGETになってしまう現象が発生した。
恐らくvclの記述がまずいのだと思うが、とりあえずnginxの方でGETリクエストのみをvarnishに投げ、それ以外は直接unicornに投げるように変更して解決した。
以下はその設定。

/etc/nginx/sites-available/default

upstream varnish {
        server localhost:8080;
}

upstream unicorn-rails {
        server localhost:3000;
}

server {
        listen 80;
        server_name rails-app-sample.larus.jp;
        root /var/www/rails-app/current/public;
        error_log /var/www/rails-app/current/log/nginx-error.log;

        location ~ ^/assets|system/ {
                expires 1y;
                add_header Cache-Control public;
                add_header Last-Modified "";
                add_header ETag "";
        }

        location = /favicon.ico {
            root   /var/www/rails-app/current/public/assets;
        }

        location / {
                proxy_set_header X-Real-IP  $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;

                if ($request_method = GET) {
                        proxy_pass http ://varnish;
                        # httpの後のスペースは本来は省く
                }

                proxy_pass http ://unicorn-rails;
                # httpの後のスペースは本来は省く
        }

}

/etc/varnish/default.vcl

backend rails_app {
  .host = "127.0.0.1";
  .port = "3000";
  .connect_timeout = 30s;
}

sub vcl_recv {
  if (req.http.host == "rails-app-sample.larus.jp") {
    set req.backend = rails_app;
    return (lookup);
  }
}

なお、以後スケールする場合はnginxをロードバランサにしてvarnish+unicornの組を増やせば良い。

しかしvarnishの作者はDJBの同類っぽくてやや不安・・・

サーモス「ケータイマグ」

少し太めで持ちにくいが、その分高さは低い。
塗装がはげやすく、すぐボロボロになる。リペイントとか楽しめる人にはいいかも。
蓋のロックはあけやすく、ゆっくり開くのも良い。
飲み口のパーツが掃除しにくく汚れる。

TIGER「サハラマグ」

蓋のロックが固くて開けにくい。勢いよく開く上に、角度が足りず鼻にぶつかる。（サイズや人によるかもしれない）
飲み口は一体化されていて掃除しやすい。
ボディがコーティングされているので塗装がはげない。

象印「ステンレスマグ」

容量が少しだけ少ないが、その分細身で持ちやすい。
底面がわずかに膨らんでいて安定する。
蓋のロックが独特で、開けにくい人もいるかも知れない。勢いよく開くが角度がつけられていて飲みやすい。
飲み口は一体化されていて掃除しやすく、簡易な空気弁がついている。
ボディはコーティングされているようだ。塗装は今のところはげてないが、時間が経ってないのでまだ不明。
なお、たまたまかも知れないけど買ったばかりは妙な匂いがあってなかなか取れなかった。

multistageを使っている時に、config/deploy/staging.rbに以下のように書いたとする。

set :rails_env, 'staging'
set :branch, 'trunk'
set :deploy_to, "/var/www/#{application}-#{rails_env}"
role :web, "staging-server"
role :app, "staging-server"
role :db, "staging-server", :primary => true

が、これは期待した動作をしない。deploy:symlinkの時にオーバーライドしたはずのdeploy_toが復活する。もしdeploy.rbでdeploy_toを指定していなければ、デフォルトの/u/apps/#{application}が使われる。

これを回避するには、staging.rbに以下を追加する必要がある。

set(:deploy_to) { "/var/www/#{application}-#{rails_env}" }
set(:releases_path) { File.join(deploy_to, version_dir) }
set(:shared_path) { File.join(deploy_to, shared_dir) }
set(:current_path) { File.join(deploy_to, current_dir) }
set(:release_path) { File.join(releases_path, release_name) }

# unicornを使っているなら以下も
set(:unicorn_config) { "#{current_path}/config/unicorn.rb" }
set(:unicorn_pid) { "#{current_path}/tmp/pids/unicorn.pid" }

これならdeploy_toが呼び出された時点で評価される。

しかし、全てのrails_envについて（staging.rb,production.rbなど）同じ内容を書かないといけないのでよろしくない。
ぱっと見だと難しそうなので、ゆっくりソースを追って考えてみます。

まず、Rails3.2でDBに接続しに行く問題はapplication.rbにconfig.assets.initialize_on_precompile = falseを追加することで回避できるみたい。RailsGuidesくらいちゃんと読めって話ですよね。このへんは先日の勉強会で教えて貰いました。

あとdeploy.rbでnamespaceを定義して更新時だけprecompileするコードだけど、multistageを使っているとパスがデフォルトになってしまったりでうまく動作しない。（multistageしてない時には正常動作するはず）
こちらはちょっと考え直す必要がありそう。うまく行ったらまた紹介します。

上記、別の問題とごっちゃになってました。そのままのコードで問題なしです。

• デザインの細かな修正ごとにprecompileするので、コミットがassets:precompileだらけになる。
• precompileした状態でdevelopment環境をロードすると、coffeescriptで書いた関数が2回実行されたりおかしなことになる。
• Rails3.2だとprecompile時にデフォルトでproductionデータベースに接続しようとするので、そのままのdatabase.ymlのままローカルで実行するとエラーになる。（これは一応RAILS_ENV=development rake assets:precompileで解決可能）

と言うわけで改善を試みた。
参考にしたのはstackoverflowのこのスレ。

まず、Capfileにload ‘deploy/assets’を追加する。この時、必ずload ‘config/deploy’よりも先にすること。そうしないと後述のnamespaceが有効にならない。
次にdeploy.rbに以下のnamespaceを定義。

  namespace :assets do
    task :precompile, :roles => :web, :except => { :no_release => true } do
      from = source.next_revision(current_revision)
      if capture("cd #{latest_release} && #{source.local.log(from)} vendor/assets/ app/assets/ | wc -l").to_i > 0
        run %Q{cd #{latest_release} && #{rake} RAILS_ENV=#{rails_env} #{asset_env} assets:precompile}
      else
        logger.info "Skipping asset pre-compilation because there were no asset changes"
      end
    end
  end

これでassetsのnamespaceが上書きされ、app/assets以下に変更があった時のみリモートでassets:precompileが行われるようになる。
万事解決良かった良かった。

のはずが、環境によってはprecompileが失敗することがある（この問題？）。ソースを追っかけたけどよく分からなかった。3.2.2で解決したかなぁ。

大体のところは

http://kray.jp/blog/rails3-fileupload/

を参考にさせて頂きました。以下、いくつかハマった所だけ。

Webrickやmongrelなら問題ないが、unicornで走らせようとするとrequest.body.lengthがNoMethodErrorを返すので、request.body.sizeに変更する。
さらにtemp_fileの保存時にEncoding::UndefinedConversionErrorが発生するのでforce_encoding(‘utf-8′)を付ける。
以上を修正した_store_uploadメソッドはこんな感じ。

# forked from http://kray.jp/blog/rails3-fileupload/
  def _store_upload(file)
    if request.xhr?
      if request.body.size == request.headers['CONTENT_LENGTH'].to_i
        file_data = request.body.read 
        file_name = file
      end
    else
      if file.instance_of?(File)
        file_data = file.read
        file_name = file.original_filename
      end
    end
    
    raise "upload failure" unless file_data

    temp_file = Tempfile.new(file_name)
    temp_file << file_data.force_encoding('utf-8')
    @picture = Picture.new
    @picture.image = temp_file
    @picture.image_file_name = file_name
    @picture.user = current_user if current_user
    @picture.tags << current_tag if current_tag
    @picture.stories << current_story if current_story
    @picture.save
    temp_file.close!
    @picture
  end

あと、元記事ではわざと単純にしてあるのだと思うけど、アップロード完了時のコールバックをlocation.reload();にすると複数ファイルをアップロードした時に中断してしまうので、ajaxで何かしら書く。こんな感じにした。

# initializer for fileuploader.js(http://github.com/valums/file-uploader)
@create_uploader = (upload_action, complete_action, token) =>
        uploader = new qq.FileUploader {
                element: document.getElementById('upload'),
                action: upload_action,
                debug: false,
                params: {
                        authenticity_token: token
                },
                onComplete: () =>
                        $.get complete_action, (data) ->
                                eval data
        }

Paperclip初めて使ったけど便利。DBへのblob保存に対応してないけど、確かにS3（+Cloudfront？）使う方が賢い気がするのでいいか。

aasm :column => :aasm_status, :whiny_transitions => false do
  state :prepared, :initial => true
  state :queued
　state :accepted
...
  event :accept do
    transitions :to => :accepted, :from => [:queued]
  end
...
end

この例だと、whiny_transitionsがtrueならpreparedから直接accept!とかすると例外を投げる。
以前は単に遷移せずpreparedのままだった。

まぁ、例外を投げるのが正しい動作だとは思う。作者もそう言ってるみたい。
あくまで既存のコードをいじりたくない場合ってことで。