benchmark学习笔记（第三篇）

一、基准测试的方法

1.避免一些常见错误

• 只使用部分数据。例如应用需要处理几百GB的数据，但测试只使用1GB数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅增长后的情况。
• 使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）。
• 使用不真实的分布参数，假定所有用户的个人信息都会平均的读取。
• 在多用户的场景中，只做单用户的测试。
• 在单服务器上测试分布式应用。
• 与真实用户行为不匹配。例如Web页面中的”思考时间“。真实用户在请求道一个页面后，会阅读一段时间，而不是不停顿的一个接一个点击相关链接。
• 反复执行同一个查询。真实的查询时不尽相同的，这可能导致缓存命中率降低。而繁芜执行同一个查询，在某种程度上，会全部或者部分缓存结果。
• 没有检查错误。如果测试的结果无法得到合理的解释，比如一个本应该是很慢的查询突然变快了，就应该检查是否是有错误产生。基准测试后，一定要检查一下错误日志，这是基本要求。
• 忽略了系统预热（warm up）的过程。例如系统重启后马上进行测试。有时候需要了解系统重启后需要多长时间才能达到正常的系统容量，需要特别留意预热的时间。反过来说，如果想分析正常的性能，需要注意，基准测试在重启后马上启动，则缓存是冷的，没有数据，这时候即使测试的压力相同，得到的结果和缓存已经装满数据时是不同的。
• 使用默认的服务器配置。
• 测试时间太短。基准测试需要持续一定时间。

只有避免了上述错误，才能走上改进测试质量的漫漫长路。

如果其他条件相同，就应该努力使测试尽可能的真实应用的情况。当然，有时候和实际情况晒为有些出入问题也不大。例如，实际应用服务器和数据库服务器分别部署在不同的机器。如果采用和实际部署完全相同的配置当然更真实，但也会引入更多变化，比如网路负载和速度。在单一节点上运行测试相对容易，在某些情况下结果也可以介绍，那么就在单一节点上进行测试。当然，这样的选择需要根据实际情况来分析是否合适。

2. 设计和规划基准测试

规划基准测试的第一步是提出问题并明确目标。确定是对整个系统还是某一组件进行测试，使用什么样的数据，并准备基准测试及数据收集脚本（CPU使用率、IO、网络流量、状态与计数器信息等）。

3. 获取系统性能和状态

执行基准测试时，需要尽可能的多手机测试系统的信息。最好为基准测试建立一个目录，并且没执行议论测试，都创建单独的子目录，将测试结果、配置文件、测量指标、脚本和其他相关说明保存在其中。及时有些结果目前不需要，也应该保存下来。多余一些数据总比缺乏重要的数据要好，多余的数据以后或许用得着。需要记录数据包括系统状态和性能指标，诸如CPU使用率、磁盘I/O、网络流量、应用状态。

4．获得准确的测试结果

获得准确测试结果的最好办法，是回答一些基准测试的基本问题

• 是否选择了正确的基准测试？
• 是否为问题收集了相关数据？
• 是否采用了错误的测试标准（比如是否对一个I/O密集型应用，采用了CPU密集型测试标准）

接着，确认测试结果是否可重复性。每次重新测试前，确保系统状态是一致的。如果是非常重要的测试，需要每次测试都重启系统。如果测试过程修改数据或者schema，那么每次测试前，需要利用快照还原数据。在表中插入1000条和插入100万条记录，测试结果肯定不同。数据碎片度和磁盘上的分布，都可能导致测试时不可重复的。

要注意的因素很多，包括外部的压力、性能分析和监控系统、详细的日志记录、周期性作业。例如，测试过程中突然有cron定时作业启动，或者RAID卡启动了定时的一致性检查。需要确保基准测试过程中所需要的资源是专用于测试的。如果有其他额外的操作，会消耗网络带宽，或者测试基于的是其他服务器共享的SAN存储，那么得到的结果可能是不准确的。

每次测试中，修改的参数应该尽量少。如果必须要一次修改多个参数，那么可能会丢失一些信息。有些参数依赖其他参数，这些参数无法单独修改。有时候甚至没有意识到这些依赖，这给测试带来了复杂性。

5. 运行基准测试并分析结果

基准测试通常需要运行多次。具体需要运行多少次看对结果的计分方式，以及测试的重要程序。一般取最好值或平均值，亦或5次测试中最好的三个值的平均值。

获得测试结果后，需要对结果进行分析，也就是把数字变成知识。最终的目的是回答在设计测试时的问题。

6. 绘图的重要性

简单有效的图形，就是将性能指标按照时间顺序绘制。通过图形可以理解发现一些问题，而这些问题再原始数据中却很难被注意到。或许你会坚持看测试工具打印出来的平均值或其他汇总过的信息，但平均值有时候是没有用的，他会掩盖掉一些实际情况。

二、 基准测试工具

1. 集成测试工具

• Apache Benchmark（即ab）

只能测试单一域名

• http_load

可以测试多个域名，并随机选择进行测试

• JMeter

更复杂，可以设置参数众多，能够更加灵活的monitor真实用户访问，并有绘图接口、还可以对测试进行记录，离线重演测试结果。支持压测多种不同应用。

• siege

能够模拟比http_load更大的负载，并支持延迟、随机等特性，可以更好的模拟真实用户请求，仅用于Web服务测试。

2. 单组件式测试工具

• TPCC-MySQL

Percona出品，主流MySQL压测

• sysbench

主流MySQL压测，支持Lua脚本，同时还支持操作系统和硬件的硬件测试。

三、benchmark的使用

1.sysbench使用举例

（1）准备数据

1

sysbench ./tests/include/oltp_legacy/oltp.lua 

--mysql-host=192.168.10.10 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 prepare

其中，执行模式为complex，使用了10个表，每个表有10万条数据，客户端的并发线程数为10，执行时间为120秒，每10秒生成一次报告。

（2）执行测试

将测试结果导出到文件中，便于后续分析。

1

sysbench ./tests/include/oltp_legacy/oltp.lua 

--mysql-host=192.168.10.10 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --oltp-test-mode=complex --oltp-tables-count=10 --oltp-table-size=100000 --threads=10 --time=120 --report-interval=10 run >> /home/test/mysysbench.log

（3）清理数据

执行完测试后，清理数据，否则后面的测试会受到影响。

1

sysbench ./tests/include/oltp_legacy/oltp.lua 

--mysql-host=192.168.10.10 --mysql-port=3306 --mysql-user=root --mysql-password=123456 cleanup

2、测试结果

测试结束后，查看输出文件，如下所示：

其中，对于我们比较重要的信息包括：

queries：查询总数及qps

transactions：事务总数及tps

Latency-95th percentile：前95%的请求的最大响应时间，本例中是344毫秒，这个延迟非常大，是因为使用的MySQL服务器性能很差；在正式环境中这个数值是绝对不能接受的。