0


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服务器性能很差;在正式环境中这个数值是绝对不能接受的。

标签: 学习 测试工具

本文转载自: https://blog.csdn.net/zlzlzlc/article/details/124743265
版权归原作者 今天你AC了没 所有, 如有侵权,请联系我们删除。

“benchmark学习笔记(第三篇)”的评论:

还没有评论