ISUCONとは

http://isucon.net/
WEBサービスのチューニングのうまさを点数化して全国で競い合うコンテスト

今回の問題

今回ははてぶのようなwikipediaのような、百科事典登録・閲覧サービスのようなものでした

キーワードとコンテンツが登録できること
キーワードとコンテンツが閲覧できること
コンテンツの中身にキーワードが含まれていたらリンクにすること

アプリケーションが2つ、DBも2つの構成でした。
テーブルは全部で3つ（user,コンテンツ,お気に入りの星）

チーム

去年と同じチームで再挑戦してみました（去年の記事）
ミドルウェア担当・アプリケーション担当・DB担当の分担を行い、私はDB担当での参加でした。
言語も去年と同じくRuby

やったこと

ミドルウェア担当がボトルネックを調べるためにログを仕込んでる間にアプリケーションの作りを把握
アプリケーション担当「てかなんでアプリケーションとDB2つに分かれてんの、統合したい」
私はDB担当だったのでアプリケーションで叩かれるクエリを見つつDBのインデックスまわり、データの持ち方を見る
descriptionという記事のコンテンツを格納しているカラムがあり、どうやらこれがボトルネックだと悟る
キーワードの取得処理がN+1のクエリが走っていたのでアプリケーション担当がサクッと改修（この時点で5000アップ、瞬間最高5位!）
昼過ぎくらいにボトルネック調査の結果が上がってきたのでチェック、トップ画面とログイン処理が遅いことが判明
記事の投稿者を示すauthor_idを保持していたが使っていなかったので削除（使ってないのでスコア変わらず）
updated_atでorder byしているクエリがあったのでupdated_atにインデックス付与（大してスコア伸びず）
ミドルウェア担当が静的ファイルの返し方を変更
キーワードの長さでorder byしているクエリがあったのでクエリでやらずにアプリケーション側で行なうように改修（アプリケーションの改修にやや手間取り、しかもスコアも全然伸びず）
記事の表示の度に正規表現で記事内のキーワードをリンク化している処理がめちゃ重だったのでキャッシュ化（ここで1万点を超える）
select*で全てとっているところが無駄だったので必要なもののみを取得するように変更（ちょっとアップ）

瞬間最高5位の図

結果

初期スコア	12:00	16:30	最終スコア
0	6000	15500	14400

感想と反省

まず反省としては、レギュレーションを勘違いしていたこと。
initializeの処理でDBの構成等も全て5秒以内に作り上げ、そこからスタートだと勘違いをしてしまった。
キーワードの文字列長をDBのカラムとして持ち、そこにインデックス貼ってソートしたら速いのでは？という案は出ていたのに「いや、initializeの5秒では終わらないね」ってことで断念してしまった。
レギュレーションをちゃんと理解してなかったのがとてもとても反省でした。
また今回はアプリケーション層での改修の比重がとても大きかったのでDBの構成がシンプルなのを見て、アプリケーション側にすぐに手伝いに入ればよかった。
あと初めから「アプリケーションとDB1つにしたい」って話が上がっていたものの結局行わなかったのでそこはチャレンジすべきだった。
今回は初めから役割分担をしていたのですぐに自分の分担の作業に取り掛かれたのはとても良かったが、全体像を眺め終わった後に作戦会議と改修方向の認識合わせを行えば良かった。

おわりに

直接点数での比較はできないですが、去年は1800点で手も足も出なかったのに対して今年は15000まで上げることができたので確実に成長しているのを感じた。
参加すること自体に意味があると思っているしとても楽しかったので参加の意義はあった。
チームの2人がとても悔しがっていたので来年は予選突破を本気で狙いにいきますかね！
ちょっとでも興味が湧いた人は来年は是非参加しましょう！