Jbuilder Rails缓存速度较慢

Question

我试图使用带有集合的缓存(使用多个解决方案)问题是,当我尝试缓存响应变慢时,请考虑下面的集合示例,为其中的每个项目呈现2个部分(大约25个项目)

json.data do
  json.array! @organizations do |organization|
    json.partial! 'api/v1/organizations/organization', organization: organization
    json.partial! 'api/v1/organizations/links', organization: organization
  end
end

没有缓存,平均响应时间约为38毫秒(平均)

现在有了缓存

json.data do
  json.array! @organizations do |organization|
    json.cache! organization do
      json.partial! 'api/v1/organizations/organization', organization: organization
      json.partial! 'api/v1/organizations/links', organization: organization
    end
  end
end

使用jbuilder默认缓存和dalli存储已正确安装和配置(我可以验证没有缓存未命中)

平均响应约为59毫秒(平均)

使用Cache Digest上的语法

json.data do
  json.cache! @organizations do
    json.partial! 'api/v1/organizations/organization', collection: @organizations, as: :organization
    json.partial! 'api/v1/organizations/links', collection: @organizations, as: :organization
  end
end

平均响应时间约为41毫秒(平均),响应时间与其他响应不同

# Instead of getting
[{ data:{}, links:{} }, {{ data:{}, links:{} }]
# I get
[{ data:{}, data:{}, links:{}, links:{} }]

但是文件的缓存摘要是一个非常大的字符串,很容易超过unix max文件名长度.这是文件名,例如.

Cache write: jbuilder/organizations/5509f9284162643526000000-20150322012449497000000/organizations/5509e5924162643056020000-20150320223230684000000/organizations/550b54d8416264add2040000-20150321004501311000000/organizations/550e35704162640a98030000-20150322032224768000000/organizations/550e357b4162640a98050000-20150322032235260000000/organizations/550e35834162640a98080000-20150322032243162000000/organizations/550e35894162640a980a0000-20150322032249767000000/organizations/550e35904162640a980c0000-20150322032256464000000/organizations/550e35944162640a980e0000-20150322032300519000000/organizations/550e35984162640a98100000-20150322032304428000000/organizations/550e359c4162640a98120000-20150322032308542000000/organizations/550e35a04162640a98140000-20150322032312514000000/organizations/550e35a54162640a98160000-20150322032317066000000/organizations/550e35a84162640a98180000-20150322032320850000000/organizations/550e35ac4162640a981a0000-20150322032324716000000/organizations/550e35b04162640a981c0000-20150322032328643000000/organizations/550e35b54162640a981e0000-20150322032333651000000/organizations/550e35ba4162640a98200000-20150322032338114000000/organizations/550e35bd4162640a98220000-20150322032341889000000/organizations/550e35c14162640a98240000-20150322032345602000000/organizations/550e35c54162640a98260000-20150322032349739000000/3fcda1f9c320ab4284da56b4b2337cf5`

我也厌倦了Jbuilder Cache Multi

json.data do
  json.cache_collection! @organizations do |organization|
    json.partial! 'api/v1/organizations/organization', organization: organization
    json.partial! 'api/v1/organizations/links', organization: organization
  end
end

响应时间约为57毫秒(平均)

加上jbuilder缓存和multi我在日志中获得了很多这些

  Cache digest for app/views/api/v1/organizations/index.json.jbuilder: 3a51096b9c8da6a2cdb5b5a33ee58ea4
  Cache digest for app/views/api/v1/organizations/_organization.json.jbuilder: 4a1f1d49c90fdd867d88701f8a3fd6e1
  Cache digest for app/views/api/v1/organizations/_links.json.jbuilder: f2a881e125f95421d566edd571fdec73
  Cache digest for app/views/api/v1/organizations/index.json.jbuilder: 3a51096b9c8da6a2cdb5b5a33ee58ea4
  Cache digest for app/views/api/v1/organizations/_organization.json.jbuilder: 4a1f1d49c90fdd867d88701f8a3fd6e1
  Cache digest for app/views/api/v1/organizations/_links.json.jbuilder: f2a881e125f95421d566edd571fdec73
  Cache digest for app/views/api/v1/organizations/index.json.jbuilder: 3a51096b9c8da6a2cdb5b5a33ee58ea4
  Cache digest for app/views/api/v1/organizations/_organization.json.jbuilder: 4a1f1d49c90fdd867d88701f8a3fd6e1

那么我的实现或机器或本地环境有问题吗？Rails 4.2.0和Jbuilder 2.2.11

我还把这个问题发布到了jbuilder#259

Answer 1

为了详细说明我的引用,现在(JBuilder的v2.2.12),如果满足以下一个或两个条件,那么在JBuilder中缓存部分只是值得的:

• 您可以跳过平均比访问缓存更昂贵的 AR查询(或计算)

  转向缓存通常是通常的Rails堆栈中的网络调用,虽然数据库查询可能很昂贵,但是通过网络获取序列化的ActiveSupport blob,然后在Ruby中反序列化为哈希的成本很高,并且必须在Ruby VM中完成.这对性能不利.

• 生成的JSON blob的大小很小

  作为必然结果,如果您有一个小查询,但产生了大量JSON,那么当您从ActiveSupport blob反序列化blob时,您将很快达到降级性能,然后再转向原始JSON.请记住,缓存不存储原始JSON,而是存储序列化的中间格式.这意味着,对于存储在缓存中的JSON的每个附加字节,您将通过线路(来自序列化AS表示)获得大约4个字节,并且可能花费尽可能长的反序列化而不是仅仅计算部分无论如何.

如果你有一个产生巨大JSON blob的端点,我建议只需手动有条件地渲染控制器中的blob并将其作为原始字符串缓存Rails.cache.现在重新计算所有JSON的成本可能低于每次调用时通过JBuilder的缓存机制.

Answer 2

在回答这个问题时...这就是 jbuilder 的工作原理...并且我可以从github 问题中引用

@vincentwoo

问题是 jbuilder 缓存相当简单 - 它基本上将一个巨大的 activerecord blob 的序列化版本转储到缓存存储中，然后将其拉出，反序列化，最后将其序列化为 JSON。

将来，jbuilder 将有望直接作用于字符串，但在那之前，我认为 jbuilder 缓存最好不要使用俄罗斯娃娃风格。

和@rwz（合作者之一）

目前，只有当缓存允许跳过一些 AR 查询或者您使用计算量很大的视图助手时，缓存才会带来好处。

当您已经获取了记录并且仅执行基本提取时，缓存只会减慢速度。