基准测试的方法

　　一般在这之后，我们再来详细的说明怎样设计和执行基准测试。在我们讨论怎样能更好的做基准测试之前，先来看看一些错误，它们能导致不可用或者不准确的结果。

　　* 使用真实数据的子集，如本来这个应用需要处理几百G的数据，而测试数据仅为1G。再如，你计划这个程序处理的数据增长非常之快，而测试数据还是当前的数据量。

　　* 使用不正确的分布式数据。当真实的系统有一些所关注的“热点”却均匀分布数据。（随机生成的数据是不真实的分布）

　　* 使用不真实的分布参数（unrealistically distributed parameters）。假装所有的用户资料都是可见的。

　　* 对于多用户的应用，使用单用户的场景。

　　* 在单独的服务器上测试分布式应用。

　　* 不符合实际的用户行为。比如在网页的“等待时间”（think time）。真正的用户请求一个页面然后再去阅读；没有停顿的情况下，他们不能依次的点击链接。

　　* 在循环中执行同一语句。真正的语句不是相同的。因此它们忽略了缓存。相同的语句在某些级别被缓存了。

　　* 没有检查错误。如果基准测试结果没有意义。比如，一个缓慢的操作突然变快了，请检查错误。你做的基准测试可能会快速发现了MySQL的语法错误。基准测试之后查看错误日志，是个比较重要的准则。

　　* 忽略了系统没有预热（warmed up）下的执行情况。比如在重新启动之后，你要知道在启动之后，服务器需要多久才能达到一定的能力。因此就要看“预热”阶段，系统执行的情况。如果你要研究正常的性能，你需要关心的是，基准测试在服务器重启之后，许多缓存被清空的情况下，在系统预热之前，这基准测试是不能反映出正常的结果的。

　　* 使用默认的服务器设置。以后会详细讲到。

　　为了得到有质量的结果，避免了这些错误，只不过刚刚上路而已。

　　其他的一些也一样，你要尽最大努力去做到真实性。但有的时候，不真实的基准测试也说得通，比如，你的应用是在不同主机的数据库服务器上。可能在相同的配置下，运行基准测试会更真实，但是这么做需要增加额外的信息，如网络的速度和负载。在单点上做基准测试一般来说都很简单，在许多实例中已经足够了。这就需要你自己判断怎么样是最合适的。

　　基准测试的设计和计划

　　基准测试计划的第一步就是发现问题和目标。接下来 决定是使用标准的基准测试还是自己设计一个。

　　如果你使用标准的基准测试，要选择一个适合你的需要。一个例子，不用TCP去基准测试电子商务系统。TCP已经说了。它比较适合决策支持系统。这个系统需要查看大量的数据。因此，它并不适合在线交易系统。

　　设计自己的基准测试是个比较复杂和迭代的过程。开始的时候，要做一个产品数据集的复制。确定在随后进行的测试，数据可以恢复。

　　接下来，需要针对数据运行大量的语句。你可以在基本的基准测试中创建一个单元测试包。你可以多次运行它，但是可能并不适合你使用数据库的方式。比较好的做法是在一个典型的时间段中如高峰期或一整天，在产品系统中记录所有的语句。如果你记录的语句在一个小时间段中，你可能需要选择很多的时间段。这样才能覆盖系统所有的活动。如语句的周报或者不在高峰时期的批量任务。

　　可以在不同级别记录日志。一个例子，如果你需要全栈的基准测试，那么就需要web服务器的日志。你也要开启MySQL的日志功能。如果你重新查看一个语句的日志，要重新新建一个独立的线程来执行，而不是仅仅重复执行这个语句。在日志中，为每一个连接创建一个独立的线程也是非常重要的。而不是把各个线程执行的语句弄混。日志应该显示链接哪个连接运行每条语句。

　　即使你不创建自己的基准测试，你也要应该有自己的基准测试计划。你的基准测试将会运行很多次以及你需要有能力去重新准确的创建它。计划意味着未来。你可能不会是下次运行基准测试那个人，即使你是，你可能也不会准确记住你第一次是怎样运行的。你的计划应该包含测试数据，设置系统的步骤以及预热（刚启动服务器的时候，性能并没有完全发挥的时候）的计划。

　　设计一些记录参数和结果的方法，并且仔细的记录系统运行情况。你的记录方法可能像电子表格或者记事本或者如复杂点的数据库。（记住，你可能需要写一些脚本区分析一些结果。因此它比那些电子表格和文本文件更容易处理）。

　　你可能会创建一个基准测试的目录，对于每个结果建立子目录。之后，可能会放置结果，配置文件或者记录每次运行情况。如果你的基准测试测量的数据要多于你所感兴趣的。有一些不需要的数据要好于丢失重要的数据，以及将来你可能会发现这些额外的数据非常有用。在基准测试中要尽量记录更多的信息。如CPU德使用。硬盘的I/O.以及网络流量分析。使用SHOW GLOBAL STATUS去发现一些计数统计等等。