【问题标题】:Space Restriction for Client side caching客户端缓存的空间限制
【发布时间】:2014-08-19 11:26:52
【问题描述】:

我有一个返回大约 40 张图片的搜索结果页面。我使用 mongohq 来存储我的图像。 现在这些形象永远不会改变。它们要么被删除,要么保持原样。

所以我的 Spring servlet 基于图像 id 从 mongoHq 读取图像后流式传输图像

/app/download/{uniqueImageId}

一切正常。除了流式传输图像的加载时间。我觉得这些图像对于这些唯一的 id 将保持不变,所以为什么不缓存它们。我可以添加一个适用于我上面的 url 类型的过滤器并添加一个缓存标头,我计划给它一个非常长的值,比如可能将图像缓存一周。

我的问题是,如果我开始告诉客户端的浏览器缓存所有这 40 多张图片,它会缓存所有这些图片吗? 客户端没有空间限制吗?

您有没有更好的选择来处理这种情况?

【问题讨论】:

    标签: java image performance caching


    【解决方案1】:

    我的问题是,如果我开始告诉客户端的浏览器缓存所有这 40 多张图像,它会缓存所有这些图像吗?客户端没有空间限制吗?

    当然,客户端有空间限制(也是整个世界的存储空间都是有限的……呃,对不起……)。用户可能会限制缓存空间,和/或浏览器只是自动占用可用于缓存的可用空间。

    通常我希望浏览器缓存总是几兆字节(假设是 100+),因此会话中传输的经常需要的图像(如图标)将被缓存。当用户在三天后访问您的网站时,图像是否仍在缓存中,取决于缓存大小和介于两者之间的用户活动。所以你永远不知道。

    客户或任何中间代理所做的一切都超出了您的直接控制范围。您通过设置缓存标头所做的唯一一件事就是说暂时不刷新此资源是合法的。如果您确实在应用程序中设置了标头,请确保您正确理解 HTTP1.1 标头。

    您有没有更好的选择来处理这种情况?

    “更好”这个词在这里并不十分准确。您究竟需要优化什么?

    如果您对同一图像集有很多请求,您可以通过在应用程序前面放置一个边缘服务器(如 nginx)来减少服务器和数据库负载,该服务器配置为缓存反向代理。在这种情况下,您自己的边缘服务器正在解释缓存标头。一般来说,如果应用程序在提供静态资源方面没有显着负载,我认为这是一个很好的设计。

    【讨论】:

      猜你喜欢
      • 2017-03-18
      • 2012-07-26
      • 2019-04-24
      • 1970-01-01
      • 2011-08-27
      • 2011-11-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多