性能常识 记录一下性能测试实战

转圈 · 2024年09月25日 · 最后由 大伟哥 回复于 2024年09月29日 · 5244 次阅读

在网上搜寻性能测试相关信息,大部分都是工具的使用,脚本录制。看了很多但到自己实际压测的时候,还是不知道怎么动手,这次开贴 1.为了自己记录使用 2.想要各路大佬指出压测步骤中错误的地方,让每个想做压测的人都有一个案例可以抄袭

1.压测前景是,最近迭代了一个功能,上级给到指令:进行压测。此次为第一个坑,大部分公司的产品和主管是不会给你一个目标,只会让你去压测,怎么压什么是目标结果是什么,大家都不清楚。基于这种情况自己来罗列目标:首先我通过以往活动情况在 SLB 上看到并发连击数 1.6w 左右,在秒杀活动下达到 2.6w。此次目标为 SLB 达到如此连接数下每个压测场景需要达到 90% 响应时间 2S 以下,ecs 和 rds 内存和 cpu 不超过 70%。吞吐量本人没什么经验不知道如何去估计,只能走一步看一半
2.压测方案,压测工具是用到 jmeter,压测场景以页面为维度,比如进入首页作为一个场景,那首页下的 5 个接口都作为一个场景压测。(这里我也不清楚是否对错,希望有大佬看见能够指点)。再网上了解一台 4 核 8G 的电脑正常就支持 500 个并发,所以会用到阿里云上面的压测工具,这个上面可以支持开多台机器好达到 1w 起步的并发。(公司由于压测不是很平凡,所以没有压测机器给与压测,这块想确认一下:我 slb 到达 2w 是不是一定得让线程数达到这个值)
3.压测环境搭建:这个由运维人员帮助,搭建了一个压测环境,这块不多做描述,对我而言压测环境方便在,我可以关闭接口的验签,然后自己写了一个任意手机号获取 token 的接口,方便自己造数据使用。
4.压测数据准备:会员数据通过准备的测试接口(传手机号返回 token,如果手机号会员不存在则自动创建会员);活动数据直接通过接口调用创建出来。为了避免获取 token 接口影响真实压测数据,先写脚本把所有 token 取出到 csv 文件中给后面压测接口使用

开始压测,首先本地进行压测,压测活动主页场景包含,活动信息查询,子活动列表查询,用户活动参与信息接口,订阅消息模板。本地线程 700 持续 2 分钟:压测结果:SLB 达到 700 连接数,吞吐量总体 200,响应时间 95% 为 12s,异常无。压测结果感人查看了一下,数据库压力直接 100%,应该是这个地方导致,查看了一下索引什么都已经加过了,目前还没有解决方案。等待后续

好消息,找到一个地方没走索引,先加上试试
无敌;加完之后吞吐量达到 1200,之前每个 sql 都要全表扫描 5w 条数据,改完直接一条。感谢索引

共收到 15 条回复 时间 点赞

讲点另外的,其他项目碰见一个问题,客户要求项目可以支持 8w 个人同时使用,以此去做压测,面对这种怎么去安排压测目标,我个人是俩种想法:1.保证吞吐量达到 4w。这样是不是等于 8w 个人同时用可以在俩秒全部处理完。2.线程数拉到 8w 进行压测,保证响应时间在 2 秒内。但这种情况昨天在测试的时候,接口开 50 线程数接口吞吐量可以达到 1000 多,对我理解来说吞吐量!=线程数,线程数左右到底是什么。作为一个测试搞不清楚这些东西,完全不知道压测目标是什么。希望有人能解答

疑问点,接口一单独压测吞吐量可以达到 500,接口二可以达到 1400,接口三可以达到,250,接口四可以达到 81。
四个接口组合一起进行压测单接口都是 80 左右。但这四个接口我并没有开启事务控制器去包裹,这种是不是证明每一个线程都会要求 4 个接口都请求完成才算完成吗。那如果这样的话,事务控制器不就没用了吗

加完事务控制器后效果是:
事务控制器,只是把时间累积起来吗
按个人理解,把这 4 个接口比作一个页面打开的事务,由于这 4 个接口都是各自异步调用,所以整个页面响应时间其实是看没加事务前的总体,

对于你的回复,我有好多不理解的点:第一个相关问题中:吞吐量:设定在并发 2.6 万连接的情况下,每秒请求数达到 1 万次。这个怎么理解,是指 slb 达到 2.6w 链接,我吞吐量可以有 1w 吗。错误率这一块,你有讲到高并发场景,什么是高并发场景,是指我 500 线程持续请求,还是 5000 个请求开同步定时器一起请求

第二个点中,你指出 slb 连接数其实和我的线程没有关系,但我在尝试中本地线程 700 情况下 slb 确实达到 700,而 50 线程下 slb 也只是 50。作为压测过程中,压测人员应该怎么去理解 slb,

