带有ImageResizer DiskCache插件的高CPU

Question

我们注意到在使用ImageResizer的web服务器上偶尔会出现高CPU的现象。以下是使用NewRelic的线程分析器在这样一个高峰期间执行跟踪的惊人结果：

​

​

看起来，与ImageResizer的DiskCache插件相关的清理例程在与此应用程序相关的高CPU消耗中占很大比例。我们启用了autoClean，但如果没有，则配置为使用缺省值，我认为对于大多数典型情况来说，这是最优的：

 <diskCache autoClean="true" />

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

这是一个运行在WindowsServer2008R2上的带有Windows3.4.3的ASP.NET MVC应用程序。

Answer 1

采样，或者为什么分析没有帮助。

New的螺纹轮廓仪使用了一种名为取样的技术--它不对调用进行检测--因此无法知道是否实际使用了CPU。

查看所提供的屏幕截图，我们可以看到，在WaitHandle.WaitAny和WaitHandle.WaitOne调用中经常可以找到清理线程的反向跟踪(只有一个线程)。这些方法是低级别的同步结构，不旋转或消耗CPU资源，而是有效地将CPU时间返回到其他线程，然后继续处理信号。

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

如果/imagecache中有超过7,000个文件，下面是提高性能的一种方法

默认情况下，在V3中，DiskCache使用32个子文件夹，每个文件夹有400个项(1000个硬限制)。由于不完善的散列分布，这意味着您可能开始看到清理发生在只有7,000张图像，并且您将开始在大约12,000个活动缓存文件的磁盘。

这个将在DiskCache文档中解释-请参阅子文件夹部分。。

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