詩と創作・思索のひろば

ドキドキギュンギュンダイアリーです!!!

Fork me on GitHub

ISUCON11予選敗退(92604点、30位) #isucon

ISUCON11 オンライン予選 全てのチームのスコア(参考値) : ISUCON公式Blog

チームは カラアゲネイティブ-ng。92604点、30位だった。通過ラインが 106094 点だったのでもうひと伸びあれば、というところで悔しい。

メンバーは去年と同じく songmu & toricls。予選の問題を見たときは AWS、IoT、時系列データベース、おれらの得意分野じゃんとか言って笑ってた。

やったこととおぼえていること:

  • 実装は Go。
  • 今回は去年の個人的な反省を活かして自分が構築、songmu & tori でアプリケーションを見る、という感じで進めていった。といっても songmu さんの秘伝の Makefile を頼りに見様見真似でやってみた、というレベルで、ミドルウェアのチューニングなどは何もやってない。
    • Makefile はさらによくなった気がする。
    • 構築してるあいだに2人でじっくりコードを読んでくれていて、方針建てがクリアだった(と思う)。
    • しかしあとから追いついた自分は全部を完全に読めていた自信がなく、自分では良い判断ができなかったようにも思う。
  • nginx を 01 に、Redis を 02、MariaDB を 03、アプリを全台に置くように分散。
    • これであまり問題にならなかったと記憶してるので、ここから再配置はしなかった。
    • Redis は初手では入れなかった。
  • 全体的に songmu さんがいい感じにブレーキをかけてくれていて、アクションの決定は拙速を免れた。これはよかった。
  • pt-query-digest を参考に、インデックスを張る系の作業を行う。
  • あとは画像周りを DB に入れてるのが重く、ファイルに保存するか……と考えたけど、Cache-Control をつけたら問題にならなくなった。
  • http.Transport.MaxConnsPerHost を大きくしたのも多少効果があったような気がする。
  • このへんで手が止まり、大きめの改修が必要だねという話をしていよいよ isu_condition を Redis 化することに。
    • ソート済みセットを使う。ここは並行実装できてよかった。
    • これで絶妙なハマりをしてしまって、コードを読んでもロジックはおかしくないように見えるのにFAILする……なぜ。
    • となってしまい、DB に入っているデータと Redis に入っているデータを目視で見比べることをしてみたところ、timestamp をわざわざ除いて JSON 化していたレコードがまったく同じ文字列になってしまっており、レコードが縮退してしまっていたことが判明。Redis のソート済みセットでは値の重複は許されない。それは知ってたわ~といいつつ直した。
  • あとは encoding/json を goccy/go-json にしただけでスコアが上がる。これには笑った。ありがとうございます。
  • 以上いろいろ取り組んでみたものの、dropProbability をなかなか上げられない、上げてもスコアが思ったように上がらなかったので苦しかった……。
    • ユーザ数に応じて dropProbability を変えてみたらいいんじゃね? と最後に思ったがうまくいかなかった。おれはこういうこと言いがちである。

割といいところ行けると思ったんだけどなー! 個人的にはアプリケーションの理解があいまいなまま走り出したのが反省点。

リポジトリはこちら:

GitHub - x-motemen/isucon11-qualifier: カラアゲネイティブ-ng

よく考えたら x-motemen に置くのどうなんってなるな……。来年もがんばります。

はてなで一緒に働きませんか?