Jbuilder缓存更慢。

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 is (平均)。

现在有了缓存

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 is (平均)。

使用缓存摘要上的语法

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 is (平均)，响应与其它响应不同。

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

但是文件的缓存摘要是一个很大的字符串，它很容易超过unix文件名的长度。例如，这是文件名。

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 on左右。

另外，使用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的2.2.12版)，只有在以下一项或两项都正确的情况下，JBuilder中的缓存部分才是真正值得的：

• 您可以跳过平均比访问缓存更昂贵的AR查询(或计算)。 在通常的Rails堆栈中，缓存通常是一个网络调用，虽然DB查询可能会很昂贵，但通过网络获得序列化的ActiveSupport blob，然后反序列化为Ruby的代价是昂贵的，必须在Ruby中完成。这对性能不好。
• 生成的JSON blob大小很小 作为推论，如果您有一个小的查询，但是产生了大量的JSON，那么随着blob从ActiveSupport blob反序列化，然后在输出到原始JSON的过程中，您将很快地降低性能。请记住，缓存不存储原始JSON，而是存储序列化的中间格式。这意味着，对于存储在缓存中的每一个额外的JSON字节，将有大约4个字节在线路上(从序列化为表示)，并且可能花费的反序列化时间与只计算部分任何方式所需的时间一样长。

如果您有一个产生巨型JSON的端点，我的建议是手动在控制器中有条件地呈现blob，并将其缓存为Rails.cache中的原始字符串。偶尔重新计算所有JSON的成本可能比每次调用JBuilder的缓存机制都要低。

Answer 2

作为回答的时间..。这就是jbuilder的工作方式..。我可以引用github问题的话

@vincentwoo

问题是jbuilder缓存相当幼稚-它基本上将一个巨型activerecord blob的序列化版本放入缓存存储中，然后取出它，反序列化它，然后最终将它序列化为JSON。 在未来，jbuilder有望直接处理字符串，但在此之前，我认为jbuilder缓存最好不要使用俄罗斯娃娃风格。

和@rwz (合作者之一)

目前，只有在允许跳过某些AR查询或使用计算量很大的视图帮助程序时，缓存才能带来好处。 当您已经获取记录并且只执行基本提取时，缓存只会减慢速度。