Rails Impressionist 进行昂贵的查询答案

【问题标题】：Rails Impressionist making expensive queriesRails Impressionist 进行昂贵的查询
【发布时间】：2023-03-19 03:54:01
【问题描述】：

我正在使用 charlotte-ruby/impressionist 来跟踪我的 rails 应用程序中的印象。

我有一个非常简单的实现，类似于快速入门指南中显示的内容。有效： - 控制器：印象派动作：[:show, :index] - 查看：@post.impressionist_count - 型号：is_impressionable

我今天遇到了一些数据库排队问题，并在检查 Heroku Postgres 中昂贵的查询时发现了以下问题：

我立即从我的控制器/视图中删除了印象派（在 14:30），您可以看到它如何影响性能：

有没有人遇到过印象派宝石的类似问题？从数据库的角度来看，为什么它如此昂贵？

编辑：

以下是添加的索引：

  add_index "impressions", ["controller_name", "action_name", "ip_address"], name: "controlleraction_ip_index", using: :btree
  add_index "impressions", ["controller_name", "action_name", "request_hash"], name: "controlleraction_request_index", using: :btree
  add_index "impressions", ["controller_name", "action_name", "session_hash"], name: "controlleraction_session_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "ip_address"], name: "poly_ip_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "request_hash"], name: "poly_request_index", using: :btree
  add_index "impressions", ["impressionable_type", "impressionable_id", "session_hash"], name: "poly_session_index", using: :btree
  add_index "impressions", ["impressionable_type", "message", "impressionable_id"], name: "impressionable_type_message_index", using: :btree
  add_index "impressions", ["user_id"], name: "index_impressions_on_user_id", using: :btree

【问题讨论】：

我在安装impressionist gem 时注意到的是它在数据库中创建的大量索引。我把它们都去掉了，因为我认为你很少使用的表中不需要索引。也许这就是你造成这种情况的原因。
很难从发布的数据中得出确切的结论（除了您得出的高级别的结论，即 印象派 gem 是可能的原因）...是否有任何索引在适合where 子句条件的impressions 表的数据库中？是否有一堆 selects 为给定的页面加载而聚集在一起？
为问题添加了索引。这个不是太熟悉。有什么不正常的地方吗？
从抽象出到 Ruby DSL 中的索引，很难说是哪一种……索引对性能有帮助吗？最能说明问题的是获取长时间运行的SELECT 查询的查询计划，并查看是否缺少索引。
@Iceman 见stackoverflow.com/questions/27862701/…。你有什么建议吗？

标签： ruby-on-rails database postgresql heroku impressions

【解决方案1】：

@Ken Hampson - 感谢您的推荐。寻找长期运行的 SELECT 查询确定了另一个需要的索引。一旦添加，POOF，一切都变得更好了。很奇怪，这个问题在网站运行了几个月后才出现。印象一定达到了压垮骆驼的规模。感谢您的帮助！

对于因数据库查询（在 Heroku 上）而遇到性能下降的类似问题的任何人，转到 https://postgres.heroku.com/databases/your-database-name 并查看“昂贵的查询”表是找出您可能错过索引的好方法.

【讨论】：

发现这个太棒了。昨天有一个非常相似的经历......几个月的稳定响应时间和 BOOM，20000 毫秒 +

【解决方案2】：

大型项目（数千/百万用户）的最佳解决方案是出气筒 gem，请通过文档进行集成：punching_bag

当每个请求都创建一个新记录时，就会出现主要问题，这会给数据库带来巨大的负载。宝石印象派在这里失败了。沙袋也能创造记录，但它有一个救援任务：

每月/每周为此 rake 任务安排一次 cron 作业，以减少（对记录进行分组）记录数量，而不会影响页面浏览量，这可以通过简单的 - @post.hits 找到。这是 rake 任务：rake punching_bag:combine[by_hour_after,by_day_after,by_month_after,by_year_after]

【讨论】：