在网上搜寻性能测试相关信息，大部分都是工具的使用，脚本录制。看了很多但到自己实际压测的时候，还是不知道怎么动手，这次开贴 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 条数据，改完直接一条。感谢索引
我对性能测试也不是很了解，大致说下可能的点，不一定对，得求助下社区里的性能大佬
- 相关问题点：
吞吐量目标和 RPS 未明确，只提到响应时间和资源利用率。目标需要更清晰，应该包括每个服务节点的目标：如最大并发量、各节点的 CPU 和内存使用率、网络带宽占用、响应时间等
例如：
吞吐量：设定在并发 2.6 万连接的情况下，每秒请求数达到 1 万次。
响应时间：95% 的请求响应时间在 2 秒以内，99% 的响应时间在 3 秒以内。
错误率：确保在高并发场景下，错误率小于 0.1%。
资源利用率：ECS 和 RDS 的 CPU、内存、网络和磁盘 IO 使用率不超过 85%。
建议：明确测试目标，结合业务需求，量化吞吐量、响应时间、错误率和资源使用率的具体指标
2.相关问题点
SLB 达到 2w 是不是一定得让线程数达到这个值”
你混淆了并发连接数和线程数这两个概念，【并发连接数】这是指在同一时刻，客户端与服务器之间同时保持的连接数量，【线程数】这是指在工具中模拟的虚拟用户数。一个线程可以发起多个请求，也可以维持多个连接，或者快速发起请求后释放连接，SLB 只关心有多少个客户端连接到服务器，如何分发这些连接，并不会关心这些请求背后是由多少个线程发起的。建议从较低的线程数开始测试，并逐步增加，观察每个节点的 CPU、内存、网络、磁盘 IO 等资源情况
将首页下的 5 个接口作为一个场景测试
2.1 每个接口的压力和负载情况不同，放在同一个场景中测试会混淆每个接口的性能结果，难以单独定位具体哪个接口是性能瓶颈。比如某些接口可能是高负载接口，而其他接口可能只是简单的静态数据返回。
2.2 在分布式系统中，不同的接口可能被路由到不同的服务节点。如果这些接口在同一场景下压测，可能会掩盖某个节点的性能瓶颈
3.数据库瓶颈
数据库性能的瓶颈不仅仅是索引，还包括并发连接数、锁等待、事务处理等问题
4.其他想到的琐事
你没有模拟网络延迟和带宽限制。网络延迟和带宽限制会影响系统性能，应在测试中模拟不同网络条件，评估系统在复杂网络环境下的表现
测试中应模拟部分节点失效的场景，查看负载均衡器是否能迅速剔除故障节点，并将流量引导至其他健康节点
讲点另外的，其他项目碰见一个问题，客户要求项目可以支持 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（会导致排名不是实时的，业务上对实时要求也不高，所以按照方案三执行）。
红温了，我不要测试了
又一个情况，另一个项目在压测中，设置线程数是 5000 然后网关炸了。这种情况是不是只有不断加线程数才能压测到
转圈
回复
8 万人同时使用，这八万人不太可能集中去操作的，真的这么高并发量那用户数量都得几千万了。
客户的意思应该是总用户数有 8 万，你应该要确定以下他们同事操作会有多少人，也就是并发度
转圈
回复
性能测试要求的能力挺综合的，我觉得如果你是第一个，那不要想得太复杂了，先做下接口的基准性能测试就行了，不要想着调优，把接口的基准性能报告发给开发，让他们去调，然后再请教
在性能测试中，线程是模拟并发用户行为的关键概念，每个线程代表一个虚拟用户，可以同时执行一组操作，从而模拟多个用户同时访问系统的情景。
如果是前面没有性能测试积累，可以先做简单的单接口并发测试，像 “并发 5000 然后网关炸了” 这种情况就是单接口测试场景。
基于单接口测试的指标前提，可以设计出复杂的性能测试场景，比如 “系统可以支持 8w 在线用户”，不可能 8W 用户同时去请求同一个接口，可以按照一定的比例拆分去做不同的业务，比如有的用户去请求登录，有的用户去请求搜索，有的用户去请求提交订单，有的用户就什么都不做，这块可以参考系统功能模块使用情况分析。这样测试出来的性能指标才是真实有效的。
性能测试要注意的事项：
1.合理设置 Ramp-Up Period：确保系统有足够时间处理逐渐增加的负载，而不是瞬间启动所有线程。
2.使用定时器模拟真实用户行为：添加适当的延迟，以更贴近实际使用情况。
3.监控资源使用情况：在运行性能测试时，监控服务器和网络资源使用情况，以便识别瓶颈和优化点。
4.逐步增加负载进行压力测试：从小规模开始逐步增加负载，观察系统表现，避免突然施加过大压力导致系统崩溃。
转圈
回复
压测中有个概念叫 并发活动占比。也就是每 100 个用户中，有 20 个用户在不断做操作，其余全部静止不动，那么并发度就是 20%。这种实际并发度只能上线后由 OP 统计出来。上线前，一般大家都按照二八法则，也就是 20% 的活动度拍脑袋决定。自己也可以判断一下，比如分钱，秒杀，抢房子，那参与度自然高，比如 50%-70% 都可能，如果只是看文档，那么可能 5% 都不到。
其实，第一次压测，只能基于猜测，也就是拉个基线就可以了。反而是后续的补丁才是每次都要跟基线对比才是。