测试何种指标
在开始执行甚至是在设计基准测试之前需要先明确测试的目标测试目标决定了选择什么样的测试工具和技术以获得精确而有意义的测试结果可以将测试目标细化为一系列的问题比如这种CPU 是否比另外一种要快？或新索引是否比当前索引性能更好？
有时候需要用不同的方法测试不同的指标比如针对延迟（latency）和吞吐量（throughput）就需要采用不同的测试方法
请考虑以下指标看看如何满足测试的需求
吞吐量
吞吐量指的是单位时间内的事务处理数这一直是经典的数据库应用测试指标一些标准的基准测试被广泛地引用如TPCC（参考http://wwwtpcorg）而且很多数据库厂商都努力争取在这些测试中取得好成绩这类基准测试主要针对在线事务处理（OLTP）的吞吐量非常适用于多用户的交互式应用常用的测试单位是每秒事务数（TPS）有些也采用每分钟事务数（TPM）
响应时间或者延迟
这个指标用于测试任务所需的整体时间根据具体的应用测试的时间单位可能是微秒毫秒秒或者分钟根据不同的时间单位可以计算出平均响应时间最小响应时间最大响应时间和所占百分比最大响应时间通常意义不大因为测试时间越长最大响应时间也可能越大而且其结果通常不可重复每次测试都可能得到不同的最大响应时间因此通常可以使用百分比响应时间（percentile responsetime）来替代最大响应时间例如如果% 的响应时间都是 毫秒则表示任务在% 的时间段内都可以在 毫秒之内完成
使用图表有助于理解测试结果可以将测试结果绘制成折线图（比如平均值折线或者% 百分比折线）或者散点图直观地表现数据结果集的分布情况通过这些图可以发现长时间测试的趋势本章后面将更详细地讨论这一点
并发性
并发性是一个非常重要又经常被误解和误用的指标例如它经常被表示成多少用户在同一时间浏览一个Web 站点经常使用的指标是有多少个会话注然而HTTP协议是无状态的大多数用户只是简单地读取浏览器上显示的信息这并不等同于Web 服务器的并发性而且Web 服务器的并发性也不等同于数据库的并发性而仅仅只表示会话存储机制可以处理多少数据的能力Web 服务器的并发性更准确的度量指标应该是在任意时间有多少同时发生的并发请求
在应用的不同环节都可以测量相应的并发性Web 服务器的高并发一般也会导致数据库的高并发但服务器采用的语言和工具集对此都会有影响注意不要将创建数据库连接和并发性搞混淆一个设计良好的应用同时可以打开成百上千个MySQL 数据库服务器连接但可能同时只有少数连接在执行查询所以说一个Web 站点同时有 个用户访问却可能只有 ～ 个并发请求到MySQL 数据库
换句话说并发性基准测试需要关注的是正在工作中的并发操作或者是同时工作中的线程数或者连接数当并发性增加时需要测量吞吐量是否下降响应时间是否变长如果是这样应用可能就无法处理峰值压力
并发性的测量完全不同于响应时间和吞吐量它不像是一个结果而更像是设置基准测试的一种属性并发性测试通常不是为了测试应用能达到的并发度而是为了测试应用在不同并发下的性能当然数据库的并发性还是需要测量的可以通过sysbench 指定 或者 个线程的测试然后在测试期间记录MySQL 数据库的Threads_running 状态值在第 章将讨论这个指标对容量规划的影响
可扩展性
在系统的业务压力可能发生变化的情况下测试可扩展性就非常必要了第 章将更进一步讨论可扩展性的话题简单地说可扩展性指的是给系统增加一倍的工作在理想情况下就能获得两倍的结果（即吞吐量增加一倍）或者说给系统增加一倍的资源（比如两倍的CPU 数）就可以获得两倍的吞吐量当然同时性能（响应时间）也必须在可以接受的范围内大多数系统是无法做到如此理想的线性扩展的随着压力的变化吞吐量和性能都可能越来越差
可扩展性指标对于容量规范非常有用它可以提供其他测试无法提供的信息来帮助发现应用的瓶颈比如如果系统是基于单个用户的响应时间测试（这是一个很糟糕的测试策略）设计的虽然测试的结果很好但当并发度增加时系统的性能有可能变得非常糟糕而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题
一些任务比如从细粒度数据创建汇总表的批量工作需要的是周期性的快速响应时间当然也可以测试这些任务纯粹的响应时间但要注意考虑这些任务之间的相互影响批量工作可能导致相互之间有影响的查询性能变差反之亦然
归根结底应该测试那些对用户来说最重要的指标因此应该尽可能地去收集一些需求比如什么样的响应时间是可以接受的期待多少的并发性等等然后基于这些需求来设计基准测试避免目光短浅地只关注部分指标而忽略其他指标
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
