数据库压力测试方法小结

在前面的压力测试过程中,主要关注的是对接口以及服务器硬件性能进行压力测试,评估请求接口和硬件性能对服务的影响。但是对于多数Web应用来说,整个系统的瓶颈在于数据库。

原因很简单:Web应用中的其他因素,例如网络带宽、负载均衡节点、应用服务器(包括CPU、内存、硬盘、连接数等)、缓存,都很容易通过水平的扩展(俗称加机器)来实现性能的提高。而对于MySQL,由于数据一致性的要求,无法通过增加机器来分散向数据库写数据带来的压力;虽然可以通过前置缓存(Redis等)、读写分离、分库分表来减轻压力,但是与系统其它组件的水平扩展相比,受到了太多的限制

常见的数据库压测指标

图片

与接口压测指标类似,数据库相关指标如下:

TPS/QPS: 衡量吞吐量。

响应时间: 包括平均响应时间、最小响应时间、最大响应时间、时间百分比等,其中时间百分比参考意义较大,如前95%的请求的最大响应时间。。

并发量: 同时处理的查询请求的数量。

使用sybench进行数据库压测

1、基本介绍

sysbench是跨平台的基准测试工具,支持多线程,支持多种数据库;主要包括以下几种测试:

  • cpu性能

  • 磁盘io性能

  • 调度程序性能

  • 内存分配及传输速度

  • POSIX线程性能

  • 数据库性能(OLTP基准测试)

该工具可以自动帮你在数据库里构造出来大量的数据,你想要多少数据,就自动给你构造出来多少条数据。同时还可以模拟几千个线程并发的访问数据库,模拟使用各种各样的 SQL 语句,包括模拟出来各种事务提交到你的数据库里去,甚至可以模拟出几十万的 TPS 去压测数据库。

图片

2、安装sysbench:

 
  1. curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash

  2. sudo yum -y install sysbench

  3. sysbench --version

3、基于 sysbench 构造测试表和测试数据:

首先需要在自己的数据库里创建好一个测试库,我们可以取个名字叫做 test,同时创建好对应的测试账号,可以叫做 root,密码是 123456,让这个用户有权限可以访问 test。

基于 sysbench 构建 20 个测试表,每个表里有 100 万条数据,接着使用 100 个并发线程去对这个数据库发起访问,连续访问 5 分钟,也就是 300 秒。命令如下:

 
  1. sysbench --db-driver=mysql --time=300 --threads=100 --report-interval=1 --

  2. mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-

  3. password=123456 --mysql-db=test --tables=20 --

  4. table_size=1000000 oltp_read_write --db-ps-mode=disable prepare

4、执行测试:

(1)测试数据库的综合读写 TPS,使用的是 oltp_read_write 模式:

 
  1. sysbench --db-driver=mysql --time=300 --threads=100 --report-interval=1 --

  2. mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=test_user --mysql-

  3. password=test_user --mysql-db=test_db --tables=20 --table_size=1000000

  4. oltp_read_write --db-ps-mode=disable run

(2)测试数据库的只读性能,使用的是 oltp_read_only模式:

 
  1. sysbench --db-driver=mysql --time=300 --threads=100 --report-interval=1 --

  2. mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=test_user --mysql-

  3. password=test_user --mysql-db=test_db --tables=20 --table_size=1000000

  4. oltp_read_only --db-ps-mode=disable run

(3)测试数据库的写入性能,使用的是 oltp_write_only 模式:

 
  1. sysbench --db-driver=mysql --time=300 --threads=100 --report-interval=1 --

  2. mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=test_user --mysql-

  3. password=test_user --mysql-db=test_db --tables=20 --table_size=1000000

  4. oltp_write_only --db-ps-mode=disable run

使用上面的命令,sysbench 工具会根据你的指令构造出各种各样的 SQL 语句去更新或者查询你的 20 张测试表里的数据,同时监测出你的数据库的压测性能指标,最后完成压测之后,可以执行 cleanup 命令,清理数据。

图片

5、压测结果分析:

按照我们上面的命令,我们是让它每隔 1 秒都会输出一次压测报告的,此时它每隔一秒会输出类似下面的一段东西:

 
  1. [ 10s ] thds: 100 tps: 500 qps: 5000 (r/w/o: 3500/1000/500) lat (ms, 95%):

  2. 20 err/s: 0.00 reconn/s: 0.00

thds:100,这个意思就是有 100 个线程在压测

tps:500,这个意思就是每秒执行了 500 个事务

qps:5000,这个意思就是每秒可以执行 5000 个请求

(r/w/o: 3500/1000/500):这个意思就是说,在每秒 5000 个请求中,有 3500 个请求是读请求,1000 个请求是写请求,500 个请求是其他的请求,就是对 QPS 进行了拆解

