RubyKaigi 、2010 年のに行ってすごく感化されて 2011 年も 2012 年の Sapporo も行きたかったけど結婚するといろいろあってそういうのは無理だった。当然のように今年も無理だった。恐らく自分は終生 RubyKaigi には行けないのだと思う。ああいうプログラミングのイベントに熱心に参加したり運営の方に回ったりする人は本当にすごいと思う。みんなそれぞれ家庭とか奨学金の返済とか住宅ローンとかあるんだろうけど、時間をやりくりしてコミュニティ活動を行っている。
受託の会社にいた頃、技術とかどうでも良くて言われたとおり作って金がもらえるならそれでいい、というような情熱がない感じの人だらけの職場がとても嫌だった。しかしいま自分が彼らのようになりつつあるように感じる。悪い感じにサラリーマン化している。このままでは新卒とか有能な若者にあっという間に追い越されて老いさらばえていくだけだと思う。それは分かっているけど 30 歳くらいになるといろいろ厳しい。
フッターのキャッシュとかフラグメントキャッシュはできたので、サイトのなかで一番重いアーカイブページのキャッシュを考えてみることにした。
当初はアーカイブページも、一番重い記事一覧表示部分をフラグメントキャッシュしてみていた。しかしあまり効果がなかった。Sinatra は仕組み上、コントローラーにいろいろ書いてしまいがちになり、アーカイブページのコントローラーが Fat になっていた。そのためフラグメントキャッシュをしたところでコントローラーの重い処理はビューがレンダリングされる前に走ってしまい、キャッシュの意味があまりない状態だった。
Rails だったらアクションキャッシュとかあるけど、先日から Folk して改造を進めている sinatra-cache でできるのはページキャッシュとフラグメントキャッシュだけなため、ページキャッシュをしてみることにした。
ページキャッシュの残念な点は Nginx 側の設定も必要なことだ。せっかく Lokka は Heroku や Sqale など Rack アプリケーション置ける PaaS にならどこにでも置けるのに、Nginx の設定変更を前提とした変更を行うと CMS for Cloud ではなくなってしまう。しかしこのブログは自分の勉強の場でもあるのでえいやっとやてみた。
sinatra-cache は Lokka + Nginx + Unicorn という環境であれば、LOKKA_ROOT/lib/lokka/app.rb を開いて以下のようにしてやれば使えるようになります。
require 'lokka'
require 'sinatra/cache' # <= 追加
module Lokka
class App < Sinatra::Base
configure do
# ...
register Sinatra::Cache # <= 追加
set :cache_enabled, true # <= 追加
# ...
end
# ...
end
endとかやってやれば、勝手に LOKKA_ROOT/public にキャッシュファイルを作るようになります。Nginx 側でキャッシュファイルがあれば Unicorn に proxy せずキャッシュファイルを返すようにすればページキャッシングで爆速になる。sinatra-cache は {$request_filename}.html という名前でキャッシュファイルを作るので Nginx の設定は以下のような感じになる。
server {
location {
root /var/wwww/portalshit/public;
# ...
if (!-f $request_filename.html) {
add_header Cache-Control public;
rewrite (.*) $1.html;
break;
}
# ...
}
}ポータルシットはトップページも重いのでトップページもページキャッシュしようかなと思ったけど、ページングとかあるのでいろいろ面倒くさいことになることに気がついた（キャッシュファイルがない状態で Google のクローラーが 35 ページ目とかをクローリングしてたら 35 ページ目の html が index.html としてキャッシュされてトップページに来た人が全員 35 ページ目を見ることになってしまう）のでやめた。
キャッシュ、レスポンスを速くしてくれるけど何でもキャッシュすれば良いわけではないし奥が深い。
Lokka でキャッシュしたいと書いてたけどキャッシュできるようになった。
結局 sinatra-cache を使った。sinatra-cache、2 年くらいメンテされてなくて全然だめかなと思ってたけどドキュメントが執拗なほど詳しく書かれてて使い方がわかりやすかったので使ってみることにした。フラグメントキャッシュがページごとに共有されなくて非効率的だったところは適当に改造した（morygonzalez/sinatra-cache · GitHub）。
footer 部分だけキャッシュするようにしてるのでトップページのレンダリングはあまり変わってないように感じる。個別記事ページは HTML が返ってくるまで 2, 3 秒かかってたのが 500ms から 600ms くらいになった。割とよいと思う。
いまのところ cache の有効期間みたいのを設定できないのでこれを任意の時間で設定できるようにしたい。しばらく使ってみて問題なさそうだったら Lokka 本体に Pull Request してもよいかも。
他の人は Vagrantfile をプロジェクトルートの上に置いてるけど自分はプロジェクトルートに置きたくて、Vagrantfile を ignore したいと思った。しかしそれは自分の都合なので PROJECT_ROOT/.gitignore には追加したくない。そんなことはありませんか。
シェルの設定ファイルでやるみたいに、 .gitignore.local みたいなファイルを作って読み込ませたり出来ないのかなと思ったけど、出来ないみたいだった。
ところで git はホームディレクトリにある .gitconfig に git config --global したときの設定情報を保存する。自分は ~/.gitconfig に以下のように書いてる。
[core]
excludesfile = /Users/morygonzalez/.gitignore
自分のホームディレクトリにも .gitignore ファイルを作っていて、こちらをプロジェクト横断的に読み込ませている。従ってこちらに Vagrantfile を追加しても良かった。
しかしそうするとプロジェクト横断的に Vagrantfile が無視されてしまい、Vagrantfile をバージョンコントロールしているプロジェクトで困ってしまう。
調べてみたところ、リモートブランチには反映させたくないけど自分の手元だけで特定のファイルを無視したいときには以下のようにすると良さそうだった。
PROJECT_ROOT/.git/info/exclude に無視したいファイル名を記載するPROJECT_ROOT/.git/config で以下のように記載する[core]
excludesfile = /path/to/ignore-definition
自分は新しく ignore-list 用のファイルを作るのが面倒くさかったので .git/info/exclude に無視したいファイルリストを書いた。
友達の結婚式があって、先週末は土日月と東京に行ってた。東京観光してきたけどなかなか楽しかった。ただベビーカーに子ども乗せてうろうろするのはやはり大変だった。初めて来る場所でエレベーターの場所を探すのは大変で、移動に1.5倍くらい時間がかかった。小さなスーツケース持ってるだけなのに健康な人がエレベーター乗るの止めて欲しいと思う。車いすの人やベビーカーを優先して欲しい。東京には電車内でベビーカーたたまずにいるとぶち切れ始める怖い人がいるとニュースでやってたから、いきなり刃物で刺されたりしないか心配だったけど通勤ラッシュにぶち当たらなかったので刺されずに済んだ。
1泊目は目黒のホテルに泊まった。駅から近くて建物はきれいで一階はスターバックスだったけど部屋が狭かった。出張とかで来てて泊まる分には良いけど、家族連れで泊まるにはしんどいなぁと思いながら泊まった。
結婚式が横浜の崎陽軒であったので近いところに泊まろうと思って、2泊目はみなとみらいに宿をとった。2泊目のホテルは良かった。ツインルームで部屋が広く、部屋からみなとみらいの夜景と観覧車が見えて、金持ちになった気分味わえた。日曜の夜ということと楽天トラベル様のおかげで安く良いホテルに泊まれて本当に良かった。ホテルのフロントの人とかは若干冷たい感じだったけど、貧民なのに一人一泊2万円くらいするホテルに5000円くらいで泊まれて本当に幸せだった。おまけに結婚式で食べ足りなかったので閉店間際の成城石井に押しかけて定価の半額以下になっていた弁当を買ってきて食べた。高いホテルに格安料金で泊まって高級スーパーの半額以下の弁当を食べるなんて本当に俺は下衆だなと思ったけど充分満足感あった。オススメです。
EC2 の micro で Lokka を運用してたけど、Unicorn が CPU 100% 近く使う状態が続き、リクエスト送ってレスポンスが返ってくるまでに 30 秒近くかかる状態になってて、AWS での運用を諦めざるを得なかった。さくら VPS に戻したところ、CPU 使用率もロードアベレージも落ち着いた。しかしレスポンスは遅くて、HTML が返ってくるまでに 5 秒くらいかかってる。
Newrelic を入れて調べてみた。Application が一番遅い。MySQL も遅いけど気になるレベルではないみたいだった。
という構成で運用していたのが遅い原因だったかも。App も DB も同じサーバーに置いたら Newrelic 上で Database が遅いと表示されなくなった。つまり Application をどうにかするしかない。
Lokka で動いててもそんなに遅くないページもある。komagata さんのブログは遅くない（heroku に置いてあるっぽいので heroku 側でキャッシュとかいろいろやってあるのもあると思う）。自分のブログに関してはテンプレートで最近の過去数ヶ月の月ごとの記事数表示したりタグクラウド出したりしてるところが遅そう。なので重い処理のところをフラグメントキャッシュしたい。
導入できて動いた。勝手にページキャッシュする。フラグメントキャッシュできるけど、キャッシュのキーが URL のディレクトリベースのため、効率が悪い。
導入できなかった。Padrino::Routing に依存してるっぽくて素の Sinatra で使いづらい。
これも Sinatra が前提。view から使うフラグメントキャッシュ専用ヘルパーメソッド。なんか Sinatra が内部的に使ってるインスタンス変数を上書きするというやり方みたい そのままでは Lokka で使えず <- ｲﾏｺｺ。
最後のやつが一番導入に近いところまで来てるっぽいけど、断片の部分だけ haml のコードを実行させて結果を取得させる、というところがなかなか難しい。Rails の ActionController::Caching のコードを見て参考にしようとしてみたけどちょっとよく分からなかった。
実は最近、仕事で Ruby 書かないおじさんになってしまったので週末に Ruby のコード見てもすんなり頭に入ってこない。ダメだなぁ。
以前、Unicorn が暴走して困ってるという記事を書いていた。しかしよくよく調べてみると暴走してるのは Unicorn ではなく、Syntax Highlight に使っている Python の Pygments を呼び出している Ruby のプロセスだった（pygments.rb）。こいつが CPU をバカ食いしてしまい、アプリケーションのレスポンスがすこぶる悪くなっていた。
少し前、Pure Ruby の Pygments 互換 Syntax Highlighter で Rouge というのを発見していたので、Python を spawn するプロセスがなくなれば CPU バカ食いも止まるはず、と思って pygments.rb から移行してみた。しかし…
なんと逆にサイトが重くなってしまった。やはり Pure Ruby のプログラムは重いみたいである。pygments.rb は C のネイティブコードも含んでいて、速さがボトルネックになるところは C で処理しているみたい。
というわけで残念ながら EC2 のマイクロインスタンスで Rouge を常用するのは無理そうなので Pygments + pygments.rb に戻します。あとはキャッシュして誤魔化すしかなさそう。