目录
一、基准测试的方法
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 |
|
其中，执行模式为complex，使用了10个表，每个表有10万条数据，客户端的并发线程数为10，执行时间为120秒，每10秒生成一次报告。
（2）执行测试
将测试结果导出到文件中，便于后续分析。
| 1 |
|
（3）清理数据
执行完测试后，清理数据，否则后面的测试会受到影响。
| 1 |
|
2、测试结果
测试结束后，查看输出文件，如下所示：
其中，对于我们比较重要的信息包括：
queries：查询总数及qps
transactions：事务总数及tps
Latency-95th percentile：前95%的请求的最大响应时间，本例中是344毫秒，这个延迟非常大，是因为使用的MySQL服务器性能很差；在正式环境中这个数值是绝对不能接受的。
3854
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
