200Vu，前段无异常，后段，吞吐量就掉下来了。想请教原因是什么？
想请教一下，都有哪些原因会导致吞吐量急剧下降？
附图二，求指教。如果说随着用户的增加，吞吐量下降我还能理解，这个跑到一半，突然下降实在不知道是为啥了。
吞吐量不是和虚拟用户成正比吗？突然下降，是到拐点？ 有没有达到系统瓶颈，服务器是否能够处理的了 看你设置的用户跑脚本的逻辑是怎样，如果是设置只跑一次，不循环，有些用户到27分钟就跑完了，在等候退出的话，这时候吞吐量肯定会下降 lin0731032 发表于 2016-6-28 09:02
看你设置的用户跑脚本的逻辑是怎样，如果是设置只跑一次，不循环，有些用户到27分钟就跑完了，在等候退出的 ...
问题是没跑完，还在跑的过程中，吞吐量就掉下来了。 花总丢了金箍棒 发表于 2016-6-28 10:13
问题是没跑完，还在跑的过程中，吞吐量就掉下来了。
200个用户，有些用户跑的快，有些用户跑的慢，懂不？跑的快的结束后，等慢的继续跑完，吞吐量不就降了吗 lin0731032 发表于 2016-6-28 10:20
200个用户，有些用户跑的快，有些用户跑的慢，懂不？跑的快的结束后，等慢的继续跑完，吞吐量不就降了吗
那怎么看200用户同时并发接口呢？多谢。 1、在出现拐点的地方打堆栈，看下代码具体的执行情况
2、看下后台日志有没有报错（如：内存泄漏）
3、数据库监控下，看下是否是数据库的链接数 或者 sql语句执行等问题
4、实时监控网络IO，看下拐点的时候网络是否正常
5、保证性能测试环境干净，没有其他服务占用资源
6、看tps在吞吐量出现拐点的时候没有波动，可能是系统处理到极限了；当有很多事务处于等待状态时，服务器处理能力降低；让开发优化代码
7、。。。。。 一个简单点的猜测，楼主验证一下：后半段吞吐量下降可能是服务器承受不住长时间负载而报错（Http500等错误），此时本该回复的报文体长度从很长变为了0，这导致了接收的急剧下降，解释了图形的变化。
但是以上的猜测有个前提是：脚本没有做检查点。如果检查点没有做判断，也正好解释了吞吐量下降的同时，事务并没有失败。
页:
[1]
