yano3nora · February 25, 2021 14:49 · Jun 7, 2020 · May 15, 2020 · May 11, 2020 · May 11, 2020
diff --git a/rails_performance.md b/rails_performance.md
@@ -192,6 +192,9 @@ New Relic はバックエンドまでしか解析できないので ...
 
 速度検査には [Lighthouse](https://developers.google.com/web/tools/lighthouse/) を利用しており、こちらは Chrome 拡張もあるみたい。
 
+#### Refs
+- [PageSpeed Insightsの点数はどのように計算されているか。100点をとるための条件](https://qiita.com/miyanaga/items/d38124cdd64a1999fed9)
+
 
 ### Sonar - GoogleChrome Extension
 > [今、見ているWebページのW3C標準規格の表示速度が測れるChrome用機能拡張「Sonar」](https://takehora.hatenadiary.jp/entry/2016/05/16/130703)

diff --git a/rails_performance.md b/rails_performance.md
@@ -1,5 +1,5 @@
 ## KNOWLEDGE ##
-- [Webパフォーマンスについて](https://takehora.hatenadiary.jp/entry/2017/12/27/011121)
+- [Webパフォーマンスについて - 「推測するな、計測せよ」のWebパフォーマンスにおける真の意味](https://takehora.hatenadiary.jp/entry/2017/12/27/011121)
 - [Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...](https://havelog.ayumusato.com/develop/performance/e744-performance_metrics.html)
 - [ソーシャルゲームのバックエンドの構成例](https://qiita.com/the40san/items/1ad69ce3be84e82b8f05)
 - [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)

diff --git a/rails_performance.md b/rails_performance.md
@@ -18,6 +18,8 @@
     - [Rails のキャッシュ機構](https://railsguides.jp/caching_with_rails.html)
     - [Rails: パーシャルと`collection:`でN+1クエリを回避してビューを高速化（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_02_05/51346)
 
+### JavaScript
+> https://developers.google.com/web/tools/chrome-devtools/rendering-tools?hl=ja
 
 ### Memory
 > [Ruby 2.6 の改善を自慢したい](https://techlife.cookpad.com/entry/2018/12/27/093914)

diff --git a/rails_performance.md b/rails_performance.md
@@ -188,4 +188,10 @@ New Relic はバックエンドまでしか解析できないので ...
 
 ... などなどフロントエンド周りまで含めたパフォーマンスは Google PageSpeed Insights でチェックし、ローカルでは Chrome DevTools の Performance などでデバッグしていくようにする。
 
-速度検査には [Lighthouse](https://developers.google.com/web/tools/lighthouse/) を利用しており、こちらは Chrome 拡張もあるみたい。
+速度検査には [Lighthouse](https://developers.google.com/web/tools/lighthouse/) を利用しており、こちらは Chrome 拡張もあるみたい。
+
+
+### Sonar - GoogleChrome Extension
+> [今、見ているWebページのW3C標準規格の表示速度が測れるChrome用機能拡張「Sonar」](https://takehora.hatenadiary.jp/entry/2016/05/16/130703)
+
+https://chrome.google.com/webstore/detail/sonar/dibilcjfahbokhiodajibcajcabfjein/related
diff --git a/rails_performance.md b/rails_performance.md
@@ -1,4 +1,5 @@
 ## KNOWLEDGE ##
+- [Webパフォーマンスについて](https://takehora.hatenadiary.jp/entry/2017/12/27/011121)
 - [Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...](https://havelog.ayumusato.com/develop/performance/e744-performance_metrics.html)
 - [ソーシャルゲームのバックエンドの構成例](https://qiita.com/the40san/items/1ad69ce3be84e82b8f05)
 - [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)

diff --git a/rails_performance.md b/rails_performance.md
@@ -1,4 +1,5 @@
 ## KNOWLEDGE ##
+- [Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...](https://havelog.ayumusato.com/develop/performance/e744-performance_metrics.html)
 - [ソーシャルゲームのバックエンドの構成例](https://qiita.com/the40san/items/1ad69ce3be84e82b8f05)
 - [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)
 - [Railsアプリケーションのパフォーマンス改善](https://speakerdeck.com/k0kubun/number-ginzarb?slide=42)

diff --git a/rails_performance.md b/rails_performance.md
@@ -10,6 +10,8 @@
 - [Synthetic Monitoring を活用したグローバルサービスのネットワークレイテンシの測定と改善](https://techlife.cookpad.com/entry/2017/09/21/080000)
 - [最初のバイトまでの時間を最適化して検索ランクを改善する](https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte)
 - [Amazon Elasticsearch ServiceをつかったRDSのスロークエリの集計と監視](https://techlife.cookpad.com/entry/2019/12/27/000000)
+- ActiveRecord
+    - [ActiveRecord の count, length, size の違い](https://www.lanches.co.jp/blog/3199)
 - ActionView
     - [Rails のキャッシュ機構](https://railsguides.jp/caching_with_rails.html)
     - [Rails: パーシャルと`collection:`でN+1クエリを回避してビューを高速化（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_02_05/51346)

diff --git a/rails_performance.md b/rails_performance.md
@@ -66,6 +66,9 @@ User.where(id: user_ids).update_all(processed: true)
 
 ### Rails.cache
 - [Rails.cacheについて](https://morizyun.github.io/ruby/rails-function-cache-fetch-write-delete.html)
+- [Railsでクエリ結果をキャッシュしてDB負荷を軽減する](https://qiita.com/yamashun/items/bf9a3d29de749cf18f2e)
+    - ActiveRecord_Relation を保存したらそりゃ当然毎回クエリ走るわな
+    - to_a して保存したらデータ量は ActiveRecord_Relation より太るわな
 
 ### Ruby Modules, And Gems
 > [Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α](https://blog.kasei-san.com/entry/2016/01/18/101610)

diff --git a/rails_performance.md b/rails_performance.md
@@ -1,4 +1,5 @@
 ## KNOWLEDGE ##
+- [ソーシャルゲームのバックエンドの構成例](https://qiita.com/the40san/items/1ad69ce3be84e82b8f05)
 - [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)
 - [Railsアプリケーションのパフォーマンス改善](https://speakerdeck.com/k0kubun/number-ginzarb?slide=42)
 - [横断的なチームを作ってパフォーマンス改善をやっている話](https://qiita.com/foostan/items/5f5e2be16b009848b76b)
@@ -20,21 +21,24 @@
 メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
 ```rb
-top_1_000_user_ids = []
+conditions = {
+  # ...
+}
+user_ids = []
 
-User.limit(1000).each do |user|
+User.where(conditions).each do |user|
   #
   # - each でクエリが実行される
   #   - SQL 実行のコスト
-  #   - 仮にここで to_a すると 1,000 インスタンス生成 => 高コスト
-  # - user.id の参照により User インスタンスが都度生成される
-  #   - ActiveRecord.new => 高コスト
-  # - user.id を << で追加した後 user が GC で開放されない
+  #   - 仮にここで to_a すると User.where(conditions).count 分の
+  #     ActiveRecord インスタンス生成 => 高コスト
+  # - user.id の参照により User インスタンスが都度生成され
+  #   user.id を << で追加した後 user が GC で開放されない
   #
-  top_1_000_user_ids << user.id
+  user_ids << user.id
   #
-  # user.save は User.count が増える毎にクエリが増えてしまう
-  # いわゆる N + 1 アンチパターンになる
+  # user.save は User.where(conditions).count が増える毎に
+  # クエリが増えてしまういわゆる N + 1 アンチパターンになる
   #
   user.processed = true
   user.save
@@ -45,8 +49,8 @@ end
 # - pluck なので User インスタンスが生成されない ( SQL 発行のみ )
 # - update_all はモデルのコールバック／バリデーションが働かないことに注意
 #
-top_1_000_user_ids = User.limit(1000).pluck(:id)
-User.where(id: top_1_000_user_ids).update_all(processed: true)
+user_ids = User.where(conditions).pluck(:id)
+User.where(id: user_ids).update_all(processed: true)
 ```
 
 - [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)

diff --git a/rails_performance.md b/rails_performance.md
@@ -20,33 +20,33 @@
 メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
 ```rb
-user_ids = []
+top_1_000_user_ids = []
 
-User.where(condition).each do |user|
+User.limit(1000).each do |user|
   #
   # - each でクエリが実行される
   #   - SQL 実行のコスト
-  #   - 仮にここで to_a すると User.where(condition).count 分のインスタンス生成 => 高コスト
+  #   - 仮にここで to_a すると 1,000 インスタンス生成 => 高コスト
   # - user.id の参照により User インスタンスが都度生成される
   #   - ActiveRecord.new => 高コスト
   # - user.id を << で追加した後 user が GC で開放されない
   #
-  user_ids << user.id
-  user.processed = true
-  user.save
+  top_1_000_user_ids << user.id
   #
-  # user.save は User.where(condition).count が増える毎にクエリが増えてしまう
+  # user.save は User.count が増える毎にクエリが増えてしまう
   # いわゆる N + 1 アンチパターンになる
   #
+  user.processed = true
+  user.save
 end
 
 #
 # - pluck, update_all で User が増えても 2 回のクエリ
 # - pluck なので User インスタンスが生成されない ( SQL 発行のみ )
 # - update_all はモデルのコールバック／バリデーションが働かないことに注意
 #
-user_ids = User.where(condition).pluck(:id)
-User.where(id: user_ids).update_all(processed: true)
+top_1_000_user_ids = User.limit(1000).pluck(:id)
+User.where(id: top_1_000_user_ids).update_all(processed: true)
 ```
 
 - [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)
@@ -66,6 +66,13 @@ User.where(id: user_ids).update_all(processed: true)
 ### Ruby Modules, And Gems
 > [Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α](https://blog.kasei-san.com/entry/2016/01/18/101610)
 
+- [Rails: N+1クエリを「バッチング」で解決するBatchLoader gem（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_09_07/45077)
+    - バッチング ( 非同期でクエリを遅延評価 + キャッシュ ) 手法
+    - GraphQL のような「どんなフィールドの問い合わせがあるかわからない」API との相性よきらしい
+    - このバッチング + GraphQL の組み合わせなら graphql-batch というデファスタな gem もある
+        - https://github.com/Shopify/graphql-batch
+- [EnumeratorとEnumerator::Lazyの違い](https://qiita.com/gam0022/items/8acfc0c674b96060c03f)
+    - 遅延評価を使うのが賢そう
 - [Rails向け高機能カウンタキャッシュ gem ‘counter_culture’ README（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_08_03/43698)
 - [flyerhzm/bullet - github.com](https://github.com/flyerhzm/bullet)
     - N + 1 検証 gem

diff --git a/rails_performance.md b/rails_performance.md
@@ -20,33 +20,33 @@
 メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
 ```rb
-top_1_000_user_ids = []
+user_ids = []
 
-User.limit(1000).each do |user|
+User.where(condition).each do |user|
   #
   # - each でクエリが実行される
   #   - SQL 実行のコスト
-  #   - 仮にここで to_a すると 1,000 インスタンス生成 => 高コスト
+  #   - 仮にここで to_a すると User.where(condition).count 分のインスタンス生成 => 高コスト
   # - user.id の参照により User インスタンスが都度生成される
   #   - ActiveRecord.new => 高コスト
   # - user.id を << で追加した後 user が GC で開放されない
   #
-  top_1_000_user_ids << user.id
+  user_ids << user.id
+  user.processed = true
+  user.save
   #
-  # user.save は User.count が増える毎にクエリが増えてしまう
+  # user.save は User.where(condition).count が増える毎にクエリが増えてしまう
   # いわゆる N + 1 アンチパターンになる
   #
-  user.processed = true
-  user.save
 end
 
 #
 # - pluck, update_all で User が増えても 2 回のクエリ
 # - pluck なので User インスタンスが生成されない ( SQL 発行のみ )
 # - update_all はモデルのコールバック／バリデーションが働かないことに注意
 #
-top_1_000_user_ids = User.limit(1000).pluck(:id)
-User.where(id: top_1_000_user_ids).update_all(processed: true)
+user_ids = User.where(condition).pluck(:id)
+User.where(id: user_ids).update_all(processed: true)
 ```
 
 - [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)

diff --git a/rails_performance.md b/rails_performance.md
@@ -52,6 +52,7 @@ User.where(id: top_1_000_user_ids).update_all(processed: true)
 - [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)
 - [メモリを意識したRubyプログラミング（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_30/48130)
 - [Rails: Active Record 5.2のメモリ肥大化を探る（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_07_11/58710)
+- [Railsパフォーマンスのヒント](https://medium.com/@andresakata/rails-performance-tips-494824a7ded7)
 
 
 ------

diff --git a/rails_performance.md b/rails_performance.md
@@ -2,6 +2,7 @@
 - [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)
 - [Railsアプリケーションのパフォーマンス改善](https://speakerdeck.com/k0kubun/number-ginzarb?slide=42)
 - [横断的なチームを作ってパフォーマンス改善をやっている話](https://qiita.com/foostan/items/5f5e2be16b009848b76b)
+- [マネーフォワード社内PRに見られるRubyの書き方について](https://moneyforward.com/engineers_blog/2019/08/21/ruby-code-8/)
 - [AWS クックパッドの運用事例](https://www.slideshare.net/satoship/aws-11650261)
 - [Varnish入門と仕組み](https://qiita.com/koudaiii/items/6a0efa024842cd48e2fb)
 - [Varnish自前運用からFastly移行の際に調べたこと](https://techblog.lclco.com/entry/2018/12/26/170000)

diff --git a/rails_performance.md b/rails_performance.md
@@ -18,6 +18,36 @@
 
 メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
+```rb
+top_1_000_user_ids = []
+
+User.limit(1000).each do |user|
+  #
+  # - each でクエリが実行される
+  #   - SQL 実行のコスト
+  #   - 仮にここで to_a すると 1,000 インスタンス生成 => 高コスト
+  # - user.id の参照により User インスタンスが都度生成される
+  #   - ActiveRecord.new => 高コスト
+  # - user.id を << で追加した後 user が GC で開放されない
+  #
+  top_1_000_user_ids << user.id
+  #
+  # user.save は User.count が増える毎にクエリが増えてしまう
+  # いわゆる N + 1 アンチパターンになる
+  #
+  user.processed = true
+  user.save
+end
+
+#
+# - pluck, update_all で User が増えても 2 回のクエリ
+# - pluck なので User インスタンスが生成されない ( SQL 発行のみ )
+# - update_all はモデルのコールバック／バリデーションが働かないことに注意
+#
+top_1_000_user_ids = User.limit(1000).pluck(:id)
+User.where(id: top_1_000_user_ids).update_all(processed: true)
+```
+
 - [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)
 - [メモリを意識したRubyプログラミング（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_30/48130)
 - [Rails: Active Record 5.2のメモリ肥大化を探る（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_07_11/58710)

diff --git a/rails_performance.md b/rails_performance.md
@@ -14,9 +14,11 @@
 
 
 ### Memory
+> [Ruby 2.6 の改善を自慢したい](https://techlife.cookpad.com/entry/2018/12/27/093914)
+
 メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
-- [Ruby 2.6 の改善を自慢したい](https://techlife.cookpad.com/entry/2018/12/27/093914)
+- [ActiveRecordデータ処理アンチパターン](https://speakerdeck.com/toshimaru/active-record-anti-patterns)
 - [メモリを意識したRubyプログラミング（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_30/48130)
 - [Rails: Active Record 5.2のメモリ肥大化を探る（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_07_11/58710)
 

diff --git a/rails_performance.md b/rails_performance.md
@@ -14,16 +14,21 @@
 
 
 ### Memory
-メモリを食う大きめのデータを取り回すと重くなる説ある。
+メモリを食う大きめのデータを取り回すと重くなる説ある。Ruby は「全てがオブジェクト」なためメモリ消費が多め、2.2 以前は GC の性能にも問題が合って顕著に遅かったみたい。
 
+- [Ruby 2.6 の改善を自慢したい](https://techlife.cookpad.com/entry/2018/12/27/093914)
 - [メモリを意識したRubyプログラミング（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_30/48130)
+- [Rails: Active Record 5.2のメモリ肥大化を探る（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_07_11/58710)
 
 
 ------
 
 
 ## TOOLS ##
 
+### Rails.cache
+- [Rails.cacheについて](https://morizyun.github.io/ruby/rails-function-cache-fetch-write-delete.html)
+
 ### Ruby Modules, And Gems
 > [Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α](https://blog.kasei-san.com/entry/2016/01/18/101610)
 

diff --git a/rails_performance.md b/rails_performance.md
@@ -13,6 +13,12 @@
     - [Rails: パーシャルと`collection:`でN+1クエリを回避してビューを高速化（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_02_05/51346)
 
 
+### Memory
+メモリを食う大きめのデータを取り回すと重くなる説ある。
+
+- [メモリを意識したRubyプログラミング（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_30/48130)
+
+
 ------
 
 

diff --git a/rails_performance.md b/rails_performance.md
@@ -1,4 +1,5 @@
 ## KNOWLEDGE ##
+- [Railsでパフォーマンスを低下させないために気をつけること](https://qiita.com/nikadon/items/9e6431f5a7b2b8798113)
 - [Railsアプリケーションのパフォーマンス改善](https://speakerdeck.com/k0kubun/number-ginzarb?slide=42)
 - [横断的なチームを作ってパフォーマンス改善をやっている話](https://qiita.com/foostan/items/5f5e2be16b009848b76b)
 - [AWS クックパッドの運用事例](https://www.slideshare.net/satoship/aws-11650261)

diff --git a/rails_performance.md b/rails_performance.md
@@ -20,6 +20,7 @@
 ### Ruby Modules, And Gems
 > [Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α](https://blog.kasei-san.com/entry/2016/01/18/101610)
 
+- [Rails向け高機能カウンタキャッシュ gem ‘counter_culture’ README（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_08_03/43698)
 - [flyerhzm/bullet - github.com](https://github.com/flyerhzm/bullet)
     - N + 1 検証 gem
     - 動的解析、アクション実行時にログで警告を出力

diff --git a/rails_performance.md b/rails_performance.md
@@ -52,7 +52,7 @@
 
 ```rb
 articles = Article.sample 3
-articles.first.author.loaded?  # false
+articles.first.association(:author).loaded?  # false
 ```
 
 ログなんかで全体的に確認したいなら `ActiveSupport::Notifications` の `#subscribed` の第三引数にクエリ実行可能性のあるブロックを渡すような作りにするとよい。

diff --git a/rails_performance.md b/rails_performance.md
@@ -44,6 +44,59 @@
     - `Benchmark.benchmark do ... end` でブロック内のベンチマークが取れる
     - 修正前後の比較などに
 
+### Rails
+#### Detection Eager Load
+> [Rails: ActiveRecord関連付けのpreload/eager-loadをテストする2つの方法（翻訳）](https://techracho.bpsinc.jp/hachi8833/2017_11_09/47618)
+
+さくっと確認するなら `binding.pry` で止めて `ActiveRecord::Associations::CollectionProxy` の `#loaded?` で確認。
+
+```rb
+articles = Article.sample 3
+articles.first.author.loaded?  # false
+```
+
+ログなんかで全体的に確認したいなら `ActiveSupport::Notifications` の `#subscribed` の第三引数にクエリ実行可能性のあるブロックを渡すような作りにするとよい。
+
+```rb
+require 'rails_helper'
+
+RSpec.describe Order, type: :model do
+  specify "#average_line_gross_price_today eager loading" do
+    o = Order.new()
+    o.order_lines.build
+    o.order_lines.build
+    o.save!
+
+    count = count_queries { Order.average_line_gross_price_today }
+    expect(count).to eq(2)
+    # 2 を期待しつつ、実際の SQL トリガ回数は count_queries 内の
+    # ActiveSupport::Notifications.subscribed で購読した
+    # sql.active_record イベントのカウント総数が評価されるテスト
+  end
+
+  private
+
+  def count_queries &block
+    count = 0
+
+    counter_f = ->(name, started, finished, unique_id, payload) {
+      unless %w[ CACHE SCHEMA ].include?(payload[:name])
+        count += 1
+      end
+    }
+
+    ActiveSupport::Notifications.subscribed(
+      counter_f,
+      'sql.active_record',
+      &block
+    )
+
+    count
+  end
+end
+```
+
+
 ### New Relic
 > [newrelic.com](https://newrelic.com/)  
 > [New Relic ドキュメント](https://newrelic.degica.com/docs) - 日本代理店の非公式ドキュメント

diff --git a/rails_performance.md b/rails_performance.md
@@ -17,7 +17,7 @@
 
 ## TOOLS ##
 
-### Rails
+### Ruby Modules, And Gems
 > [Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α](https://blog.kasei-san.com/entry/2016/01/18/101610)
 
 - [flyerhzm/bullet - github.com](https://github.com/flyerhzm/bullet)
@@ -45,7 +45,8 @@
     - 修正前後の比較などに
 
 ### New Relic
-> [newrelic.com](https://newrelic.com/)
+> [newrelic.com](https://newrelic.com/)  
+> [New Relic ドキュメント](https://newrelic.degica.com/docs) - 日本代理店の非公式ドキュメント
 
 WEB アプリケーションのパフォーマンス解析 SaaS 。Controller#action の以下のようなパフォーマンス指標を監視可能。詳細は別メモ参照。
 
@@ -54,10 +55,6 @@ WEB アプリケーションのパフォーマンス解析 SaaS 。Controller#ac
 - DB スロークエリ
 - Redis などのバックエンド通信
 
-#### Refs
-日本の代理店 Degica 社がドキュメントまとめてくれてる。
-
-- [トランザクションについて](https://newrelic.degica.com/docs/apm/transactions)
 
 ### Google PageSpeed Insights
 > [Google PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/)

diff --git a/rails_performance.md b/rails_performance.md
@@ -8,6 +8,7 @@
 - [最初のバイトまでの時間を最適化して検索ランクを改善する](https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte)
 - [Amazon Elasticsearch ServiceをつかったRDSのスロークエリの集計と監視](https://techlife.cookpad.com/entry/2019/12/27/000000)
 - ActionView
+    - [Rails のキャッシュ機構](https://railsguides.jp/caching_with_rails.html)
     - [Rails: パーシャルと`collection:`でN+1クエリを回避してビューを高速化（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_02_05/51346)
 
 

diff --git a/rails_performance.md b/rails_performance.md
@@ -46,7 +46,7 @@
 ### New Relic
 > [newrelic.com](https://newrelic.com/)
 
-WEB アプリケーションのパフォーマンス解析 SaaS 。Controller#action の以下のようなパフォーマンス指標を監視可能。
+WEB アプリケーションのパフォーマンス解析 SaaS 。Controller#action の以下のようなパフォーマンス指標を監視可能。詳細は別メモ参照。
 
 - レスポンスタイム ( TTFB )
 - ビューレンダリング

diff --git a/rails_performance.md b/rails_performance.md
@@ -1,4 +1,5 @@
 ## KNOWLEDGE ##
+- [Railsアプリケーションのパフォーマンス改善](https://speakerdeck.com/k0kubun/number-ginzarb?slide=42)
 - [横断的なチームを作ってパフォーマンス改善をやっている話](https://qiita.com/foostan/items/5f5e2be16b009848b76b)
 - [AWS クックパッドの運用事例](https://www.slideshare.net/satoship/aws-11650261)
 - [Varnish入門と仕組み](https://qiita.com/koudaiii/items/6a0efa024842cd48e2fb)

diff --git a/rails_performance.md b/rails_performance.md
@@ -6,6 +6,8 @@
 - [Synthetic Monitoring を活用したグローバルサービスのネットワークレイテンシの測定と改善](https://techlife.cookpad.com/entry/2017/09/21/080000)
 - [最初のバイトまでの時間を最適化して検索ランクを改善する](https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte)
 - [Amazon Elasticsearch ServiceをつかったRDSのスロークエリの集計と監視](https://techlife.cookpad.com/entry/2019/12/27/000000)
+- ActionView
+    - [Rails: パーシャルと`collection:`でN+1クエリを回避してビューを高速化（翻訳）](https://techracho.bpsinc.jp/hachi8833/2018_02_05/51346)
 
 
 ------

diff --git a/rails_performance.md b/rails_performance.md
@@ -5,6 +5,7 @@
 - [Varnish自前運用からFastly移行の際に調べたこと](https://techblog.lclco.com/entry/2018/12/26/170000)
 - [Synthetic Monitoring を活用したグローバルサービスのネットワークレイテンシの測定と改善](https://techlife.cookpad.com/entry/2017/09/21/080000)
 - [最初のバイトまでの時間を最適化して検索ランクを改善する](https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte)
+- [Amazon Elasticsearch ServiceをつかったRDSのスロークエリの集計と監視](https://techlife.cookpad.com/entry/2019/12/27/000000)
 
 
 ------

diff --git a/rails_performance.md b/rails_performance.md
@@ -27,7 +27,7 @@
 - [kainosnoema/rack-lineprof - github.com](https://github.com/kainosnoema/rack-lineprof)
     - Rack アプリ向けの行単位プロファイラ
     - どの処理に時間がかかっているか見つけやすい
-    - `?lineprof=users_controller.rb` などで対象ファイルを指定可能
+    - `?lineprof=users_controller.rb` などで対象ファイルを指定すると標準出力にプロファイリング結果が出てくる
     - [ref](https://k0kubun.hatenablog.com/entry/2014/09/22/020942)
 - [MiniProfiler/rack-mini-profiler - github.com](https://github.com/MiniProfiler/rack-mini-profiler)
     - ページごとのプロファイラ

diff --git a/rails_performance.md b/rails_performance.md
@@ -27,6 +27,7 @@
 - [kainosnoema/rack-lineprof - github.com](https://github.com/kainosnoema/rack-lineprof)
     - Rack アプリ向けの行単位プロファイラ
     - どの処理に時間がかかっているか見つけやすい
+    - `?lineprof=users_controller.rb` などで対象ファイルを指定可能
     - [ref](https://k0kubun.hatenablog.com/entry/2014/09/22/020942)
 - [MiniProfiler/rack-mini-profiler - github.com](https://github.com/MiniProfiler/rack-mini-profiler)
     - ページごとのプロファイラ

diff --git a/rails_performance.md b/rails_performance.md
@@ -31,7 +31,8 @@
 - [MiniProfiler/rack-mini-profiler - github.com](https://github.com/MiniProfiler/rack-mini-profiler)
     - ページごとのプロファイラ
     - ページの左上に処理にかかった時間などプロファイリング結果を出してくれる
-    - [ref](https://qiita.com/kadoppe/items/6ce36a21d829585dd319)
+    - `?pp=enable` `?pp=disable` で表示切替も可能
+        - [ref](https://qiita.com/kadoppe/items/6ce36a21d829585dd319)
 - [module Benchmark](http://docs.ruby-lang.org/ja/2.3.0/class/Benchmark.html)
     - Ruby 組み込みクラス
     - `Benchmark.benchmark do ... end` でブロック内のベンチマークが取れる
No results found