そして惨敗した話だよ。
こんにちは、ゆめです。
普段はアプリケーションの設計とか、運用周りのこととかやってます。
プログラミングはやりたくなったときに遊び程度にしかやらない私が、ISUCONになんちゃって参加してきました。
ISUCON詳細
http://isucon.net/
チーム編成
- インフラエンジニアまつb
- わたし
もう1人いたらいいなと思って「下僕」という名前も含めた3人チームでエントリーしてましたが、
誰も下僕になってはくれませんでした。
会場
住み慣れた弊社のMyデスク
お題
運営さんが用意してくれたSNSサイトで高パフォーマンスを!
※お題サイトみたときの衝撃。凝ってますよね。
予習
去年のISUCONの環境再現したり、ブログ読んだりしました。
言語
PHP
一番慣れていたので。
SQL文以外のソースをいじれる気はあんまりしなかったので、
PHP読んで仕様把握してRubyのソースをアレコレしようとしてましたが、
結局PHPに変えてもらいました。
自分で書くときはフルスクラッチなので他の書き方も慣れてなくて、
人のソース読むのも大変だった。勉強になったなぁー。
方針
- ブラウザでサイトの内容や機能をざっと確認する
- MySQLのテーブル構造把握する
- SQLを投げる部分に重点を置いてソース読む
- とりあえずindexはる
- SQL_CACHE使えそうな部分を探す
- SQL文見直す
- テーブルを非正規化してみる
あとは、やっていくうちに、
「日記のTitleとBodyで何でおんなじカラムに入ってんの?」
とか
「relationsの設計なんとかならないの?」
とか
「is_friendsをなんとかしたいなぁ」
とか
「そもそもusersにselectかけすぎじゃない?」
とか、徐々に気づくかんじでした。
でも、ちゃんと修正できなかった。。。
- title/body分離
→もともとtext型だったので、titleをvarcharにしていいのか悩んだ。
text型がテーブルに複数あるってどうなのかしらと余計なことを考えるうちに終わった。
- relationsテーブル
→「SELECTを変えず、insertを減らす(one、another1パターンのみ)」のが正解だと分かってはいても、
初期データを半分に減らす方法がすぐに思いつかなかった。
結局、SELECT文のWHERE句をoneのみにしました。
- is_friends
→認識はあったものの、対応策を考えるところまでたどり着けなかった。。
- users
→呼び出し回数が多い上にテーブルの内容が変わらないので、どっかにまるごと持たせておくとかした方がよかったかも。
※footprintはどうにかせねばと思ってましたが、まつbに任せきりでした
課題の発見ポイントはなんとなく押さえられてたけど、
修正の具体策を考え・実装するのに時間がかかってしまったのが大きな反省。
普段は課題発見して修正方針決めたら、
実際のコーディングは別の方が担当するため、
自分にその力量・経験がないことが露呈してつらたんでした。
やっぱり、普段やってないことはできないね。