Skip to content

Instantly share code, notes, and snippets.

@rosylilly
Created September 8, 2019 14:05
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rosylilly/79bd3b146c36aa16eb10e7949571edea to your computer and use it in GitHub Desktop.
Save rosylilly/79bd3b146c36aa16eb10e7949571edea to your computer and use it in GitHub Desktop.
ISUCON9

ISUCON9 に出た

リポジトリにやったことは書いてあるし、今回やらなかったことは出来なかったことなので省略。

いくつか思い出深いものだけ言及していく。

  • c9248d474db448e5367084abf42a333049abed09: 手元でもリモートの画像が出るようにした。手元に全部の画像持ってくるのは無駄だと思ったので。これは案外重要で、スクロール幅によってページングリクエストが発火されるので、手元の試験時に大事になる。
  • fc8e55da988972826cfbed938ed2c603ee4346da: これもそう。存在しない localhost がデフォルトである価値はない。最初から用意されてるモックサービスを見に行くように。開発をしやすくしておく、というのを初手に打てるようになると、6年目で落ち着いてきたなと思わなくもない。
  • f70d520bf123d19a6aec7874d10d4db10abac2fd: クエリを JOIN に。あとから思えば IN で別引きしたほうが items のロックに巻き込まれなかったなと思う。反省点。
  • 35a525a95c9bdd063acf89c060471d35774eac2e: このへんで外部 API へのリクエストがヘビーだと気づいて Redis にキャッシュし始める。実際効果はあった。この時点で13:1頃。
  • 86eb73bb9aba5ee8fd79d75f5a701fa5705ed21f: いくつかの理由から shipment API のキャッシュを一部諦め始める
    • 理由は以下の通り
      1. shipment create 後は initial という state なのは自明なので、レスポンスをキャッシュするよりもリクエスト後にキャッシュを作って埋めておくほうが良い。
      2. wait_pickup 以降、つまりは shipment request 以降の state コントロールはこのアプリケーションの手を離れる上、想像以上にベンチマークはシビアにチェックしてくる。ならばキャッシュするだけ無意味。素直に返したほうがいい。
      3. done になったら TTL もつけずにキャッシュする。なぜなら以降状態は変化しない
    • 以上のような戦略で組んで、以降ここに手を付けることはない。スコアにも貢献したのでだいたいよかった
    • このとき 13:49 頃。7000 スコアぐらいで低迷していた時期。
  • 以降、N+1 クエリを潰して回る。ここも JOIN でなく IN でよかったような気がしている。この時点で buy がトップヘビーだと思っていたが手がついていない。
  • 8e177660fc6b1ee4279c73d0cd0882694a4dda2e: Ruby 参考実装が rescue でなんでもかんでも握りつぶす実装になっているので逐一エラーを吐かせるように修正。賛否あるとおもうが自分の目から見て『ああ、 Go のコードを引っ張ったんだな』と思うコードであった。作法が違う言語に同系実装を移植する難事は ISUCON 出題の常である。運営陣の苦労を忍ばずに居られない。しかし rescue squash には親を殺されたので許さん。
  • 5f8e382ecb1dbe4e41f852f974e1b9a9420e4c4c: 少し大きめ。各種 GET リクエストの内容を redis にキャッシュさせた。なんと大したエラーも出さず、この後少し修正しただけでベンチマークを突破した。が、スコアには響かず。元から取得系がどうこうというより決済が走らなければならないサービスなので無価値というかなんというか。惜しいことをした。
  • ここからは連作
    • レギュレーションに記載を見て『ユーザーごとに新着一覧を変えて良い』ことに着目する
    • 「バカ正直になんでも返せばいいというもんでもない。売れるものを出すのが正しい」
    • ということでここからいくつかトップから消していく判断になる
    • 9cb1b58ff91f8492548d28a3ceb3dfc244bfcb5b: 自身が出品者な商品をリストしない。ちなみにこのコミットは意図した変更箇所でないところを修正しており壊れている。後ほど意図した挙動が入る。
    • 821d59dac384e62804c7c8064250ac8ae25d7860: SOLD OUT な商品を出さない。本家?メルカリは売却済みも表示されるが、今回は売れた商品はトップビューから消えてもらう。
    • 965827fe0ead1b30d7e3c3772b6a7bea21dc4f31: ユーザー ID ベースで表示するカテゴリーを絞る。ここが悔やまれるが、どうやらユーザーにはお気に入りの商品カテゴリーがあったらしい?それを考慮して出せればよりよい結果につながったのであろうが……ちなみに、事前登録済みの総てのユーザーは自分が買ったことのあるカテゴリを3つから4つ持っている。これで絞っていればバチボコに購買意欲を刺激し、じゃぶじゃぶにイスコインが動いたであろうことは想像に難くない。無念。

以上、やったことでした。他チームメンバーもなにかしていたでしょうがいつもどおりの白金動物園で、僕は他メンバーが何をしていたのかよくわかっていません。チームに貢献してくれていたことだけしっており、それを疑っていないのですべては問題ない。昨年は敗北を喫しだいぶ手痛い気分になったものであるが、今年はなんとかなってよかった。

本戦でまた会いましょう。おしまい。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment