「わたし史上、最高のチューニング」に参加してきました

感想

仕様を変えるのが一番負荷にきく
複雑な仕様がDBパフォーマンスに影響を与える
- スロークエリ
- ロングトランザクション
例:購入ボタンが重い
- さまざまなAPIアクセスを1つのトランザクションで
- 全部を同時にやる必要はない
- 購入だけしてあとは非同期でとか
ロングトランザクション対策
- 先にできること後で出来ることを分割する
- 全部同じテーブルだと分割できない
- ダメな設計の上には何を乗せてもダメ
- テーブルを分割
例:検索結果の総件数
- count(*) が重い
  - indexがきかないと遅い
- Googleは昔出してたけど今はない
- 仕様を削るのが一番きく
例:最終ページの番号
- ページングの最終ページが何ページか出す
- 最後のページにアクセスされると重い
- limit offsetのoffsetがでかいと重い
- order逆にしてとるといい

2011年のアプリのチューニング
- diskにアクセスしたら負け
  - ハードディスクなので今のSSDと比べると100倍違う
  - メモリにおさまらないと一時的にdiskに書く
  - 遅くなると処理がたまってコネクション数も増えていく
- 2024年ならお金をつぎ込んで解決できる
  - ただｓどこかで限界が来る
  - お金をかけずに解決する方法もある
  - お金で時間を稼いでその間に対処する
負荷試験をやるといい
- リリース後に発生する問題の9割は分かる
- ゴールを決めてからやらないと何を試験してるのか分からなくなる
- シナリオも考えて負荷を決める
リリース後長期運用してる時に突然悪化することも
- DBのデータが溜まってきて実行計画が変わる
- 使ってほしいindexが使われなくなる

一番早いのはCDNから静的htmlを返すこと
- マウスホバーでpreloadとかするとはやいがいろんなコストとの兼ね合い
2018と2014の違い
- https://speakerdeck.com/mizchi/guang-wochao-erutamefalsehurontoendoakitekutiya
- 初期ロード重いSPAがなくなってきた
- CDN Edge Workerが枯れてきた
- Core Web Vitalsで投資する動機が生まれた
2024のフロントエンドのゴール
- CWV的にLCPを2500ms以内にしたい
- サーバで1.5秒、フロントで1秒くらい
- html/css/jsのロードパースが重い(200msくらい) 1mbとかになると1秒とかかかる
- メディア経過管理画面かなど特性によって目指すところが違う
  - キャッシュなしの初回ロードか
  - 初回ロード後のインタラクションか
チューニング
- とにかく手前でキャッシュに当たって返したい
- リクエストに依存がある回数でウォーターフォールが大きくなってしまう
- 並列にできるならフロント視点では問題はない
  - ただし同時接続数の制限は注意
- LCPの確定までをEdge Cacheに置きたい
  - 部分的に静的サイトにしたい
  - キャッシュパージはとにかく高速にしたい
  - アプリケーション側でキャッシュを管理できると嬉しい
    - でも管理が難しいし事故るリスク
    - フレームワークに押し込みたい