目录
记录
以脚本代替手动输入
选择低开销的工具
同时使用多个工具
确定指标和基线
追踪近似问题
查看问题是否早已解决
分离问题
一次只改变一件事
始终在优化后重新测量
记录
在调查性能问题时，你可以做的最重要的事情大概就是记录下看到的每一个输出、执行的每一条命令，以及研究的每一个信息。结构清晰的记录能让你只查看记录就可以检验关于性能问题原因的猜想，而不是重新运行测试。这能节约大量时间。写下来并且创建性能记录。
每一步操作、每个输出结果，可以直接截图或者复制保存在文档，便于后期对比分析。以脚本代替手动输入
使用脚本自动执行，可以节省时间，并有助于避免因不当工具和测试调用造成的误导性信息。
举个例子，你想在特定工作负载下或某段时间内监控系统，但是在测试结束时，你可能不在现场。这种情况下，脚本就很好用了，在测试完成时，可以自动收集、命名、保存全部生成的性能数据，并将它们自动放到“Results”目录中。有了这些基础之后，你就能按照不同的优化和调整重新运行测试，并且不用担心数据是否已经保存好。你反而可以集中精力找出问题的原因，而不是去管理测试结果。选择低开销的工具
使用工具观察性能变化的同时，也会占用系统的资源，所以尽量选择低开销的工具来降低对系统的影响。
有些性能工具能够给出高度精确的系统信息，但其检索信息的开销也很高。高开销工具对系统行为带来的变化大于低开销工具。如果你只需要了解系统的粗略信息，那么使用低开销的工具是更好的选择，即使它们不够准确。同时使用多个工具
虽然在找出性能问题原因的时候，如果只需要用一个工具那将是非常方便的，但这种情况相当少见。实际上，你使用的每一种工具都会为问题的原因提供线索，因此，你必须同时使用多个工具来真正搞清楚发生了什么。比如，一种性能工具会告诉你系统存在大量的磁盘I/O，而另一种工具则告诉你系统使用了大量的交换。如果只以第一个工具的结论制定解决方案，你可能会简单地选择更快的磁盘驱动器（然后发现性能问题仅仅改善了一点点）。而将两种工具的结果放在一起，你就会判断出：大量的磁盘I/O是由大量使用的交换造成的。在这种情况下，你可能会买更多的主存以减少交换（这样就不会再有大量的磁盘I/O）。确定指标和基线
明确性能峰值有助于你设置合理的性能期望值，并能给你一个性能目标，这样你就知道何时应该停止优化。你可能总是没有目标地时不时对系统做一点调整，这会浪费大量的时间，只为得到一些额外的性能，即使你可能并不真的需要它们。
要想知道什么时候结束优化，你必须为系统自行确立或是使用已发布的指标。指标是一种客观的度量，用于指示系统的执行情况。例如，如果你要优化一个Web服务器，你就可以选择“每秒服务的Web请求数”。如果你没有一个客观的途径来度量性能，那么在调整系统的时候，你几乎无法确定是否取得了进展。
在调整和优化之前，运行应用程序并记录其性能，这就是基线值，它是性能调查的起点。追踪近似问题
通过初始的粗略尝试，你能对问题形成大致的看法。这个简单切口的目的就是收集足够的信息传递给程序的其他用户和开发者，以便他们提出意见和建议。这里非常重要的一点是要有良好的书面记录来解释你认为问题是怎样的，以及什么样的测试使你得出了这个结论。查看问题是否早已解决
通过搜索引擎(谷歌、百度或国内常见的技术博客平台，比如博客园、CSDN等)查找相似的错误信息/问题。
Web搜索常常会揭示很多与应用程序以及你正在查找的具体错误情况相关的信息。它们还可以指向其他用户所尝试的系统优化，还可能提示哪些有作用、哪些没有作用。成功的搜索可以产生好几页能够直接用于你的性能问题的信息。分离问题
如果可能的话，删去任何运行于被调查系统的多余的程序或应用。运行许多不同应用程序的系统，其负载较重，会影响性能工具收集信息的准确性，并最终将你引导到错误的方向。一次只改变一件事
这点非常重要。要真正确定问题出在哪儿，一次只能有一个变化。这可能会很花时间，并让你运行多个不同的测试，但它的确是发现你是否解决了问题的唯一途径。始终在优化后重新测量
如果你稍稍调整了系统，那么在调整后对所有的事情重新进行测量是很重要的。当你开始修改系统配置时，所有之前生成的性能信息可能不再有效。通常，在你解决一个性能问题时，别的问题会随之而来。新问题可能与老问题有着极大的不同，因此，你真的需要重新运行性能工具来确保正在调查的问题没有出错。
