**优化--后端**: 计数缓存counter_cache; rack-mini-profiler(2300) ; bullet(5000✨):侦测N+1query...

rack-mini-profiler 这个 gem,可以永远显示网页的加载时间。（2300✨）开发环境和产品环境都可以用。（生成非常详细的报告）

development环境,直接使用gem 'rack-mini-profiler'
production环境，
1. gem 'rack-mini-profiler', require: false ，让
2. 然后运行bundle exec rails g rack_profiler:install，这样在开发环境下也可以使用。

以下服务可以收集网站实际营运的数据，找出哪些部分是效能不好的地方加以改善：

New Relic
Skylight
Scout

后端效能提速的方向

对后端来说，一个方向是提供 Rails 和 Ruby 代码的效能，一个方向是提供数据库方面的效能。

主要是query查询SQL的效能提升空间大。

1. 避免N + 1的query

includes()：让你存取Post模型的关联对象user的属性，却不会产生额外的查询语句。用于简单的join的执行速度的改进。

可以嵌套，可以指定多个关系，可以附加where（具体看API）

对关联，可以使用：

def index
　@posts = Post.includes(:user).page(params[:page])
end

SELECT "posts".* FROM "posts" LIMIT ? [["LIMIT", 2]]
SELECT "users".* FROM "users" WHERE "users"."id" IN (1, 5)

def show
@post = Post.find(params[:id])
@comments = @post.comments.includes(:user)
end

多个关联，和加嵌套：

def index
@posts = Post.includes(:user, :liked_users, {:comments => :user}).page(params[:page])
end

{:comments => :user}是因为post关联comments，下一层comments关联了user。

加上条件查询：

可以在include()后面直接加上where()。

使用scope(name, body, &block),预先设置查询的rails语法. 就是一个类方法。返回一个ActiveRecord::Relation。

可以把返回结果当array，用Enumerable的方法。

scope可以连接scope或类方法。

例子：

如果希望在index页面只显示公开的comments，即comment的status属性的值是public,
同时不希望产生N+1query,

改MVC模型：

则在Models/post.rb中添加：

has_many :comments, -> { where( status: "public")}, class_name: "Comment"

在Controllers/posts_controller.rb中的index方法中修改：

{:comment => :user}改为{:visible_comment => :user}

在views/posts/index.html.erb中修改：

post.comments为post.visble_comments

Bullet在开发时协助侦测 N+1 queries

gem https://github.com/flyerhzm/bullet （5500✨）

注意：在配置时，注释掉不需要的gem的功能。然后打开页面，如果遇到N+1 query就会弹出窗口。

Rails.application.configure do

config.after_initialize do
Bullet.enable = true
Bullet.alert = true 　　　　#弹出提示框。
Bullet.bullet_logger = true
Bullet.console = true
Bullet.rails_logger = true #在terminal显示提升
Bullet.add_footer = true #在当前页角显示提升
end

end

activerecord内存的优化：

1.不要用all,可以使用分页的gem。 will_paginate 或 kaminari

2. 真要捞全部数据，使用批处理方法 find_each ，find_in_batches。

例子：在数据库内新增一个字段，并赋值。

db/migrate/2017XXXXXXXXXX_add_date_to_posts.rb

   class AddDateToPosts < ActiveRecord::Migration[5.1]def change
+      add_column :posts, :date, :date
+
+      Post.find_each do |post|
+        post.date = post.created_at.to_date
+        post.save( :validate => false )
+      endend
   end

3. Preload技术，使用复杂的语法糖（复杂的Sql）一次性从数据库捞出所有想要的数据，存入了内存。

对不同的需求，使用不同的调用方法从内存中获取记录。

def show
@post = Post.find(params[:id])

if current_user
all_comments = @post.comments.where("status = ? OR (status = ? AND user_id = ?)","public", "private", current_user.id).includes(:user)
@comments = all_comments.select{ |x| x.status == "public" }
@my_comments = all_comments.select{ |x| x.status == "private" }
else
@comments = @post.comments.visible.includes(:user)
end
end

