ISUCON6ダメでした #ISUCON
去年の に引き続き2回目のイスを投げるコンテストに @uadachiさん, @hayasshi_さんと チーム お腹すいたCity で出てきました. 自分は学生ですが一般枠です. 結論から言うと ダメでした
以下文章力がないのでメモみたいな箇条書き
前日まで
チームリハーサルとしてISUCON5のお題をakka-http+scalikejdbcでフルスクラッチ(!)
- akka-httpは初めてだったが同期/非同期制御周りが非常に扱いやすい印象. また使ってみたい
- が, やはりフルスクラッチに5hほどかかってしまった(しかもチェックしきれてない)ので断念, おとなしくチューニングで行く方針に
- (恐らく3人とも慣れていれば十分にできると思われ)
その他, githubのprivate repoとslackとかを使いながらいい感じのconf集めやらsnippetsの用意
当日
- インタァンの関係で自分はリモート参加
- 去年のエントリで「ハングアウトで通話しながらやってたんですが, 実際に集まるべきでした. 多分効率が全然違う.」とか書いたのに…
- 予定通りScala実装で, 去年と違いちゃんと動く実装だとのことで一安心
- ソースを読むと結構こなれたコードが散見された(出題がはてなさんだからかな?)
- よさisここにあり
- ソースを読むと結構こなれたコードが散見された(出題がはてなさんだからかな?)
- とりあえずベンチ回すと他のチームが3k~4kの中, 堂々の 0点
- 主に以下の分担で進めた
- DBやらクエリ周りをいい感じに
- Nginxとか静的ファイルとかをいい感じにしたり全体の管理とか(@uadachi)
- redis導入や非同期処理やデプロイ周りやら(@hayasshi_)
- apiごとの細かな部分はその場で分担
- 個人的にslow queryやコードから明らかだった
htmlify
の改善. (終わってから超重要なポイントだったと知る) - 「keywordはメモリで管理行けるやろwついでになんかすごい正規表現あるし適当に直そw」という軽いノリで直そうとする
- 当然のようにハマる
- concurrentなcollectionに慣れておらず微妙に手間取る
- escape処理をミスりまくってバグの嵐(contentが全部リンクになったりして楽しかった(棒))
- (模範解答らしい?)aho-corasick?trie?とか考える余裕なく
- 個人的にslow queryやコードから明らかだった
- 普段intellijで完結させてるせいで, 「あれ?UbuntuOnWindows環境でsbt動かないっけ?」とか言ってローカル環境で動かすのは諦めた(←後々致命的すぎた)
- その他, メンバー全員で非同期沼にハマったり(servletサン…)
- 最後の最後でそれなりの速さで動いた(っぽい)もののベンチマーク間に合わず😇
去年からの成長点
- リハーサルをしたおかげか, DB周りの(簡単な部分の)扱いがちょっと早くなった
- 設定を流し込んだり
- 一部計算をcolumn化したり
- indexやらメタ的な部分の確認・調整
- 開発スタイルの確立
- PRは作るがガンガンmerge
- あれ…?それだけ???
- まるでせいちょうしていない
去年からまるで成長してないことを思いしらされた。
— YutaAdachi (@uadachi) 2016年9月18日
もっとやるべきだったこととか
- キャッシュ箇所の洗い出し
- もっと早く, 明確に
- 大体メモリに載せれば早くなる(てきとう)
- ロジック変更を伴うチューニングといかにうまく並行して作業分担ができるか
- 若しくはキャシュ箇所は思考停止で先に全部やったほうが後々楽か(?)
- 正規表現の扱い
- aho-corasickとかtrieに切り替えていくための知識と勇気
- 統合の検討
- APIレベルであったり
- 今回のようなmicro serviceであればそれらの統合も視野(?)
- skinny frameworkに詳しくなる
- ベンチでfailした箇所を早期にデバッグ・解決する手段
- ローカル環境はなにがなんでも用意する
- やっぱり最初は デバッガ使ってアプリを実際に動かして 追いつつ
- 終盤色々弄ってバグらせないためにも必須
- リモートはダメ, ちゃんと集まる
- 打ち上げが許されない
お疲れ様でした. 結果はダメでしたが色々と知識が増えました. 最後に非常にいい感じのコミットログで〆