Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インターンでハチナイのAPIを高速化しました!
Search
akatsukinewgrad
December 17, 2021
0
940
インターンでハチナイのAPIを高速化しました!
akatsukinewgrad
December 17, 2021
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
2023/1/25_QAテスター meet up!
akatsukinewgrad
0
100
成果発表資料.pdf
akatsukinewgrad
0
1.9k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
460
正規表現とReDoS.pdf
akatsukinewgrad
0
470
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
490
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
440
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
560
7分でわかるアカツキゲームス
akatsukinewgrad
0
480
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
740
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
For a Future-Friendly Web
brad_frost
175
9.4k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
RailsConf 2023
tenderlove
29
900
The Pragmatic Product Professional
lauravandoore
31
6.3k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
655
59k
How to Ace a Technical Interview
jacobian
276
23k
Transcript
インターンで ハチナイのAPIを高 速化しました!
自己紹介 ▣ 長谷川 貴斗 ▣ 京都大学大学院 情報学研究科 数理工学専攻 M1(23卒) ▣
先月10月にアカツキの就業型インターン(Ruby on Rails, 八月のシンデレラナイン)に1ヶ月参加 ▣ アカツキインターンでの担当業務 □ 管理画面の開発 □ バリデーションの追加 □ 新規機能開発 □ APIの高速化← ▣ 趣味 □ 喫茶店(モス,ドトール,近所)で読書 □ お絵描き 2
目次 ▣ 何を高速化したいのか ▣ どのくらい遅いのか ▣ どうやって高速化したのか □ 既存のコードの問題点 □
解決策 ▣ どのくらい高速化されたのか ▣ まとめ 3
1. 何を 高速化したいのか 4
高速化したいAPI ▣ 八月のシンデレラナイン ▣ チャプター情報一覧取得API □ ステージは解放済み? □ チャプターはボーナス期間? □
クリアスターはいくつ? などチャプターに関する情報諸々を取ってくるAPI 5
APIが返却するデータ ▣ 返却するデータは大きく分けると □ マスターデータだけで計算できるもの ▪ チャプターはボーナス期間中か □ ユーザーデータが計算に必要なもの ▪
チャプターはクリア済か ▣ マスターデータ □ 選手情報,能力値やスカウトの開催時期など ▣ ユーザーデータ □ ミッションのクリア状況や獲得経験値など 6
2. どのくらい 遅かったのか 7
計測結果 3957ms (Views: 2452.5ms | ActiveRecord: 251.4ms) ▣ Viewsも遅いが,ViewsとActiveRecord以外の部分もかなり時 間かかってる
→Controllerに遅い処理がありそう... 8
大量のpreload ▣ Chapterの関連テーブルを 読み込むところの処理が 1300msほどかかっていた. 9
なぜ遅いか ▣ preload □ クエリの使用回数を減らすために関連づけられたレコードを一括で読み込む □ いわゆるN+1問題を解消するのによく使われる ▣ 遅い理由 □
レコード数が多いものでは20000ほどもあり,preloadするとそれぞれに対 してActiveRecordインスタンスが生成.さらにそれぞれのレコードに対して カラム数分だけActiveRecord::AttributeMethods関連オブジェクトのメ ソッドが呼ばれたりして.生成コストが高くなる つまり,レコード数が多い時preloadはそれなりに重たい. 10
3. どうやって 高速化したのか 11
preloadする回数を減らしたい かといって,ただpreloadをやめるだけではN+1が起きてしまう ▣ マスターデータだけで計算できるデータは,アプデなどでマスターデー タが変更されない限り不変. □ 一回計算した後はキャッシュに持たせておけば,preloadしなくて 済む. ▣ キャッシュはマスターデータが変更されるときに削除
12
APIが返却するデータ(再掲) ▣ 返すデータは大きく分けると □ マスターデータだけで計算できるもの ▪ チャプターはボーナス期間中か □ ユーザーデータに紐づくもの ▪
チャプターはクリア済か ▣ マスターデータ □ 選手情報,能力値やスカウトの開催時期など ▣ ユーザーデータ □ ミッションのクリア状況や獲得経験値など 13
他にも色々 ▣ N+1っぽい問題が起こっている箇所の修正 ▣ キャッシュを作る時だけpreloadが必要だが,毎回preloadしてし まっていた箇所を修正 など... 14
4. どのくらい 高速化されたのか 15
結果 3957ms→1871ms!! 50%程高速化できました. 16
5. まとめ 17
まとめ ▣ 「N+1問題」を起こさないのは基本 ▣ 「ActiveRecordインスタンスの生成コスト」はそれなりに高い ▣ 変更される頻度が低いデータはキャッシュに持たせるという解決策 をとった. - Future
Work ▣ 技術の選定(たとえばErlangだとプロセスをまたがる場合でも内蔵 のオンメモリDBが使えたりするらしい...) ▣ joinとかpluckを使ってActiveRecordインスタンスを生成しない みたいな方法もあったのかも 18