对应的查询语法：

SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = ? AND (status = 'private' OR (status = 'public' AND user_id = 1)) [["post_id", 1]]

4. count和size: size可以返回已经加载的collection的数量，如果没有加载则调用count的sql方法。所以在collection中都用size，

总结：sql优化，是优化已经实现的功能。不可能有先见之明。

5. pluck()选择字段，在只需要记录的部分字段的情况下使用的。可以节省内存。直接返回一个数组。

Post.all.map{|x| x.id } 是先捞出输出生成ActiveRecord，然后再生成数组

Post.pluck(:id)直接捞需要的数据生成数组，不会生成ActiveRecord。

pluck()和select()用有区别，select()有2个用法：

1。select()返回的是activerecord对象集合。

⚠️比较好的写法是: Post.select(:id, :column_name, ...)这样会带上id。否则返回的activerecord对象不带id索引.

2。select{|x| 条件 } ：这是另一种用法，返回数组对象集合。

数据库的sql优化：

使用复杂的sql语法，进行如报表之类的计算。因为在数据库中的计算，比调出数据再用Ruby计算的速度快很多。

因此, 如COUNT, MAX, MIN, SUM, AVG等都直接用数据库计算比较好。

对应的Rails语法糖：count(), maximum(), minimum(), sum(), average().

例子：

SQL:

SELECT posts.*, COUNT(subscriptions.id) as subscriptions_count FROM "posts" INNER JOIN "subscriptions" ON "subscriptions"."post_id" = "posts"."id" GROUP BY posts.id

Rails语法糖：

Post.joins(:subscriptions).group("posts.id").select("posts.*, count(subscriptions.id) as subscriptions_count")

group()和select()可以换顺序，不影响SQL。

解释：group by 用于集合计算的函数并分组显示结果。

使用计数缓存counter_cache

比如以前没有使用counter_cache，现在已经有了一堆相关的记录。可以：

1. rails g migration AddXxxToXxxs xxx:type，然后在db/migrate/XXX_add_xxx中添加：

2. add_column :users, :posts_count, :integer, default: 0, null: false

User.pluck(:id).each {|id| User.reset_counters(id, :posts)}

⚠️：reset_counters(id, *counters, touch: nil)

3. 在posts.rb中加上 belongs_to :user, counter_cache: true

4. 在user的posts数量发生变化时，可以更新它使用update_counters(id, counters, touch: nil)

User.update_counters(user.id, posts_count: 1 )

⚠️：id, 想要更新一个counter的对象的id或者，一数组ids

⚠️：counters是hash, 要更新的字段的名字做key，字段的值是value.

⚠️：如果设置选项touch：true代表更新时间戳updated_at。

Rails 内建的 Counter Cache 功能比较简单，如果你需要更多功能，请参考 https://github.com/magnusvk/counter_culture 这个 gem。

小结论：什么时候用逆规范化做优化？

如果不常显示该数据，可以用纯 SQL 的方式来解决。但是如果需要经常显示该数据，就可以考虑用逆规范化的方式，将数据缓存下来。这样效能可以更好。但是缺点就是需要维护该数据的正确性，要写的 Ruby 代码也比较多。

考量：读取的频率 v.s. 更新缓存数据的成本。

比如：点赞数，关注数。无需时时更新。可以用逆规范化。

改进render partial的效能（比较小）

<% @posts.each do |post| %>
<%= render partial: "post", locals: {post: post}%>
<% end %>

改为用a collection of partials:
<%= render partial: "post", collection: @posts, as: :post%>

数据库索引（加快查询速度，但会占内存）

add_index(table_name, column_name, options={}) ,各种例子的用法见API

以下需要加上index:

外部键(Foreign key)
会被排序的字段(被放在order方法中)
会被查询的字段(被放在where方法中)
会被group的字段(被放在group方法中)
order("id desc")等同于created_at desc，效能更好。这是因为id是integer格式，而created_at是datetime格式。因此⚠️index对不同的数据格式的效率也不同。

效率上Boolean > integer > String > Date > Datetime