tps趋势变化、响应时间多少，怎样的现象才叫问题。

第一阶段

对公网上的测试来说，基本上压力都会在网络上，因为出入口带宽会成为瓶颈，所以先要看一眼自己的带宽用到了多少，再比对一下出口路由上的带宽。
image.png
这里 1Gbps 只用到了 0.01%，也就是 (1000/8)x0.01%=12.5k（这里是将带宽 bit 换成 byte 计算）。在这样的带宽使用率之下，即使是公网也不见得会有问题，更别说在内网了。可见带宽不是瓶颈点
带宽现在看到用得并不多，但 TPS 也上不去。首先应该想到的场景就是把 TPS 曲线给做出梯度来。
响应时间一定是从低到高慢慢增加的；TPS 一定也是从低到高慢慢增加的，并且在前面的梯度中，可以和线程数保持正比关联。举例来说，如果 1 个线程 TPS 是 10，那 2 个线程的 TPS 要在 20。依次类推

第二阶段

将 Ramp-up 再放缓，改为 300 秒。这一步是为了将梯度展示出来。将粒度改小，JMeter 默认是 60 秒，这里改为 1 秒。这一步是为了将毛刺显示出来。强调一点，如果不是调优过程，而是为了出结果报告的话，粒度可以设置大一些。至于应该设置为多大，完全取决于目标。
一般情况下，我们在调试脚本的时候会打印日志，因为要看到请求和响应都是什么内容。但是压力过程中，基本上我们都会把日志关掉。一定要记住这一点，不管是什么压力工具，都要在压力测试中把日志关掉，不然 TPS 会受到很严重的影响。

压力越大，曲线的毛刺就会越多，所以在 TPS 达到 6000 以上后，后面的 TPS 在每增加一个线程，都会出现强烈的抖动。在这种情况下，我们再往下做，有两条路要走，当然这取决于我们的目标是什么。接着加压，看系统什么时候崩溃。做这件事情的目标是找到系统的崩溃点，在以后避免出现。将线程最大值设置为 10，增加 ramp up 的时间，来看一下更明确的递增梯度，同时分析在线程增加过程中，系统资源分配对 TPS 的影响，以确定线上应该做相对应的配置。
我们通过对曲线的不合理性做出判断，你需要记住以下三点：

  • 性能分析中，TPS 和响应时间的曲线是要有明显的合逻辑的趋势的。如果不是，则要降线程，加 Ramp-up 来让 TPS 趋于平稳。
  • 我们要对曲线的趋势敏感，响应时间的增加不可以过于陡峭，TPS 的增幅在一开始要和线程数对应。
  • 当 TPS 和响应时间曲线抖动过于强烈，要想办法让曲线平稳下来，进而分析根本原因，才能给出线上的建议配置。