---
# System prepended metadata

title: isucon11q

---

# isucon11q

* リポジトリ: https://github.com/ShotaKitazawa/isucon11q-20220505

## 初期スコア: 2000 点程度

## index を張った: 16000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/6bb62823957e4a5e8fda1ef6164803c52c1af786)

pt-query-digest 見ると明らかにインデックスが効かせられそうなクエリが上位に来るので、すぐ見つかる

## postIsucondition の bulk insert: 18000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/67cd1297b4289b5bd6aeb2fba96240704c8b938f)

pprof で postIsucondition に一番時間がかかっていたし、今回は Write heavy な問題なので、ひとまずここから着手

## image を DB 管理からファイル管理に変更: 18000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/pull/1)

Image の取得に conditional get を効かせたかったのでやった。
(nginx で `etag: on` にすればいいだけなので image 外だしは必要なかった可能性が大)

## drop rate を 0.5 にした等: 18000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/compare/3256827da8743edf32d7dd42f84f8a6b64f587ee...10a86a50a16e907e496b6d1bfb6a96a851e10e0d)

## getCondition にて SQL で limit を使えるようにした: 18000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/305d49579bf10bf9d518090d0de1a205eee7f08e)
    * サーバ上にしかない 1_InitData.sql を新規スキーマに対応するよう修正
    * MySQL ユーザの追加もした
      ```mysql
      CREATE USER isucon@'%' IDENTIFIED BY 'isucon';
      GRANT ALL PRIVILEGES ON *.* TO isucon@'%';
      ```

getCondition 内で「全件 SELECT → for → slice に対して limit 処理」という無駄処理をやってたので、改善した

## 複数台構成: 57700 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/compare/7d28f8fbdbbd92f8bc1ab6c66e32042a36758ccf...60309030ae3ac472d7bff4d66f8fe2f9e5ea4bc4)

以下のような構成にした

* 1台目: ユーザの通信を受ける nginx, app
    * CPU Usage: isucondition が 200%
* 2台目: post Isucondition を受ける app (nginx は無し)
    * CPU Usage: isucondition が 40% (うち sys 10%)
* 3台目: DB のみ
    * CPU Usage: MySQL が 90% (うち sys 10%)

## getTrend 改善: 110000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/a2d7f943adc5174d0fec766e6a77e20cc621e8fe)

getTrend の無駄に LIMIT を取らないで実行してるクエリを修正しただけ

## dropProbability の廃止: 110000 程度

おそらく、post が増えたがその分別エンドポイントの負荷が高くなった

## getTrend を singleflight に: 65000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/cb10e811e77a84730158f907bb79cc98b74357d7)

[当日マニュアル](https://github.com/isucon/isucon11-qualify/blob/main/docs/manual.md#%E3%82%B3%E3%83%B3%E3%83%87%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%8F%8D%E6%98%A0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6) よりキャッシュは許容されているので、 singleflight 化

getTrend が劇的に改善 → ユーザの増加率が上昇 → postIsucondition の件数が増加 → 別エンドポイントの負荷が高くなった

## postIsucondition の bulk insert ②: 200000 程度

* [差分](https://github.com/ShotaKitazawa/isucon11q-20220505/commit/cd2eadbc4fd4f1e37c1d3e9abd0fd6bb9d7159cd)

[当日マニュアル](https://github.com/isucon/isucon11-qualify/blob/main/docs/manual.md#%E3%82%B3%E3%83%B3%E3%83%87%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%8F%8D%E6%98%A0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6) より postIsucondition の反映が遅れることが許容されているので、複数 postIsucondition リクエストをまとめて 1 query で insert するようにした