一次精疲力尽的压测

记一次精疲力尽的无语压测经历

平台改版，需要新的登录，平台组挑选了red hat开源的keycloak，一个针对现代应用程序和服务的开源身份和访问管理解决方案。

压测主要是进行了接口的压测。
正常流程，脚本编写，执行，监控服务器资源，报告。

但是，这个神奇的接口，每次都是线程到300时候，有一瞬间QPS到达峰值，然后瞬间下降，之后持续一个很稳定的值一直下去，并且伴随着一堆的socket timeout报错。

于是乎，正常的，重测，看CPU
top，vmstat，uptime没啥用，CPU根本没什么反应，三台AP都是50%左右

看内存
free -m也没啥用，一堆限制内存

看磁盘
iostat -dxk 2没怎么写。。

看网络：
看连接
netstat -an | grep 端口 | wc -l貌似也正常的很。。

没办法，继续看内存，定位JVM问题：
jstat PID > 1.log导出dump文件，看一下，有很多block的，暂时不用优化
jmap -dump:live,format=b,file=dump.hprof PID生成堆栈的完整文件，没啥用。。。
jmap -heap PID看当前堆内存使用情况，GC正常，没用。。

然后开始怀疑是自己压测工具的问题，做了jmeter分布式，每台压力机起100个线程，也没什么用。

最后快绝望了，抱着试试看的心态，切到内网地址，那个到峰值之后降下来的情况终于没了（之所以开始不用内网地址测试，是因为之后上正式环境，提供出去的是外网地址，所以测试中，肯定是用外网地址来模拟）。找到了是内外网的区别之后，找运维同事看了网络的区别，得出的结果是外网地址限制了流量。。。阿里云ECS服务器，限制了外网流量是100Mb/s，我们的接口，一个请求大概数据包是2k，并发情况下，流量超出了限制，直接被阿里云服务器限制了访问。。。服气！

所以，压测，不止要关注服务器自己的CPU，内存，磁盘，网络连接，还要看服务器提供商的外部限制。。。