” 将首页下的 5 个接口作为一个场景测试 “这个话题下,刚刚也确实发现在场景压测下会出现所有接口慢的情况,最后还是得单个接口去压去找到问题。但这里对我理解来说就成了单接口的负载测试,对于最终客户要求的结果来说,他要的是用户真实的使用情况,用户在实际中肯定是大量大量接口同时请求。这块地方也是我疑惑的点
分布式目前项目还不是没有加入考虑点中,数据库瓶颈的话,对于我只能说是在压测过程中发现数据库压力拉满了,然后查看这段时间的慢 sql,然后去查看执行计划看看有没有用到索引等等。对于数据库连接数我的理解是:如果 ecs 压力大但数据库没有压力,可能是连接数不足导致全部堆积在 ecs。锁的话主要考虑一些新增操作可能存在乐观锁这种,目前还没测试到,如果出现这种情况调优方法是什么,把锁移到 redis 上吗。数据库事务的话,目前工作上好像还没见过数据库的事务,缺乏这方面的经验。
第四点中有讲到带宽的限制,我对这个理解带宽=slb 的入口,只要 slb 还没达到上不去的情况,压力就不在带宽上面。最后是网络延迟的情况,这种是需要考虑用户自身弱网情况还是服务器本身的网络情况,如果需要去考虑的话,应该怎么去做呢。
最后:万分感谢能够回复我的贴子并且给了很多用心的建议解惑。性能测试有好多模糊的概念,对于我这种测试人员很希望有一份标准答案去抄袭。目前没找到这种相关文章,想努力去做成这件事

回到压测,目前压测接口四的时候发现吞吐量只有 80,讲讲我是怎么去定位性能问题,看了 slb 连接数 50,ecs 无异常,看了 rdsCPU 直接 100% 了,好了大概率这里问题,这块 rds 部署在阿里云上面,自带慢 sql 分析,打开分析
慢 sql 全是这条,查看了一下做的业务,于用户下单会有消费金额,主页会显示消费金额排行,由于是实时排名,导致这个接口每次需要把所有人员拉出来做排序得到当前排名。考虑优化方案。方案一:sql 优化,添加索引,查看执行计划已经走了索引方案失败。方案二:把 sql 改成统计大于当前用户消费的数量作为排名,只需要 count() + 金额大于的条件。不知道有没有效果(未成功执行,被方案三覆盖)方案三:产品维度把查看排名做成按钮,点击之后才显示排名,减少每次进入页面的请求次数。同时开发人员写一个定时任务,每隔一段时间统计排名到 redis(会导致排名不是实时的,业务上对实时要求也不高,所以按照方案三执行)。


红温了,我不要测试了😭

转圈 回复

建议你找你们公司的老员工或者上级领导,问下之前的性能测试是怎么做的

转圈 回复

希望坚持记录,这是宝贵的实践,也是你成长的轨迹,可以分享出来大家共同探讨。

转圈 #10 · 2024年09月26日 Author

我是开拓者,没有前辈了

转圈 #11 · 2024年09月26日 Author

又一个情况,另一个项目在压测中,设置线程数是 5000 然后网关炸了。这种情况是不是只有不断加线程数才能压测到

转圈 回复

8 万人同时使用,这八万人不太可能集中去操作的,真的这么高并发量那用户数量都得几千万了。

客户的意思应该是总用户数有 8 万,你应该要确定以下他们同事操作会有多少人,也就是并发度

转圈 回复

性能测试要求的能力挺综合的,我觉得如果你是第一个,那不要想得太复杂了,先做下接口的基准性能测试就行了,不要想着调优,把接口的基准性能报告发给开发,让他们去调,然后再请教

在性能测试中,线程是模拟并发用户行为的关键概念,每个线程代表一个虚拟用户,可以同时执行一组操作,从而模拟多个用户同时访问系统的情景。
如果是前面没有性能测试积累,可以先做简单的单接口并发测试,像 “并发 5000 然后网关炸了” 这种情况就是单接口测试场景。
基于单接口测试的指标前提,可以设计出复杂的性能测试场景,比如 “系统可以支持 8w 在线用户”,不可能 8W 用户同时去请求同一个接口,可以按照一定的比例拆分去做不同的业务,比如有的用户去请求登录,有的用户去请求搜索,有的用户去请求提交订单,有的用户就什么都不做,这块可以参考系统功能模块使用情况分析。这样测试出来的性能指标才是真实有效的。

性能测试要注意的事项:
1.合理设置 Ramp-Up Period:确保系统有足够时间处理逐渐增加的负载,而不是瞬间启动所有线程。
2.使用定时器模拟真实用户行为:添加适当的延迟,以更贴近实际使用情况。
3.监控资源使用情况:在运行性能测试时,监控服务器和网络资源使用情况,以便识别瓶颈和优化点。
4.逐步增加负载进行压力测试:从小规模开始逐步增加负载,观察系统表现,避免突然施加过大压力导致系统崩溃。

转圈 回复

压测中有个概念叫 并发活动占比。也就是每 100 个用户中,有 20 个用户在不断做操作,其余全部静止不动,那么并发度就是 20%。这种实际并发度只能上线后由 OP 统计出来。上线前,一般大家都按照二八法则,也就是 20% 的活动度拍脑袋决定。自己也可以判断一下,比如分钱,秒杀,抢房子,那参与度自然高,比如 50%-70% 都可能,如果只是看文档,那么可能 5% 都不到。

其实,第一次压测,只能基于猜测,也就是拉个基线就可以了。反而是后续的补丁才是每次都要跟基线对比才是。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册