基准测试是什么？
简单来说，基准测试是则很难对系统设计的一种压力测试，通常的目标是为了掌握系统的行为。但也有其他原因。比如重现某个系统状态，或者是做新硬件的可靠性测试。
为什么需要基准测试
因为基准测试是唯一有效方便的，可以学习系统在给定的工作负载下会发生什么的方法。系统测试可以观察在不同压力下的行为，评估系统的容量，掌握哪些是重要的变化，或者观察系统如何处理不同的数据。
基准测试可以完成的工作：
- 验证系统的假设以及这些假设是否符合实际情况
- 重现并解决系统中的异常行为
- 测试系统当前的运行情况和利用历史的基准测试结果分析一些无法预测的问题
- 模拟比当前系统更高的负载从而找出系统随压力增加而遇到的瓶颈
- 规划未来的业务增长
- 测试应用适应可变环境的能力
- 测试不同的硬件，软件和操作系统配置
- 证明新采购的设备是否配置正确
基准测试的一个主要问题在于其不是真实压力的测试。基准测试施加给系统的压力相对真实压力来说，通常会比较简单，因为真实压力是不可预期而且变化多端的，有时候情况会过于复杂而难以解释。
那么基准测试和真实压力不同在什么地方？
- 数据量，数据和查询的分布
- 但最重要的一点是基准测试通常要求尽可能快完成，所以会给系统造成过大的压力，所以一般都会调整给测试工具的最大压力，一遍系统可以在阈值内完成测试
结论就是，我们只能进行大概的测试，来确定系统大致的余量有多少。当然也可以做一些真实的压力测试，但在构造数据集和压力要特别小心，而且这样就不再是基准测试了。基准测试要简单直接，结果之间相互容易比较
基准测试的策略
两种主要策略：
- 集成式：针对整个系统的整体测试
- 单组件式：单独测试MySQL
针对测试整个系统做集成式测试而不是单独测试的原因有以下几点：
- 因为用户关注的不仅仅是MySQL本身的性能，而是应用整体的性能
- MySQL并非总是应用的瓶颈
- 只有对整体应用做测试，才能发i西安各部分之间的缓存带来的影响
- 集成式测试更能揭示应用的真实表现，而单独组件很难做到这一点
但是集成式测试很难建立，如果基准测试的设计有问题，那么结果就无法反映真实的情况，决策也可能是错的。
所以有的时候不需要了解整个应用的情况，而只需要关注MySQL的性能，至少在项目初期可以这样做，以下情况，可以选择只测试MySQL：
- 需要比较不同的schema或查询的性能
- 针对应用中某个问题的测试
- 为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的”周期循环“
另外，如果能够在真实的数据集上执行重复的查询，那么也是有用的，如果可能，可以采用生产环境的数据快照。不幸的是，设置一个基于真实数据的基准测试复杂而且耗时，而且开发一个新应用，只有很少的数据量，如果想要测试规模扩张后的性能表现，只能通过模拟大量的数据和压力进行
测试何种指标
不同的指标需要用不同的方法测试
以下指标：
- 吞吐量：单位时间内事务处理数。这类基准测试主要是针对在线事务处理（OLTP）的吞吐量，测试的常用单位是每秒或每分钟事务数（TPS/TPM）
- 响应时间或延迟：这个指标用于测试任务所需的整体时间，一般使用百分比响应时间
- 并发性：非常重要但是经常被误解的指标。并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作的线程数或者是连接数。当并发性增加时，需要测量吞吐量是否下降，响应时间是否变长
- 可扩展性：可扩展性不是压力测试的指标，可扩展性指标对于容量规范非常有用，它可以提供其他测试无法提供的信息，来帮助发现应用的瓶颈
归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求，然后基于这些需求去设计基准测试
基准测试的方法
以下是测试的常见错误
- 使用真实数据的子集而不是全集
- 使用错误的数据分布
- 使用不真实的分布参数
- 在多用户场景中，只做单用户的测试
- 在单服务器上测试分布式应用
- 与用户真实行为不匹配
- 反复的执行同一个查询
- 没有检查错误
- 忽略了系统预热的过程，不同状态下测试的结果是不相同的
- 使用默认的服务器配置
- 测试时间太短了，因为基准测试需要持续一定的时间
设计和规划基准测试
- 提出问题并明确目标
- 决定是采用标准的基准测试，还是设计专用的测试
标准的基准测试，应该确认选择了合适的测试方案
设计专用的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照（很容易还原），然后，针对数据运行查询（选择一个有代表性的时间段，如果时间段选择比较小，则可以选择多个时间段，这样有助于覆盖整个系统的活动状态）
3.可以在不同级别记录查询
4.即使不需要创建专用的基准测试，也要写下测试规划（测试数据，系统配置步骤，如何测量和分析结果，以及预热的方案）
5.写一些脚本分析测试结果
基准测试应该运行多长时间
基准测试应该运行足够长的时间，这一点非常重要，应当在稳定状态下测试并观察
一个常见的错误测试方式是，只执行一系列短期的测试。这种不花费足够时间去完成准确完成的基准测试，那么已经花费的所有时间都是一种浪费，所以有时候要相信别人的测试结果，并使用
获取系统性能和状态
可以编写一个shell脚本来记录测试结果，配置文件，测试指标，脚本和其他相关说明都保存在其中
获得准确的测试结果
首先，获得准确测试结果的最好办法，是回答一些关于基准测试的基本问题：
- 是否选择了正确的基准测试
- 是否为问题收集了相关的数据
- 是否采用了错误的测试标准
然后，确认测试结果是否可重复，每次测试之前都要确保系统的状态一致
如果测试过程会修改数据或者schema，那么每次测试前，需要利用快照还原数据
每次测试时修改的数据应该尽可能地小，一般情况下都是通过迭代的方式
|