我正在构建一个带有产品页面的 Asp.Net MVC4 应用程序。我是通过ImageResizer库来处理和提供图像的。我的页面有 jpg 缩略图，尺寸为 160x160px，每个尺寸为 3~5KB。据我了解，使用 ImageResizer 库我可以上传原始的大型产品图像 600 x 600px & 10~20KB 并在访问者请求页面时将其动态调整为缩略图大小。就像是：
<img src="@Url.Content("~/images/imagename?width=160&height=160")" alt="">
我理解这对于几张图片来说很好，但我的产品页面包含 20 到 100 个产品 jpg 独特缩略图（取决于页面大小）。每次即时处理 20-100 张图片是否会损害性能？有没有人遇到过类似的情况？在上传过程中，我总是可以返回并生成 2 张不同的图像（缩略图和大图），但我非常好奇，如果我能摆脱每个产品的一张图像和动态调整大小的问题。当我说性能时，我的意思是任何超过 0.5 - 1 秒的额外响应时间对我来说都是禁忌。
在文档中提到，有缓存插件，可将性能提高 100-10000 倍：
每个面向公众的网站都需要为其动态调整大小的图像进行磁盘缓存（不，ASP.NET 的输出缓存不起作用）。该模块速度极快，但解码原始图像需要大量连续 RAM（通常为 50-100MB）才能使用。由于它需要连续的、非分页的、非分段的 RAM，它不能用于 (D)DOS 攻击向量，但这确实意味着可以处理多少并发图像处理请求存在基于 RAM 的限制. DiskCache 插件通过将缓存文件的服务委托给 IIS 并利用哈希树磁盘结构将吞吐量提高了 100-10,000 倍。它可以轻松扩展到 100,000 个变体，并可用于多达一百万张图像。它是性能版的一部分，售价 249 美元。
http://imageresizing.net/plugins/diskcache
http://imageresizing.net/docs/basics
说到网站，每一个可以缓存的操作都应该是。这允许服务器处理更多的访问者而不是更多的处理。
您可以使用 ImageResizer 的缓存插件，也可以使用某个文件名手动写入文件，例如：product_154_180x180.jpg 其中 154 是产品 ID，180 是宽度和高度，然后在要显示时检查它是否存在它。
如果你做后者，你可以使用服务器来为你管理这个，通过链接到页面源中的预期文件名，如果它不存在，服务器然后调用一个脚本来调整大小并写入使用 imageresizer 将图像大小调整到磁盘。
最后一种方法也将避免调用 ImageResizer 为您节省一些处理能力。