诊断性能差的好工具和方法

我总是遵循这种方法：尝试一次testing一件事。

可靠的“科学方法”对于故障排除非常有效：

1. 拿出一个为什么该应用程序很慢的理论
2. devise一个可以证实这个理论的testing。
3. 重复。

对于一个Web应用程序，这可能意味着

• 它可能是数据库？ 运行一些独立的SQL查询
• 它可能是networking服务器？ 通过获取静态页面来testingWeb服务器
• 它可以是应用程序吗？ 通过点击未触及数据库的dynamic页面来testingWeb服务器
• 它可以是应用程序界面的数据库？ 通过点击打到数据库的dynamic页面来testingWeb服务器。

还运行testingcpu，内存，磁盘速度的基本基准testing可以帮助您在进一步testing之前将其中的一件事情排除在外。

我总是看到这样的事情：

新服务器上的备份需要比旧服务器花费更长的时间。

但没有人做过基本的磁盘基准testing，发现旧服务器的主轴数量是新服务​​器的两倍……或者一个networking基准testing，发现新的服务器千兆以太网只能运行在100M。

所有这一切说，如果这是一个自定义的Web应用程序，您正在使用的框架绝对有一种方法将性能信息转储到一个日志文件..但这是更多的问题stackoverflow。

我已经订阅了“福尔摩斯”的故障排除方法，即二进制search故障排除方法：

1. 把问题空间分成两半。
2. 排除问题空间的一半。
3. 重复剩余的问题空间。

根据我的经验，你有时候首先尝试一些显而易见的东西会很幸运，但是一旦你耗尽了真正的快速修复，你就需要快速有条不紊的进行。

此方法与科学方法和一次testing兼容。

上面的答案总和是我说的90％，其他的10％是这样的：

• 有一个关于控制环境的教训，更具体的是环境的变化。 即使你已经在测量性能，一次改变多个事物意味着任何问题都会变成两步问题：find效果和原因。 如果你每次改变一件事情，并有一个有效的计划，以回滚任何性能问题通常可以与这种变化（通常，有时古怪的东西发生或有人改变你不知道的东西），并希望通过滚动固定回到变化。
• 最有利的做法是尽早和经常地进行测量。 事实和准确的数据使解决性能问题更容易。
• 你可以做的最不有利的事情是猜测什么是错的，不用测量就改变它。 你会惊讶地发现一个合理的猜测猜测并不能解决问题，或者变得更糟。
• 你不能测量你还没有定义的东西。 任何时候，如果您遇到性能问题，请定义最终用户的期望值，然后find一种方法来衡量成功或失败，以您可以重复的方式达到预期目标。 尽可能以一种特定的方式来执行此操作，并且将缩小必须调查的范围以及您需要运行的testing范围。
• 对于Windows，我是性能计数器日志的大爱好者，并使用PAL来处理和帮助解释它们。 该报告的系统概述报告和build议的计数器涵盖了瓶颈的大部分可能的来源。 http://pal.codeplex.com

一些用于Windows故障排除的最佳工具来自微软的Sysinternals 。 有关如何使用它们的最佳信息（以及Windows技术信息）可以在Mark Russinovich的博客和networking广播中find 。 他在Windows内部的书也充满了很好的信息。

有了上面的内容，我build议从程序进程pipe理器和进程监视器开始，看看你正在运行的任何Web服务，看看发生了什么事情。 这两个程序都允许您显示大量关于正在运行的进程的信息，可以通过右键单击列标题进行configuration。

引入性能问题的改变是什么？ 如果只是代码被更改，那么我会开始我的故障排除。

将问题状态与已知良好状态进行比较，并查找差异。

已知良好状态可以是实际logging的状态。 它也可以基于预期行为的标准，例如networking协议的已知预期行为或诸如适当的平均CPU使用率的经验法则。

例子：

使用Wireshark或其他networking嗅探器工具，您反复看到重复的数据包。 现在你可以深入了解一下为什么你在线路上看到相同的IP数据包。 也许你有一个“本地路由器”的情况下，或者可能是分割IP数据包。

平均CPU使用率为90％。 如果平均值为90％，那么服务器可能会频繁地占用CPU，导致所有内容都被备份。

在John T的推荐下，我一直喜欢用gnuplot来使用dstat 。