ISUCON8予選に@k5342と @euglena1215 とでて惨敗しました．さようなら．
ふたりの記事は(特にk5342のほうには)詳細に書いてあるので，そちらを参考にするとムーブがよくわかります．ありがとうk5342メンバー！
なんか二人がいろいろ書いているので私はポエムを書こうと思います．
ポエム
nginx 最適化設定編
nginxとは，紛れもなくweb サーバであるが，単にエンドポイント振り分け係としての機能に加えて，同時にロードバランシングができたり，sessionを保存しているノードに振分けることができたりとそれなりに有能なのである．似たような機能を持つものとして，Apacheやh2oがある．これらのチューニングのうち，Apacheのみは経験したことはあったが，h2oはデフォルトではやい*1 らしくまともにチューニングしたことはなかった．なにより，デフォルトのh2oはデフォルトのnginxよりは当然性能はいいが，高度にチューニングされたnginxはh2oと同等もしくはそれ以上の性能を引き出せると未だに考えている．
ところで，今回のISUCONの初期実装ではh2oであった．/etc/nginx がないというのはかなりの衝撃であった．が，未だにh2oであったその真意はわかっていない．それでも上記の理由に加えて，不慣れなものはとっとと切り出すほうがそこに時間を食わなくて済むという経験に基づいて開始早々引き剥がす決断をした．
nginxの最適化というのはアプリケーションの実装によってどのパラメータを変更するのか，様々な使用率状況を把握しながらある程度は自動的に，それ以降は職人の勘で行っている．無闇矢鱈に様々なパラメータを on にすることは避けたほうがいいというのがここ数年 nginx調整係*2としての勘である．
それを踏まえて今回のISUCONを振り返ってみるとあまりにも勘に頼りすぎた可能性がある．例えば，今回の問題のアプリケーションやDBのCPU使用率はそれなりに高く，またそれ以上にメモリの使用率が半端なかったので，gzip周りで最適化することはこれ以上にサーバーに負荷を掛けてしまう恐れがあるため今回は見送った．また，最低限静的ファイルのキャッシュは終わらせたがそれ以上のチューニングは難しいと判断して早々に放置してしまった．いま考えるともっとチューニングバトルをしても良かったかなと思う．ということが複数個あって，「やらないで後悔するくらいならやって後悔したかった」という感じだ．去年のような画像がそれなりにある問題でCache-Control をつけると脳汁がドパとでるほどにスコアが跳ね上がる傾向にあるが，今回みたいなタイプはどうしてもスコアが上がりにくいし，しんどすぎという感じだった．
一方で，早々に切り上げる判断ができたのは良かったと思える面もある．それは明らかにnginxよりもmysqlの設定を更新したほうがスコアが上昇する状況だったので，小手先のスコアを伸ばすくらいならアプリケーションが大量のN+1問題やN*(N+1)問題(多重にN+1問題を起こしている)のようなDBへの負荷を爆上がりさせてくれるような問題を抱えていたのでnginxに時間割かなくてよかったとも言える．
mysql最適設定編
mysqlのチューニングとなるとinnodb_buffer_pool_sizeをいじるだけでしょ（笑）みたいなことを言われるが(言われたことはない)，それ以外にもデフォルトだとそれなりに低く設定されているため改変するべきものは多くある．
しかし，今回の問題では上で書いたとおり，DBのCPU負荷，メモリ負荷が尋常ではない状況でメモリキャッシュさせるのはどう考えても悪手であるという感じだったので，max_connections を増やす程度の設定しかできなかった．
ただ，複数台構成が実現できそうになるとDB単体で一つのサーバが与えられ，それなりにメモリに余裕ができてきたのでそのような設定を入れることができたのは良かったと思う．
ここまで書いていて
ここまで書いていて，今回のISUCONは昨年のISUCON本選同様に，最適設定ゲーではないというのがわかる．つまりアプリケーションをなんとかしないと話にならない．という話だ．
ペアプロ編
例のget_eventsクエリ潰し大会で三人でペアプロしたのが良かったのか悪かったのか問題はメンバーの間でも様々であるが，結果的には成功だったけど明らかに時間を掛けすぎた．あれに関してはてっぺーさんを信じるのと，値を見間違わないようにしないといけないという感じ．うーん．悲しい．
report_for_sales重い問題編
これは重い．おもすぎて60秒以内にレスポンスが入ればみたいなレギュレーション *3 である時点で明らかにやばいオーラを放っている．こいつがそれなりに重いためメモリ食ってんじゃないかという話になり私が担当した．sqlが3つのテーブルをinner joinするような形を取っていて，ほぼすべてのスキーマを参照してそれを一度ハッシュにぶち込んで，それをソートして渡して文字列を生成してcsvにするという形を取っていた．
この問題に当たる頃にはとにかくアプリケーションのCPU使用率とメモリ使用率を下げろ！という指示だった．
まず問題としてありえん巨大なsqlを改善したいとなったが，これをチューニングするのは死ぬほどつらそうと思った．次にわざわざメモリに展開してからソートするのは馬鹿らしいのでsqlでORDER BYすればいいと思った．よく確認するとsqlですでにソートされているのに再度ソートを掛けていて :thinking_face: となったのでその処理を外した．また，わざわざハッシュにする意味もないので直接文字列生成してそれをrender するみたいな方針にした．
この効果は不明だが微妙にスワップが減ったが微々たるもの(k5342談)だったので，うーん辛い．
総括
多分，負の貢献をしてしまったのでつらい．お茶くみすればよかった．なによりRubyチームにのみ多く見られた例の問題は言語的な辛さなのかなぁと他のチームの話を聞く感じ思った．また，salesのところだけエンドポイントを切って別サーバに任せるという技がまじですごいなと感心した．すごい．
最終スコア
これでは顔採用は厳しいです．
リポジトリ
謝辞
WantedlyオフィスでISUCONに参加させていただきました．まじでありがとうございました．ディスプレイ借りれたり，ホワイトボードを借りれたり，テレビ借りれたり，椅子(いいやつ)を借りれたり，助かりました．あとオフィスが綺麗でした．
また，去年と同じメンバーで今年も参戦することができて非常によかったです．かなりバランスの取れたチームであったので本当に本選に駒を進めたかったです．来年も @euglena1215が電撃で留年か大学院に進学することで学生枠で出たいです(冗談です)
