下記イベントの参加記です．

優勝賞金100万円！今年もやります第４回 ISUCON 開催と日程のお知らせ #isucon : ISUCON公式Blog http://isucon.net/archives/38857424.html

去年と同じように一日目に「パイの実g」で参加していました．予選の問題詳細の記事出たらリンク追加予定．追記しました．

ISUCON4 予選問題の解説と講評＆ AMIの公開 : ISUCON公式Blog

http://isucon.net/archives/40724693.html

結論

Score: 2677

実装に失敗して初期状態で動かしたベンチのスコアがそのまま結果となっています．

箇条書き

ここの記述はチームというより自分の考えのみを記述しています．

自分の簡単なスキルセット

主にコード書く人
- Go まあ読み書きできる
- PHP まあ読み書きできる
サーバ構築とかは趣味で軽くやるレベル
- 金がないので AWS の知識はほぼない
isucon とかチューニンガソンとか出たことある

開始前

事前に考えていた戦略

基本 Go で最悪 PHP を使う
- Go
  - たぶん早い
  - ただでかい修正入れるほど習熟してなさそうなのでやるならちまちまコード変更程度でがんばるぐらいでしょう
- PHP
  - 大きな改善点見つからない場合ノウハウみつかりやすいのでちまちまコード最適化したりパラメータいじって戦えるかなと
  - Phalcon 書き換えならできなくはないので検討
重そうな修正を時間的に早めにやって終盤軽めのを選んでやる
- ミドルウェアの設定とかはわりとノウハウ転がってるので最悪コピペすればよさそう
- 早めに着手すると固執したり実装によっては無意味になる可能性があるのでできれば後のほうでやりたい
キャッシュ出来るところはする
- 去年の isucon やチューニンガソンなどの教訓
ベンチのオプション確認する
- 去年 isucon で workload の存在に気付かなかった教訓
バージョン入れ替えとかは余裕があればやればやるけど多分そんなスキルはなさそうのでやらない
できれば人数分インスタンス立ててそれぞれやったほうが効率良さそう
- AWS クーポン来たのでそれの範囲内でやるために 1 台で考えることにした（若干敗因理由）

開始後

確認時やったこと

アプリ触る
query.log で全部出して傾向見る
slow_query.log でチューニング部分に当たりをつける
コード軽く読む
- 自分は手元に PhpStorm があったので挙動把握は php 読んでた
- どこかキャッシュ使えないかなとか

簡単に確認した後の感想

対象アプリ触って

フィッシングサイトっぽい
見る感じページは二つでログインフォームとログイン後フォームっぽい
ログインフォームは失敗時にフォームのページに戻ってきてエラーメッセージ出すっぽい
ログイン後になんか動的に出力するものがあるページを表示するっぽい
ベンチ走らせてなくても isucon-bank.png の画像取得に成功したり失敗したりするなぁ（勘違い？）

改善に関して

Go は martini かー知らないなーフレームワーク重そうだなー
テーブル少ない（ users と login_log の二つ）簡単に手は入れられそう
ユーザの追加などの更新はないオンメモリにできる？
login_log の INSERT 重い消したい
テンプレート少ないキャッシュしやすい？と思ったけどログイン後の情報必要なので無理かなぁ．

感想から簡単な戦略

Go 使うかー

軽中重で自分の感覚でコストを考えつつ打てる手を考えた結果

（軽）テーブルやカラムは少ないためインデックスなどのチューニングはさくっとできそう
（中）ユーザ情報はオンメモリにできそう
（重）INSERT なくそう
（軽）静的ファイルをフロントでうまく返そう

無視

Go のフレームワーク変える（というか外す） -> 今のスキルじゃバグ無し変更はたぶん無理

方針決定後

当初の予定通り重いのからやろうとしたので INSERT なくすあたりに手を出す．（終わったらミドルウェアの設定やるつもりだった．）

作業内容見積もり

コード読んでテーブル設計する
- users に最終ログイン情報突っ込む
- BAN の ip と user は別っぽいので ip でテーブル作る
変更したテーブルに合わせてコード変更する
テーブル変更に対応した初期化スクリプト

担当分担

ここらへん記憶が曖昧

初期化スクリプト書く人
コード変更する人
コード変更する人 && 方針が正しいか検討する人

作業

ハマった所

初期化スクリプト
- webapp のライブラリを使いまわそうとするも失敗してて時間食ってた様子
BAN 対象の ip や user の決定方法
- コードが結構わかりにくかった
  - クエリ複雑
  - コピペミスでわざとバグっぽい書き方してるのかと勘ぐる（rowsB 作った後に rows 参照してるあたり）
- テーブルに存在しない login（カラム名）は必要なのかどうか
  - たぶん要らないと判断
BAN 対象の ip や user の更新
- SQL 間違いまくる
- （ここの修正ができなかったため 0 点）
last_login 情報
- なんで limit 2 してる？
  - ログイン情報がないときに今ログインした結果を使うためか！
- /mypage じゃなくて /login 時にいろいろ session にもたせるようにしよう
  - session に入れた値がテンプレ側で nil になり panic
martini
- よくわからん
/report の並び順ってなに？
- 多分 primary key 順なんだろうけどよく調べてないのでなんでもいいものと決めてかかる
- 正しい判断かどうか不明

結果