isuconオンライン予選にチームMiamiで参戦しました！

大分遅れてのエントリになってしまいました。。。
@sonotsさん、@niku4iさんの3名でチームMiamiとして10/6(日)の2日目に参加しました。

おおよそのまとめはお二方のブログにまとまっているので、自分視点の報告を。

前日

前もってrubyを使うことを決めていたので、rubyのプロファイラやNewRelicの使い方とかを復習していました。

rubyでperlのNYTProfみたいなプロファイラってないのかな。。。

当日

30分ほど遅刻して参戦、、、
サーセン >_<

まずはお題のAMIを各々のアカウントで立ち上げ確認。
ベンチを走らせながらアプリを確認。

チューニング開始

まずはslow queryを出してクエリーの確認。
indexの貼り方やアプリの修正の方針を決めて、それぞれ作業を開始。

この段階で、rack-mini-profilerとNewRelicの仕込みました。
NewRelicとrack-mini-profilerはそれぞれ、Gemfileに追加し、bundle installして、

require 'rack-mini-profiler'
require 'newrelic_rpm'

するだけでonになるのは本当に便利！

rack-mini-profilerは主にsqlの発行数が表示されるのがいいですね。
ページを見ながらsqlの発行数を確認。
memosテーブルだけで完結するようにするため、memosテーブルにusernameフィールドを追加(N+1問題)。

あとは、markdownをHTMLに変換するとき、外部コマンド呼び出しをやめて、redcarpetを使ってコンバートするように変更。
あと、表示時にmarkdownに変換するのを、データ作成時にmarkdownにして保存するように変更。
(実はもともと存在するデータは、markdownの内容をそのまま表示するようになっていましたが、ベンチマークスクリプトは通っていました。後で、最初のデータをコンバートするようにしています。)

あと、複合インデックスを入れてパフォーマンス改善。

ある程度、変更が終わって、ベンチを走らせみて、NewRelicを確認。

NewRelicで取ったデータの一部はこちら。

こうやって見ると、recetが遅いのが一目瞭然。
カウントをキャッシュするなど色々修正するも、なかなかブレイクスルーが見つからず。。。

で、そのままタイムアップ >_<

終了後

MySQLのデータをtmpfsにのせようと色々やってる時に、一部テーブルを消してしまって、ベンチが走らず焦りました。。。

で、結局"MySQL 5.6のInnoDB memcached pluginを使ってみる"をみてinnodb_memcached_config.sqlを走らせてなんとか事無きを得ました。

振り返り

去年も出場したのですが、その時はあてずっぽうな感じでチューニングを進めていて、それが大きな反省点でした。チューニングポイントもずれている部分もありました。

そこで今回は、計測しながらボトルネックを正確に見つけてチューニングすることを心に留めて望みました。

実際、今回のisuconでは、NewRelicやrack-mini-profilerを見ながら改善はできていました。
ボトルネックになっている部分の見落としもほとんどなかったと思っています。

で、今回の反省点は手札の少なさ。
知識の量も増えて、触った事があるツール、ミドルウェアも増えたが、ちょっと触ったことがあるだけで使いこなせていないものが多いと痛感しました。 varnishしかり、redisしかり、、、
日頃、積極的に使っていかないとなあ。。。
まだまだ精進が足りないです。。。

isucon、参加する度に自分の課題が見つかって良いです！

最後になりましたが、運営の方々、本当に有り難うございました！

本戦も頑張ります！！