关键词：
压力测试 可靠性测试 sysbench
学习目的：
通过了解基准测试的策略、方法、工具、案例，结合实践，掌握系统的行为。
2.1 为什么需要基准测试
基准测试是唯一方便有效的、可以学习系统在给定工作负载下会发生什么的方法。
基准测试可以观察系统在不同压力下的行为，评估系统的容量，掌握哪些是重要的变化，或者观察系统如何处理不同的数据。
基准测试可以完成以下工作，或者更多：
- 验证基于系统的一些假设，确认这些假设是否符合实际情况
- 重现系统中的某些异常行为，以解决这些异常
- 测试系统当前的运行情况。如果不清楚系统当前的性能，就无法确认某些优化的效果如何。也可以利用历史的基准测试结果来分析诊断一些无法预测的问题。
- 模拟比当前系统更高的负载，以找出系统随着压力增加而可能遇到的扩展性瓶颈。
- 规划未来的业务增长。基准测试可以评估在项目未来的负载下，需要什么样的硬件，需要多大容量的网络，以及其他相关资源。这有助于降低系统升级和重大变更的风险。
- 测试应用适应可变环境的能力。
- 测试不同的硬件、软件和操作系统配置。
- 证明新采购的设备是否配置正确。
我们只能进行大概的测试，来确定系统大致的余量有多少。尽管不能完全模拟真实环境，但是基准测试还是非常有用的（只要搞清楚测试的原理，并且了解如何分析结果所代表的意义）。
2.2 基准测试的策略
集成式
针对整个系统做集成测试，而不是单独测试MySQL的原因主要有以下几点：
- 测试整个系统，包括Web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是MySQL本书的性能，而是应用整体的性能。
- MySQL并非总是应用的瓶颈，通过整体的测试可以揭示这一点。
- 只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。
- 更能揭示应用的真实表现，而单独组件的测试很难做到这一点。
单组件式
在项目初期，可以只测试MySQL
- 需要比较不同的schema或查询的性能
- 针对应用中某个具体问题的测试
- 为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果。
如果可能，采用生产环境的数据快照做测试。
2.2.1 测试何种指标
在开始执行甚至是在设计基准测试之前，需要先明确测试的目标。
测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。
可以将测试目标细化为一系列的问题，比如，“这种CPU是否比另一种快？”，“新索引是否比当前索引性能更好？”
有时候需要用不同的方法测试不同的指标。比如，针对延迟和吞吐量就需要采用不同的测试方法。
请考虑以下指标，看看如何满足测试的需求。
吞吐量
吞吐量指的是单位时间内的事务处理数。
主要针对在线事务处理（OLTP）的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数（TPS），有些采用每分钟事务数（TPM）。
响应时间或者延迟
这个指标用于测试任务所需的整体时间。
通常可以使用百分比响应时间来替代最大响应时间。
例如，如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒之内完成。
并发性
Web服务器的并发性，是指在任意时间有多少同时发生的并发请求。
并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或连接数，
一个Web站点“同时有50000个用户”访问，却可能只有10～15个并发请求到MySQL数据库。
当并发性增加时，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。
并发性测试不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。
可扩展性
系统的业务压力可能发生变化时，测试可扩展性非常必要。
可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍）。
可扩展性指标对于容量规范非常有用，基于不断增加用户连接的情况下的响应时间测试可以发现应用的瓶颈。
小结
应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，比如，什么样的响应时间是可以接受的，期待多少的并发性，等等。然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标，而忽略其他指标。
2.3 基准测试方法
在了解基本概念后，现在可以具体讨论一下如何设计和执行基准测试。
先来看一下如何避免一些常见的错误，这些错误可能导致测试结果无用或者不精确：
- 使用真实数据的子集而不是全集。例如，应用需要处理几百GB的数据，但测试只有1GB数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。
- 使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）。
- 使用不真实的分布参数，例如假定所有用户的个人信息都会被平均地读取。
- 在多用户场景中，只做单用户的测试。
- 在单服务器上测试分布式应用。
- 与真实用户行为不匹配。
- 反复执行同一个查询。
- 没有检查错误（日志）。
- 忽略了系统预热的过程。
- 使用默认的服务器配置。
- 测试时间太短。
2.3.1 设计和规划基准测试
标准的基准测试
专用的基准测试
针对查询的测试，可以建立一个单元测试集作为初步的测试，并运行多遍。
更好的办法是选择一个有代表性的时间段，比如高峰期的一个小时，或者一整天，记录生产系统上的所有查询。
如果时间段选得比较小，则可以选择多个时间段。
可以在不同级别记录查询。例如，如果是集成测试，可以记录Web服务器上HTTP请求，也可以打开MySQL的查询日期。倘若要重演这些查询，就要确保创建多线程来并行执行，而不是单线程线性地执行。
详细地写下测试规划。测试规划应该记录测试数据、系统配置的步骤、如何测量和分析结果，以及预热的方案等。
应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。
2.3.2 基准测试应该运行多长时间
直到系统稳定为止，读IO和写IO稳定。
如果没有时间去完成准确完整的基准测试，那么已经花费的所有时间都是一种浪费。
2.3.3 获取系统性能和状态
2.3.4 获得准确的测试结果
2.3.5 运行基准测试并分析结果
2.3.6 绘图的重要性
2.4 基准测试工具
2.4.1 集成测试工具
2.4.2 单组件式测试工具
2.5 基准测试案例
2.6 总结
Time waits for no one.