fresh_whenで無用なレンダリングを避ける → やめた

Rails 4アプリ(「むびりす」)のレンダリング処理が若干重い件は、結局、fresh_whenによるLast-ModifedとETagヘッダの出力で対応することにした。プラグイン化されたactionpack-action_cachingも、Rails 4のcache_digestsも、なんだか使いづらい。

Last-Modifiedは、テンプレートファイルのタイムスタンプや、表示対象データのupdate_atのうち、もっとも直近の日時としている。

ETagは表示対象データから生成している。実際にはfresh_whenの :etag オプションにデータを渡しているだけだが。現状ではすべてのデータを渡しているので、一部のデータだけにすれば、ETagの生成時間を節約できるかもしれない。

ともかく、無用なレンダリング処理を避けられるようになり、まずは満足。「304 Not Modified」の応答時間が「200 OK」の3分の1程度になった。

2013-03-16

ETag生成処理に不備が見つかったため、fresh_whenを使わないよう戻した。具体的には、アクセス日時の考慮が抜けており「New!」の表示が漏れた、などの細かい部分だ。このあたりを細かく考慮したETag生成処理も試したが、レンダリングより遅くなってしまった。しばらくはこうした試行錯誤が続きそうだ。

turbolinksはまだ使わない

Rails 4のturbolinksを試してみた。確かに速くなったのだが、僕のアプリ(むびりす)には弊害が大きすぎるため、採用を見合わせた。劇場公開カレンダー のauto-discoveryは効かなくなるし、一部のページで使っているロボットよけやリダイレクト用のMETAタグも無意味になる。

仮に将来、META要素やLINK要素まで置換されるようになったら、また試してみよう。

Heroku上のRails 3アプリをRails 4に移行する際に工夫した点

Herokuで動いている「むびりす」をRails 3から4に移行してみた。非互換部分のコード修正は意外に少なく、いくつかのExceptionやWarningを潰すだけで済んだ。ついでにRubyも2.0.0に上げている。

工夫したのは、自動インジェクションされなくなったrails_log_stdoutとrails3_serve_static_assetsの扱い。そして、まだRails 4をサポートしていないheroku-deflaterの扱いだ。

rails_log_stdout、rails3_serve_static_assetsの扱い

rails_log_stdoutとrails3_serve_static_assetsは、「Getting Started with Rails 4.x on Heroku」に書かれているgemには頼らず、以下のようにした。

config.ru
$stdout.sync = true
config/environments/production.rb
config.logger = Logger.new(STDOUT)
config.logger.level = Logger::INFO
config.serve_static_assets = true

heroku-deflaterの扱い

heroku-deflaterは、作者がRails 4を使っておらず、サポートされるのに時間がかかりそうなので、Forkしてしまった。

Rails 4に移行した理由

Rails 3ではSweeperにバグがあり、キャッシュがうまく消せなかった。Rails 4ではプラグイン化され、バグも直っているようなので、移行することにした。Sweeperの挙動はまだ試していない。

ちなみに「むびりす」では、DB処理よりビューのレンダリングに時間がかかっている。速度のみを求めているわけではない(RailsやHerokuを使っているぐらいだし)とはいえ、速いにこしたことはない。

追記(2013-05-05)

heroku-deflaterがRack 1.5をサポートしました。

これで、Rails 4アプリにも普通に導入できます。ありがたい限りです。

プロフィール
2001年からWebエンジニアをやってます
カテゴリ別アーカイブ
記事検索