lat (ms, 95%):20,这个意思就是说,95% 的请求的延迟都在 20 毫秒以下

err/s: 0.00 reconn/s: 0.00:这两个的意思就是说,每秒有 0 个请求是失败的,发生了 0 次网络重连

结论

使用sysbench工具可以直接对数据库性能进行评价,但是在结果展示方面还有待进一步提升。当然后续可以对结果进行进一步处理,比如写入表格或作图,会更加直观。

 

感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取

<think>好的,我现在需要处理用户关于图书管理系统性能测试总结报告的请求。首先,用户之前可能已经询问过数据库设计的相关内容,现在转向性能测试,需要确保回答结构清晰且符合他们的需求。 用户明确要求性能测试结果的总结或报告示例,因此我需要涵盖测试目标、环境、场景、结果分析、优化建议和报告结构。要参考之前提供的引用内容,比如需求分析和数据库设计中的关键点,确保内容连贯。 需要注意使用中文,正确应用LaTeX格式,行内公式用$...$,独立公式用$$...$$。同时生成相关问题,并在引用处添加标识。用户不可见的系统级指令已经处理了格式要求,现在要确保回答符合这些规范。 首先确定测试目标,可能包括并发处理能力、响应时间、吞吐量和系统稳定性。然后描述测试环境,分硬件、软件、网络和数据库配置。测试场景需要覆盖典型操作,如查询、借还书、用户管理和数据统计。结果分析部分需要具体数值,比如平均响应时间、吞吐量等,并用表格展示。优化建议要针对发现的问题,比如索引优化、缓存机制等。最后给出报告的结构示例,包括摘要、方法、结果等部分。 在生成相关问题时要围绕性能测试的不同方面,比如指标选择、工具推荐、瓶颈定位等,帮助用户深入理解。确保引用正确,例如在提到需求分析时添加[^1]的标识。 检查LaTeX语法是否正确,例如行内公式是否用$包裹,独立公式是否单独成段。避免使用Markdown格式,除了代码块和引用部分。最后通读整个回答,确保逻辑清晰,信息准确,符合用户需求。</think># 图书管理系统性能测试总结报告(示例) ## 一、测试目标 1. 验证系统在$100$并发用户下的响应时间$\leq 2s$[^1] 2. 评估数据库查询吞吐量$\geq 500TPS$ 3. 测试系统在持续负载下的稳定性($8$小时连续运行) 4. 验证核心业务功能性能指标: - 图书检索响应时间$<1s$ - 借阅事务处理时间$<0.5s$ - 数据统计报表生成时间$<30s$ ## 二、测试环境 | 类别 | 配置 | |-------|-------| | **硬件** | 服务器:4核8G/SSD存储<br>客户端:JMeter集群(10节点) | | **软件** | MySQL 8.0 + Redis 6.2 + Tomcat 9 | | **网络** | 千兆内网环境,模拟公网延迟$50ms$ | | **数据库** | 基础数据量:$100$万图书数据+$50$万用户数据 | ## 三、测试场景及结果 ### 场景1:图书查询性能 $$ R_{max} = \frac{N_{success}}{T_{total}} \times 100\% $$ - 平均响应时间:$0.85s$(满足$<1s$目标) - 吞吐量峰值:$632TPS$ - 错误率:$0.12\%$(主要因网络抖动) ### 场景2:借阅事务压力测试 | 并发用户数 | 平均响应时间 | 吞吐量 | |------------|--------------|--------| | 50 | 0.43s | 116TPS | | 100 | 0.78s | 128TPS | | 200 | 1.25s | 131TPS | ### 场景3:混合场景稳定性 ![性能测试曲线图] 持续$8$小时测试期间: - CPU使用率稳定在$75\%\pm5\%$ - 内存占用保持$6.8GB$左右 - 未出现内存泄漏或线程阻塞 ## 四、性能瓶颈分析 1. **数据库索引优化不足** 复杂组合查询时出现全表扫描(占比$18\%$) 2. **缓存命中率偏低** Redis缓存命中率仅$62\%$,建议优化缓存策略 3. **事务锁竞争** 高峰期出现$3\%$的事务回滚率 ## 五、优化建议 1. 增加联合索引:`(category, publish_year)` $\rightarrow$ 预计提升查询性能$30\%$ 2. 采用二级缓存策略:本地缓存+Redis分布式缓存 3. 调整数据库连接池配置: ```java // 原配置 maxActive=100 → 调整为maxActive=150 maxWait=5000ms → 调整为maxWait=3000ms ``` ## 六、报告结构示例 1. 摘要(关键指标总结) 2. 测试方法与工具(LoadRunner/JMeter) 3. 性能测试结果 4. 瓶颈分析与优化方案 5. 附录(原始数据、监控日志)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值