時計を壊せ

駆け出してからそこそこ経ったWebプログラマーの雑記

#isucon2 で惨敗してきました

isucon Benchmark

潔く。

思った事

ソースを見て

  • DB重そう
    • 参照系クエリでJOINしまくってるなー
      • recunt_soldとか
    • 更新系重そうだなー
      • IS NULL
      • ORDER BY RAND
  • appがstatic file返してるの無駄だなー
  • front endがapacheなのはやめたほうがよさそう
  • 最終的にはmemcachedにレスポンス突っ込んでnginxのmemcachedモジュールで返せればいいなー
    • recunt_soldは別パスにしてSSIで分離出来るとキャッシュの寿命分けられていいなー

負荷を見て

  • やっぱりDB重いなー
    • これいっそRedisとかで書き換える方がいいのでは
    • でもRedis普段使ってないし怖いなー
  • ベンチ直後のappが重い？
    • いろいろ疑ってみたが原因わからず
    • DBIをdisconnectしてみたが、遅くなった
    • いつの間にか解消されててなぞ
  • rev負荷あんま無いなー
    • appたててしまうとよさげかなー

どうでもいい系

  • ラーメンたべたいなー
  • 鯖…
    • 鯖……

やった事

  • ngrircd/git/NoPasteのhosting
  • appの中のあやしいクエリの洗い出し
    • 洗い出しただけで終わってしまった事が悔やまれる
  • nginxの野良ビルド/supervisord管理化
  • nginxから静的ファイルを配信するようにする
    • gzip圧縮のせいで重くなる
      • うっかり一緒にコピってきたので気付かず
  • extlibのdeploy整備/ショートカット作成/git管理化
  • memcachedをアプリから使えるようにする
  • recunt_soldのキャッシュ
    • ベンチがコケたのでrevert
  • configをfork前にloadするようにする
    • 焼け石に水だろうけどとりあえず
  • Cache::Memcached::Fastがうっかりlocalhostを見たままだったので戻す
  • gzip onでベンチ通ってるのでgzip_staticに変える
    • ベンチがコケたのでrevert
      • いま思えばベンチがこけたのはたぶん別の原因
  • Clutchをアプリから使えるようにする
  • recunt_sold用に別テーブルを用意
    • サマリをworkerで作る。(/buyのタイミングでenqueue)
      • このとき初めてClutchを利用
      • しかしうまく動かず
        • 最初はClutchがおかしいかと思ったがそんな事は無かった
        • INSERT INTOは成功してるけどSELECT出来ない謎
        • Blackhall Engineのテーブルを別に用意してInnoDB Buffer poolを温める機構があったので疑ったがInnoDBだったし関係無かった
        • 未だに謎

反省

推測するな計測せよ

負荷を計測する方法は分かっても、そこからの分析が十分に出来ず、
なんだかんだすぐ推測に走ってしまった。
負荷分析は知識が足りないのと、経験が足りないのとがあり難しいのは分かっているが、
せめてもう少し経験があれば「この情報が足りない」「このパスのこのときの実行時間分布が欲しい」とかが判断出来たのかなーと思った。
また、焦ってついつい計測してしまったというのも大きかった。

ついコードをいじりたくなるのを我慢してアプリの挙動と性質を正確に把握する

アプリの性質がわからないと効果的なチューニングが出来ないので、（やっても局所的なチューニングになるので大幅にスコアを上げる事はほぼ出来ない）
ここを正確に把握する事でもっと効果的なチューニングが出来たはずだったが、
ついついコードをいじってはベンチを走らせてを繰り返し、ミニマルなチューニングのみで終わってしまった。

ついコードをいじりたくなるのを我慢して話し合って方針決めと役割分担をする

前回よりは情報共有は比較的出来ていたが、それでもベンチマーク情報、計測情報の簡単な共有、作業しますよ宣言、＋αで終わってしまった。
誰かがリーダーシップを執って（今回は前回も参加している自分がやるべきだった）しっかりと話すべきだったが、
ついつい手を動かしてしまっておざなりになってしまった。

ついコードをいじりたくなるのを我慢してちゃんと計測する

急がば回れという言葉の通り、本来はしっかりと計測と分析をして、
アプリの性質とボトルネックを把握してチューニング方針を決め、
それから手を動かすべきだった。
しかし今回もついつい慌ててしまい、絶対やる系のチューニングをやって（本来はここで一旦作業を止めて計測と分析をするべきだった）
その後もぐだぐだ細かいチューニングを続けてしまった。

良かった事

  • 前回よりは負荷が分かった
    • 計測スキル/分析スキルの成長
      • とはいえまだまだ
  • 前回よりは状況を把握しながら動けた
    • 他の2人の間の席だったのが幸運？だった
    • 他の人の画面を見たりして状況を把握しやすかった
      • ただしそれを最大限活かすことが出来たかという問はNO
  • 楽しみながら出来た
    • アプリを最適化するのは楽しい
  • コーヒーおいしかった
    • @941++

お礼


おつかれさまでした！