Question

首先，我理解这个问题可以被视为主观的，但我坚信应该存在并且可能是对我的问题的明确答案。

在工作中，我们正在实施一种使用通用处理程序动态调整大小和提供图像的策略，缓存问题已成为一个有争议的问题。

在我的原始实现中，已调整大小的图像缓存在内存中，具有基于原始图像的缓存依赖性。

e.g

using (MemoryStream ms = new MemoryStream())
{
    imageEditor.Image.Save(ms, imageFormat);
    // Add the file to the cache.
    context.Cache.Insert(key, 
        ms.ToArray(), 
        new System.Web.Caching.CacheDependency(path)
        );
    imageEditor.Dispose();

    // Set the context headers and serve.
    SetHeaders(ms.GetHashCode(), context, responseType);
    context.Response.BinaryWrite(ms.ToArray());
}

这有它的缺点。

每次回收应用程序池工作进程时（默认情况下每隔1740分钟），我们将丢失缓存中的所有内容。
如果有很多图像，我们可能会有超载系统内存并导致内存不足的危险。（如果使用率达到一定水平，IIS会通过回收应用程序池来阻止这种情况吗？）

我的一位同事建议我们实现一个文件缓存系统，而不是保存调整大小的文件，而是在后续请求中提供该文件，这应该（我不知道操作系统IO缓存内存管理的复杂性）减少内存用法。虽然这样我们可以将重新调整后的图像保留在循环回收中，但我发现这种方法存在一些主要问题：

我们无法再跟踪原始文件，如果有人上传了同名的新图像我们调整大小的图像将不正确。
文件服务器随着时间的推移会被数以千计的图像污染
与从内存中读取相比，读取文件的速度很慢。特别是如果您正在阅读多个文件。

最佳整体方法是什么？是否有一个由Microsoft定义的标准？我们建立的网站通常非常繁忙，所以我们非常希望能够做到这一点并达到最佳标准。

Answer 1

这不是您问题的完整答案，但是，您不应该通过将大量内容放入缓存中来导致系统出现内存异常。如果系统内存应该开始低电平运行，application cache将自动开始删除不重要且很少使用的项目，以避免造成任何内存问题。

Answer 2

我的网站上有类似的系统。关于您对文件缓存系统的反对意见：

1,2）在我的网站上，我有一个类，所有文件保存/加载都通过该类。您可以实现类似的功能，只要用户上传新图像，就会清除所有缓存的，已调整大小的图像。如果以可预测的方式命名文件，这并不难。如果存储空间是您关心的问题，您可以实现一些操作来删除所有缓存的图像，其上次访问日期太旧。

3）这取决于您的网站的工作方式。我的网站有大量图像，因此将它们全部存储在内存中是不可行的。如果您的网站图片较少，则可能是更好的解决方案。

Answer 3

您可以使用ASP.NET Generated Image。 Scott Hanselman的有趣文章 - ASP.NET Futures - Generating Dynamic Images with HttpHandlers gets Easier.

缓存图像处理程序输出策略

3 个答案: