表参道.rb #44 〜Ruby/Railsパフォーマンス〜
表参道.rb #44 に参加した。Ruby/Rails パフォーマンスに関するテーマとなり、まつもとゆきひろさんもLTで参加された回である。今回の勉強会のまとめについて書く。
Active Adminの話
Active Adminはフィルタの機能があるが、気軽に使うとパフォーマンス低下の原因となるクエリを吐き出すという話だった。
Airbrake gemの話
AirbrakeというApplication Monitoring Toolを利用するためのgem rbtree がしばらくメンテナンスされていないため、rbtree3 gemが誕生するに至った経緯の発表。Application Monitoringを行うための準備が整えるところまでいくことができたということであった。
ハマったところ
Rails 4.2 -> 5.1へのアップグレードを行う流れの中でActiveRecord::Relation#uniq メソッドの実装が ActiveRecord ネイティブであったものが Enumerable に置き換わり、今まで SELECT DISTINCT による重複レコードを削除する構文をつけてくれた振る舞いがかわるようになった。deprecatedであるメソッドであったが、引き続いてEnumerableをincludeしたことにより、 uniq メソッドそのものは使い続けられたため、パフォーマンス悪化となるような起因でもハマってしまった結果になった内容を発表した。
RailsのCacheつかってますか？
とあるViewで、パフォーマンスの問題があったことから、Page Cache、Fragment CacheなどRails及びgemで実現しているCache機構を利用することでパフォーマンス問題を乗り切っている事例の紹介。Cacheに関してどの程度、パフォーマンス向上に効果があるのか実際に計測した値を紹介していた。
レガシーすぎるRailsアプリを10倍高速化した組織的なカイゼン活動
レスポンス時間の平均1000ms以上となっていたサービスのパフォーマンス改善をチーム全体で取り組んだという発表。株式会社はてなで実践されているPWG (Performance Working Group) という取り組みを参考に、チームでパフォーマンス問題を細かくタスク分割・担当し、レスポンス時間の向上が結果として現れるまでに至った経緯を紹介していた。
ニコニコ立体キャパシティ
https://niconare.nicovideo.jp/embed_works/kn4155
ニコニコ立体での有名なVTuberモデルへのアクセスを開放するにあたり、用意していたインフラ側のnginx process, unicorn processそれぞれの設定値が足りなくなり、nginx process, unicorn processが管理しているアクセスキューの処理が追いつかなくなったため、サービス障害に至ったためパフォーマンス計測を元に適切なインフラ状態の変更(スケールアップ)を行ったという話。factを重要視しながら、実際に動けている実例を知ることができた。
N+1の話
発表者: ビジネスバンクグループ CTO
N+1を抑制するにあたり、includesメソッドを利用することでRailsがよしなにeager_load, pre_loadを切り替えてくれるが、ある日から、includesメソッドがpre_loadではなくeager_loadを利用するようになる。かつ、Active Recordでのポリモーフィック関連付けを利用している場合にeager_loadを利用しているとクエリの実行が行えなくなるため、pre_loadを利用しようという発表であった。具体的なeager_load, pre_loadの話が出てきて大変、わかりやすかった。
Ruby 3x3
Ruby 3.0に向けた高速化・新仕様について発表していた。Ruby 2.6から試験的に搭載されたJITの話になり、MJITやRTLに関して紹介がされていた。
他、型プロファイルに関して、近日行われていた情報処理学会で発表したことも伝えていた。steepを参考のこと。
感想
懇談会で、パフォーマンス以外にも、インフラ管理について詳しく参加者から実例を聞けたり、大変ありがたかった。できる限り参加しつづけていきたい。
記事を読んでいただき、ありがとうございます。うれしいです😊