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

我是开拓者，没有前辈了

红温了，我不要测试了

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

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

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

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

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

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

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

好像解决了，放在线程组外面，设定同步为 2，每个线程为 1 请求过去是同时

已解决，为 java 版本太低，之前是 1.6 的升级为 1.8 后问题解决