服务器性能

这听起来可行吗？

是。

任何其他的我怎么可以去testing这个呢？

性能检查。 请注意，性能不仅仅是CPU。 如果您认为数据库是问题，那么可能是IO界限 – 在这种情况下，磁盘延迟/活动的估计将会大幅增加。 检查光盘性能计数器。 特别是如果你是IO buond，CPU会低，因为CPU基本上不提供服务进程，因为它是等待IO完成。

越来越繁忙，通常情况下，数据库需要大量的IO预算，这意味着相当多的光盘。 我在这里有一个数据库，现在使用6个10k RPM的光盘，很快就升级到8 – 只有数据。 一个典型的便宜的专用服务器往往有真正蹩脚的IO预算 – 缓慢的大型terminal用户光盘，其中很less，不build立一个快速的子系统。 这在某些情况下效果很好，但最后可能会超载。

正如TomTom所说，这几乎肯定表明你的系统是IO绑定而不是CPU绑定的。 根本原因可能只是CMS背后增加的负载数据库，或者可能是其他的东西，但是在任何情况下，PerfMon都有一些有用的计数器，可以明确地告诉你，如果磁盘子系统是原因。

\逻辑磁盘\平均。 Disk Sec / Read和\ LogicalDisk \ Avg。 磁盘秒/写
这些是读取和写入IO操作的基本延迟数字，越低越好。 任何时候，这些数字超过15毫秒左右，服务器的性能将显着差。

\ LogicalDisk \ Disk Bytes / Sec和\ LogicalDisk \ Disk Reads / Sec，这会告诉您整个磁盘的吞吐量。 这些速率可能会使磁盘子系统的最大容量达到饱和，这要么是由于吞吐量本身，要么是因为读取/写入模式已达到IOPs限制。 除非您100％确信自己拥有可预测的IO模式，否则很难从中推断出任何重要的东西。 在这里没有真正有用的方法来给出任何具体的数字，但是如果你看到一个单一的SATA磁盘50-100MBytes /秒或更多，这将是一样好，你可以期望看到。 更快的服务器磁盘（10K，15K，SSD）可以超过这个数量，SAN附加存储可以提供几乎任何你想要的，只要你付出足够的钱。 随着小随机IO（数据库操作的典型），这个数字总是很低，并没有告诉你很多。

\ LogicalDisk \ Disk Writes / Sec，\ LogicalDisk \ Disk Reads / Sec和\ LogicalDisk \ Disk Transfers / sec这些将告诉您每秒离散IO操作的次数和读取/写入比率。 旋转磁盘在这方面相当有限 – 7.2K SATA磁盘每秒可以维持70-80个IO，10K磁盘可以达到100-150范围，15K达到200+。 SSD将会是一个或两个更高的数量级。 RAID组对于读取的增加是相当线性的，但写入将受到2到5之间的惩罚。例如，3个驱动器的RAID 5包（写入惩罚为4）比单个驱动器支持的写入IOless25％。

如果这个数字趋于增加，而潜伏期正在增加到危险区域（即> 15ms），则强烈表明您的磁盘达到IOPs限制，无论报告的具体数字如何。

\ LogicalDisk \ Split IO / sec这将告诉您有多less个IO请求导致多个操作，并且会让您知道有多less碎片影响IO活动。

物理磁盘：当前磁盘队列长度和物理磁盘：平均 磁盘队列长度。 这将告诉您在物理磁盘级别有多less未完成的IO正在等待完成。 如果单个磁盘上的值为2或更高，或者超过磁盘所在的RAID组中磁盘的数量，则可能会将更多IO推入磁盘，而不是及时完成。 有些情况下，这并不重要，但对于需要低延迟磁盘IO（内存caching不能覆盖磁盘弱点的数据库）的系统来说，这将是真正的杀手锏。 第一个是瞬时读数，所以只要它一直很高或与％磁盘时间计数器一致就担心。 如果平均 磁盘队列长度太高，那么你肯定有问题。

PhysicalDisk：％Disk Time ％磁盘时间告诉你磁盘有多繁忙。 当它接近100％时，你会努力让系统去做任何依赖于这个磁盘的东西，因为所有额外的IO往往会排队。 即使数字大大低于100％，也可能表明存在问题，如果这个数字很高或上升，并且当前磁盘队列长度很高，这明确表示IO负载超过磁盘容量。 这个数字实际上是以一种奇怪的方式计算的，因此在分析RAID性能时可能并不是那么有用。

本Technet博客文章在这些计数器的某些方面进行了更深入的研究，并且可以使用这些scheme来识别问题并确定如何解决问题。

是否值得考虑configuration您的Web应用程序池经常回收工作进程？