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
1.1k
インターンでハチナイのAPIを高速化しました!
akatsukinewgrad
December 17, 2021
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
2023/1/25_QAテスター meet up!
akatsukinewgrad
0
130
成果発表資料.pdf
akatsukinewgrad
0
2k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
570
正規表現とReDoS.pdf
akatsukinewgrad
0
560
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
610
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
530
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
700
7分でわかるアカツキゲームス
akatsukinewgrad
0
570
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
920
Featured
See All Featured
Optimizing for Happiness
mojombo
379
70k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
How to Ace a Technical Interview
jacobian
279
23k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Scaling GitHub
holman
463
140k
Into the Great Unknown - MozCon
thekraken
40
2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Automating Front-end Workflow
addyosmani
1370
200k
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