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
140
成果発表資料.pdf
akatsukinewgrad
0
2.1k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
580
正規表現とReDoS.pdf
akatsukinewgrad
0
560
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
620
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
540
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
710
7分でわかるアカツキゲームス
akatsukinewgrad
0
580
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
940
Featured
See All Featured
Faster Mobile Websites
deanohume
310
31k
We Have a Design System, Now What?
morganepeng
53
7.8k
A designer walks into a library…
pauljervisheath
209
24k
KATA
mclloyd
32
15k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Facilitating Awesome Meetings
lara
56
6.6k
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