Download to read offline
bootsnapはどれくらい早くなるのか
- 1.
- 2. • ota42y • サーバサイドエンジニア •rubyとかrustとかgoとかC++とか • Twitter、github → ota42y • 技術書典4でマイクロサービス本を出した – https://ota42y.com/blog/2018/04/10/mi croservices_yorozu_book/ 自己紹介
- 3.
- 4. • Shopify/bootsnap – https://github.com/Shopify/bootsnap •Railsアプリの高速化をしてくれるgem – 入れるだけで早くなる – 起動が50%早くなるとの話 – Rails 5.2から標準で入る – Rails 4.2でも動く bootsnap
- 5. • Gemfileに以下を記述 – gem'bootsnap', require: false • config/boot.rbを変更 – bundlerのrequire後にbootsnapを読む – require 'bootsnap/setup' インストール
- 6. • Path Pre-Scanning –ファイルを読み込む際の検索をキャッシュ – ActiveSupportのautoloadも対象 • Compilation caching – YAMLのロード結果をキャッシュする • MessagePackか、ダメならMarshal stream Bootsnapの機能
- 7.
- 8. Path Pre-Scanning • $LOAD_PATHの中身をキャッシュする –requireのたびに全部調べるの遅い – bootsnapで中身をキャッシュする – Kernel#requireとか#loadとかをフックする • よくわかる解説(図がわかりやすい) – https://github.com/Shopify/bootsnap#pa th-pre-scanning
- 9.
- 10. Compilation caching • YAMLの評価結果をキャッシュする –結果のbytecodeを保存する • RubyVM::InstructionSequenceを使ってる – 保存形式はMessagePack • 表現できない構造の場合はMarshal stream • よくわかる解説(図は無い) – https://github.com/Shopify/bootsnap/tre e/86b8b285520299fec913c5f1d63dda4f1 3dbfa25#compilation-caching
- 11.
- 12. 起動時間計測 • Rails runnerで起動して即終了を10回 –Bundle exec rails runner “puts Rails.env” • スクリプトは以下 ruby -rbenchmark -e "ret = Benchmark.measure{ 10.times{ system('DISAB LE_SPRING=1 bundle exec rails runner "puts Rails.env"') } }; puts Benchmark::CAPTION; puts ret" (Springは止めてます)
- 13. 計測結果 app Gem数 normal (秒) bootsnap (秒) 速度向上率 (秒) Rails4.2 242 21.17 9.6 45.35 Rails 5.0 その1 220 19.61 9.2 46.99 Rails 5.0 その2 369 68.90 44.1 64.13 Rails 5.1 184 16.95 8.4 49.62 Rails 5.2 147 14.74 6.7 45.45
- 14. 計測結果 app Gem数 normal (秒) bootsnap (秒) 速度向上率 (秒) Rails4.2 242 21.17 9.6 45.35 Rails 5.0 その1 220 19.61 9.2 46.99 Rails 5.0 その2 369 68.90 44.1 64.13 Rails 5.1 184 16.95 8.4 49.62 Rails 5.2 147 14.74 6.7 45.45 • だいたい50%早くなってる • 元が遅いと向上率が高い？ • Gemが多いと早くなるわけではない – 4.2と5.2で向上率は同じ gemは100個違う – YAMLのせい？
- 15. • Bootsnapは色々キャッシュして早くする – LOAD_PATHやYAMLのパース結果 •だいたい50％早くなる – 便利( ﾟ∀ﾟ)o彡ﾟ • インストールは簡単 – どれもハマらずに入れられた • キャッシュによる不具合は未知数 – まだ使い込んでないので… まとめ
Editor's Notes
- #4 この中に、マイクロサービスアーキテクチャを知ってる人どれくらいいますか？ ありがとうございます、以外と少なくて資料作った会がありました…
- #8 何故我々はマイクロサービスを採用しているのか？という点です
- #9 一番大きな恩恵として、サービス事に別々のサイクルで回せるというのがあります。 例えば課金系といった仕様が複雑で長いQAが必要な機能と、フロントといったユーザの反応を見てどんどん修正を書けていくような機能は、 別々の開発速度で回していきたいわけです。 例えば1つの巨大なシステムであれば、リリースサイクルは1つになり、フロントの変更であっても課金系への影響を考えていかなければなりません。 一方でそれらが別々のマイクロサービスで構成されているのであれば、フロントは小さい変更でどんどんリリースできますし、 課金系はQA期間をしっかり取って開発できます また、影響を局所かできるというのも利点の1つです さっきの例であればユーザが大量に押し寄せてフロント側が重くなっても、 課金系は別のサーバなのでその処理に困る事はないですし、課金系が落ちてても、関係しない機能をそのまま使い続ける…といった事ができます。 その他色々ありますが、詳しくはオライリーのマイクロサービスアーキテクチャという本を読んでください。
- #10 何故我々はマイクロサービスを採用しているのか？という点です
- #11 一番大きな恩恵として、サービス事に別々のサイクルで回せるというのがあります。 例えば課金系といった仕様が複雑で長いQAが必要な機能と、フロントといったユーザの反応を見てどんどん修正を書けていくような機能は、 別々の開発速度で回していきたいわけです。 例えば1つの巨大なシステムであれば、リリースサイクルは1つになり、フロントの変更であっても課金系への影響を考えていかなければなりません。 一方でそれらが別々のマイクロサービスで構成されているのであれば、フロントは小さい変更でどんどんリリースできますし、 課金系はQA期間をしっかり取って開発できます また、影響を局所かできるというのも利点の1つです さっきの例であればユーザが大量に押し寄せてフロント側が重くなっても、 課金系は別のサーバなのでその処理に困る事はないですし、課金系が落ちてても、関係しない機能をそのまま使い続ける…といった事ができます。 その他色々ありますが、詳しくはオライリーのマイクロサービスアーキテクチャという本を読んでください。
- #12 何故我々はマイクロサービスを採用しているのか？という点です
- #13 一番大きな恩恵として、サービス事に別々のサイクルで回せるというのがあります。 例えば課金系といった仕様が複雑で長いQAが必要な機能と、フロントといったユーザの反応を見てどんどん修正を書けていくような機能は、 別々の開発速度で回していきたいわけです。 例えば1つの巨大なシステムであれば、リリースサイクルは1つになり、フロントの変更であっても課金系への影響を考えていかなければなりません。 一方でそれらが別々のマイクロサービスで構成されているのであれば、フロントは小さい変更でどんどんリリースできますし、 課金系はQA期間をしっかり取って開発できます また、影響を局所かできるというのも利点の1つです さっきの例であればユーザが大量に押し寄せてフロント側が重くなっても、 課金系は別のサーバなのでその処理に困る事はないですし、課金系が落ちてても、関係しない機能をそのまま使い続ける…といった事ができます。 その他色々ありますが、詳しくはオライリーのマイクロサービスアーキテクチャという本を読んでください。