はじめに

東京でバックエンド開発してる北村です。

ISUCON部ブログリレーです。

前回のこやまんさんからバトン受け取りまして、次の方へとバトンを繋ぐべく、筆を取らせていただきました。

参加きっかけ

りっきー部長からの熱烈なオファーを受けての参戦です。

なーんて嘘です。

ISUCONの存在は知っていたですが、取り組んでみたことはなかったです。

こーゆーのって大体パターンなんだろうなぁ、っていう思い込みがありまして。

で、最近何やかやと社内で盛り上がっていたの何だか楽しそーだなと指をくわえて見てました。

で、で、ひっそりやってみたという感じで、何を隠そう幽霊部員だったりします。

面倒臭いやつですね。

対策の予測を立ててみる

そんなこんなで部で取り組んでる題材の改善すべくやってみたです。

改善するにあたってあらかじめ対策の予測を立ててみました。

先ほども書きましたがある程度パターンなんじゃ感。

この辺は経験ですね（とかクールに言ってみる）。

• DB/SQL
  • 適切なインデックス設定
  • 諸々無駄なSQLの有無
• アプリ
  • N+1 （ループ処理中にSQL問い合わせしちゃう先輩社員に見られたらネチネチ怒られちゃうアレ）
• 各種ミドルウェア
  • の設定パラメータ
• キャッシュ戦略

実際やってみた

環境構築して何も対策してないプレーンな状態でのスコア結果がこちら。

1{"pass":true,"score":112,"success":537,"fail":23,"messages":["リクエストがタイムアウトしました (GET /)","リクエストがタイムアウトしました (GET /@dionne)","
2リクエストがタイムアウトしました (GET /logout)","リクエストがタイムアウトしました (POST /login)","リクエストがタイムアウトしました (POST /register)"]}

うーん、タイムアウト(｀・ω・´)

これはやりがいあるなー、よりもしんどいが先行しちゃう。

ともあれまずはDB/SQL関連を確認。

前回の記事でこやまんさんも言及されてましたが、各テーブルにインデックスを設定。

スコア再計測結果が  8000 前後。なるほど。

この後も対策の予測に沿った観点で調べてみたですが、そのことごとく要対応でした。

そう、パターンなんですよ。

まとめ

で、予測に沿っ対応しての最終スコアはだいたい以下な感じでした。

1{"pass":true,"score":75480,"success":73577,"fail":0,"messages":[]}

トップスコアラーな方々のだいたい1/4。

うーん...すごいな、30うん万点。

おじさんのトラディショナルな経験では太刀打ちできない高い壁がそこにはあるみたいです。

あるいは確認/対応すべきパターンの引き出しが致命的に不足しているのかもしれない。

ともあれ勉強が足りてないですね、反省です。

部の皆様、こんどご教授願います、こっそりと（嘘です）。

次回...はどなたにバトンをお渡せば良いんですかね？（幽霊なんで...）。ともあれ乞うご期待！