使用 ImageResizer DiskCache 插件的高 CPU答案

【问题标题】：High CPU with ImageResizer DiskCache plugin使用 ImageResizer DiskCache 插件的高 CPU
【发布时间】：2014-11-26 21:46:44
【问题描述】：

我们注意到偶然使用 ImageResizer 的 Web 服务器上的高 CPU 时段。以下是在这种峰值期间使用 NewRelic 的线程分析器执行的跟踪的令人惊讶的结果：

看来，与 ImageResizer 的 DiskCache 插件相关的清理例程在与此应用程序相关的高 CPU 消耗中占很大比例。我们启用了autoClean，但除此之外，我们配置为使用默认值，据我所知，这对于大多数典型情况来说是最佳的：

 <diskCache autoClean="true" />

有了这些信息，我能做些什么来缓解 CPU 峰值吗？我愿意禁用autoClean 并设置一个简单的夜间清理例程，但我的理解是这个插件的构建是为了聪明地了解它如何使用资源。有没有人遇到过这种情况，并且只要更改默认配置就幸运了吗？

这是一个在 Windows Server 2008 R2 上运行的 ASP.NET MVC 应用程序，带有 ImageResizer.Plugins.DiskCache 3.4.3。

【问题讨论】：

【解决方案1】：

New Relic 的 thread profiler 使用一种称为 sampling 的技术 - 它不会检测调用 - 因此无法知道 CPU 使用情况是否实际发生。

查看提供的屏幕截图，我们可以看到清理线程的回溯（只有一个）经常在WaitHandle.WaitAny 和WaitHandle.WaitOne 调用中找到。这些方法是低级同步结构，不会旋转或消耗 CPU 资源，而是有效地将 CPU 时间返回给其他线程，并在信号上恢复。

正确的分析器应该能够检测空闲或等待线程并将它们从统计分析中消除。由于 New Relic 的分析器未能做到这一点，因此没有有用的方法来解释它提供给您的数据。

默认情况下，在 V3 中，DiskCache 使用 32 个子文件夹，每个文件夹 400 个项目（1000 个硬限制）。由于不完美的哈希分布，这意味着您可能会在少至 7,000 个图像时开始看到清理，并且您将在大约 12,000 个活动缓存文件时开始破坏磁盘。

如果您有大量图像，我建议设置subfolders="8192"。较高的子文件夹计数会略微增加开销，但也会增加可伸缩性。

【讨论】：

谢谢，我希望你能加入。我会尝试你的建议，但你对WaitHandle 的见解特别有用。这证实了我对这些原语如何工作的理解，并让我相信我在 CPU 消耗方面是错误的。
@Lillith River - 目前的建议是什么？我们有超过一百万张图片，一旦达到子文件夹上限，服务器就会崩溃。这里有实际限制/处理大量图像的更好方法吗？我们确实在应用程序前面有一个 CDN。