获取精确地结果

　　最好的获取精确结果的方法就是，你设计的基准测试可以回答你想回答的问题。你选对了正确的基准测试了么？你正在捕获的数据能解答你需要知道的问题？用错误的标准进行基准测试了？你可能知道的是I/O边界基准测试，但是运行CPU边界的基准测试去预测程序的性能了么？

　　接下来，确定你的基准测试结果是可以重复验证的。在每次运行的开始，尽可能的确保系统是在相同的状态下。如果基准测试很重要，你应该在每次运行都去重启动系统。如果你需要基准测试预热的服务器，你应该也要确定你的预热时间是足够的长以及是可重复验证的。如果预热是由随机的语句所组成，这个基准测试结果就是不能重复验证的。

　　如果基准测试更改了数据或者数据模型，要在每次运行之前，进行数据重置。往一个上千数据的表的测试结果当然是和百万级别的表是不一样的。在硬盘上的数据碎片和分布也可能让你的结果是不可重复验证的。一个方法确认物理布局是差不多相近的，那么就快速格式化以及一个分区的文件拷贝。

　　要当心一些外部读取，程序剖析以及监控系统，详细的日志，周期性的任务，以及其他能使你结果偏离的因素。一个比较典型的因素就是周期性任务（con job），往往运行在基准测试之中，或者一个巡查读取周期（Patrol Read cycle）或者一个在RAID上进行一致性的检查。一定要确定一切资源都是为了基准测试。如果其它的一些影响了网络的能力，或者基准测试运行在与其他服务器共享的SAN上。你的结果可能不会准确。

　　在每次的基准测试中，尽可能的少更改参数。在这场景中，叫做“隔离变量”。如果你必须更该一些，那么可能要冒着丢掉某些东西的风险。参数可能还依赖于其他参数。因此有的时候，你不能单独的修改它们。有的时候你甚至不知道它们是相关的，这就更增加了复杂性。

　　一般情况下，都是迭代更改基准测试的参数。而不是在各个运行之间去更改。举个例子，使用一种如（divide-and-conquer）的技术（在各个运行之间，把差异分成两部分）对于服务器能得出一个有价值的信息。

　　我们看到了很多在移植之后的基准测试，如从Oracle移植到MySQL。这往往是令人讨厌的。因为MySQL与Oracle相比，有很多不同类型的语句运行的效果要好。如果你想知道从oracle移植到MySQL之后，这个应用的表现如何。你就需要修改数据模型和在MySQL下的语句了。（在许多案例中，如你要创建一个跨平台的应用，你可能想知道，同一语句在两个平台上的表现，但是这种案例很少见）

　　你也不能在MySQL默认配置的情况下获得有意义的数据。因为默认的配置都是面向的是极小的应用和消耗非常少的内存。

　　最终，如果你得到的是一个奇怪的结果，不要把它作为坏的数据而丢弃。调查和尽力找出哪出了问题。你可能会得到有价值的结果，一个严重的错误，或者是基准测试的设计缺陷。

　　运行基准测试和分析结果

　　一旦你准备好了所有的前期准备，你可以运行基准测试并获取并分析数据。

　　自动运行基准测试是个非常好的主意。这么做会提高结果的质量和精确程度。因为这能避免忘掉某个步骤或者每次运行都会有一些突发事件。它也能帮助你记录基准运行的方式。

　　任意的自动化方法都可以做，如，Makefile或者一些脚本。你可以任意选择一些脚本语言：shell,php,Perl等等。尽可能的让更多的步骤进行自动化。包括了读取数据，系统得预热，运行基准测试，以及记录结果。

　　你经常多次的运行基准测试。到底运行多少次，这和你计分方式和结果的重要性有很大关系。如果你要最准确的确定的事情。你需要更多次的运行基准测试。有许多好的方式有助于得到更准确的结果，如平均所有结果或者运行5次基准测试，取其中最好的3次取平均。可以精确的获得你想要的。你可能应用统计学来分析结果，找出可信的区间等等，但是往往你并不需要这个精确级别。如果这些结果可以令你满意，你可以简单的运行基准测试以及看这些结果的变化。如果结果变化非常大，那么只有多次运行或者运行时间更长。这样才能降低结果的差异。

　　一旦你有了结果，你需要分析它们-那就是把数量转换为知识。目标就是解决问题。比较理想的是，得到结果如：相同的延迟下升级到4个CPU可以提高50%的吞吐量。索引能使查询更迅速。

　　你怎样完全分析透数据取决于你怎样收集结果。你可能应该写脚本去分析结果，不仅仅能降低工作量，也可以自动运行基准测试：重复和记录。