Jbuilder Rails缓存速度较慢 [英] Jbuilder Rails caching is slower

查看:114
本文介绍了Jbuilder Rails缓存速度较慢的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I've tried to use caching with collections (with multiple solutions) the problem is that when ever I try caching the response become slower consider the following example of a collection that renders 2 partials for every item in it (around 25 item)

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毫秒(平均)

without caching the average response time is around ~38ms (on average)

现在可以缓存

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存储(我可以确认没有缓存未命中)

with the jbuilder default caching and dalli store is properly installed and configured (I could verify that there was no cache miss)

平均响应时间约为59毫秒左右

the average response is around ~59ms (on average)

使用缓存摘要

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

平均响应时间为〜41ms(平均),并且响应与其他响应不同

the average response time is ~41ms (on average), and the response is different than the other responses

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

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

but the cache digest of the file is a very big string that will easily exceed the unix max file name length. this is the filename for example.

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毫秒

and the response was around ~57ms (on average)

加上jbuilder缓存和multi日志,我在日志中得到了很多

plus with both jbuilder cache and multi I'm getting a lot of these in the logs

  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

so is it something wrong with my implementation or machine or local environment ? Rails 4.2.0, and Jbuilder 2.2.11

我也将此问题发布到了jbuilder#259

推荐答案

要详细说明一下我的报价,截至目前(JBuilder v2.2.12),仅当其中一个或两个都在JBuilder中进行缓存时,才真正值得在JBuilder中缓存部分内容以下是正确的:

To elaborate on my quote, as of right now (v2.2.12 of JBuilder), caching partials in JBuilder is only really worth it if one or both of the following are true:

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

去缓存通常是在通常的Rails堆栈中进行的网络调用,虽然数据库查询 可能很昂贵,但通过网络获取序列化的ActiveSupport blob然后反序列化的开销在Ruby中将其放入哈希中非常昂贵,并且必须在Ruby VM中完成.这对性能不利.

Going to cache is usually a network call in the usual Rails stack, and while a DB query can be expensive, the cost of going over the network to get a serialized ActiveSupport blob, and then deserializing into a hash in Ruby is expensive and has to be done inside the Ruby VM. This is not good for performance.

生成的JSON Blob的大小很小

The size of the JSON blob produced is small

作为一个必然结果,如果您有一个小的查询,但是产生大量JSON,则由于从ActiveSupport Blob中反序列化Blob,然后又返回原始JSON的过程中,您将很快遭受性能下降的困扰.请记住,缓存不存储原始JSON,而是存储序列化的中间格式.这意味着,对于存储在缓存中的JSON的每个额外字节,您将在网络上(从序列化的AS表示形式)增加大约4个字节,并且可能花费与计算反序列化所需的时间相同的反序列化时间.还是偏偏的.

As a corollary, if you have a small query, but produce a lot of JSON, you will quickly hit degraded performance as the blob is deserialized from an ActiveSupport blob, and then again on the way out to raw JSON. Remember, the cache does not store raw JSON, but a serialized intermediary format. This means, for every additional byte of JSON stored in the cache, you're going to have about 4 more bytes over the wire (from the serialized AS representation) and probably spend just as long deserializing as it would have taken to just compute the partial anyhow.

如果您的端点产生一个巨大的JSON Blob,我的建议是仅在控制器中手动有条件地呈现该Blob,并将其作为原始字符串缓存在Rails.cache中.时不时地重新计算所有JSON的成本可能比每次调用都要通过JBuilder的缓存机制要低.

If you have an endpoint that produces a giant JSON blob, my recommendation is to just manually conditionally render the blob in the controller and cache it as a raw string in Rails.cache. The cost of recomputing all of your JSON now and then is probably less than going through JBuilder's cache machinery on every call.

这篇关于Jbuilder Rails缓存速度较慢的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