【问题标题】:Fragment Caching and User avatars/images片段缓存和用户头像/图像
【发布时间】:2013-03-13 02:04:38
【问题描述】:

我们在我们的网站上使用 Gravatar,但我们希望让用户直接上传他们的个人资料图片,以改善用户体验,类似于 Stackexchange has been doing

在我们的网站上,用户可以相互关注、评论、“点赞”并以直接或间接生成内容的方式进行互动。 这意味着带有用户头像的缓存片段分散在各处,我们无法找到合理的方法来使其无效而不会对渲染性能产生负面影响。

以下是我们研究过的可能解决方案:

选项 1) 采用 Gravatar 方法并设置非常短的 Expires/Cache-Control max-age 标头并回收相同的图像文件名。

选项 2) 为所有用户使用占位符图像,其数据属性包含由 JavaScript 读取的用户 ID,并用于发出第二个 Ajax 请求,请求服务器提供最新数据头像。

有没有更好的方法来解决这个问题?我们是否忽略了什么?

【问题讨论】:

    标签: ruby-on-rails ruby-on-rails-3 caching gravatar


    【解决方案1】:

    我想我理解你的问题,但我不确定我是否理解选项 2 作为解决方案,这可能表明它不是一个很好的解决方案。如果是我,我只会将正在重用的用户 gravatar 周围的 html 缓存在由用户 ID 键入的顶级缓存键中。即。

    <% cache("user_#{user.id}_profile_image") do %>
      <img src="blahblahblah or gravatar helper code or whatev">
    <% end %>
    

    如果您担心用户上传 gravatar,然后会缓存默认 gravatar 图片,我会说您最好的选择是:

    1) 在您发送他们上传 gravatar 的用户个人资料区域中,有一个刷新链接,该链接指向一个刷新操作,该操作实际上使该用户缓存片段无效。即

    expire_fragment "user_#{user.id}_profile_image"
    

    (http://guides.rubyonrails.org/caching_with_rails.html)

    2) 您可以不使用默认的 gravatar 重定向来上传图片,而是拦截点击,将其发送到您自己的控制器,安排后台任务在 15 分钟左右运行,然后渲染 javascript响应将他们重定向到实际的 gravatar 页面以上传他们的图片。然后后台工作人员将在稍后运行时清除该片段。这假设他们实际上上传了他们的图片,并且总的来说我会说一个糟糕的想法。

    不过,老实说,我不知道你为什么一开始就担心缓存 gravatar。它击中了 gravatars 服务器,因此它不会在您的服务器上造成任何负载,自己存储它似乎有点自我挫败到使用 gravatar 的地步。希望您的问题更简单(并且只是:如何在用户上传自己的图像时清除默认缓存的 gravatar 图像),这可以通过 #1 解决),这将允许您使缓存的 gravatar 图像过期并使用您自己的重新缓存它图片,在用户上传他们的图片后。 (其中,下次呈现页面时会重新缓存图像,因为您有一些逻辑,例如:

    <% cache("user_#{user.id}_profile_image") do %>
      <% if user.has_uploaded_image? %>
         <%= display_profile_image %>
      <% else %>
        <%= display_gravatar_image %>
      <% end %>
    <% end %>
    

    【讨论】:

      猜你喜欢
      • 2019-12-23
      • 1970-01-01
      • 2011-09-17
      • 2012-04-26
      • 1970-01-01
      • 1970-01-01
      • 2011-10-28
      • 2012-11-30
      • 2012-06-02
      相关资源
      最近更新 更多