按照测试方案的基准场景的设计步骤,先压测这个接口的基准场景。
如上图所示,这现象老明显了。
压测结果中的 TPS 平均才 25 平均响应时间达到了 993 ms。
链路路径主要为:JMeter-Nginx-APP SVC-Redis-MySQL
从性能分析逻辑上来说,针对响应时间长的问题,首先要做的就是拆分时间。由于这个系统已经部署了 SkyWalking,用它看看时间主要消耗在了哪里。
看图中,Tomcat 的 SelfDuration 是最多的,也就是说时间几乎消耗在服务本身。
首先查看下应用服务器的资源水位情况:
可以看到 4C 的 CPU 资源已经被耗光。
这里部署的是容器,先看下各容器资源使用情况:
可以看到资源主要被服务容器消耗了。
首先进入服务容器查看下资源消耗情况:
在 SkyWaking 中又看不到完整的调用栈,考虑直接连到服务 Java 进程中看方法的时间消耗。这里用 Arthas 来跟踪一下。
查看当前最忙的前N个线程并打印堆栈:
这里为程序的业务代码。
于是 trace attemptAuthentication 这个方法。
接着trace authenticate 这个方法。
一层层跟踪下去,最终来到了这里:
既然这个 crypt_raw 方法耗时比较长,那就反编译源代码看看这一段是什么东西。
image.png
可以看到这里是一个加密算法 BCrypt,那么结论就很明显了 BCrypt 加密算法虽然安全性高,但性能差。
这里使用 SpringBoot 实现 MD5加密和 BCrypt 加密的实例。
JMeter 并发20 MD5 加密结果:
JMeter 并发20 BCrypt 加密结果:
这里解释一下,Bcrypt 在加密时,每一次 HASH 出来的值是不同的,所以特别慢!
具体什么是 Bcrypt 算法,可以参考这篇文章:https://www.jianshu.com/p/2b131bfc2f10
分析到这里,优化方案其实比较明确了,那就是用更快的加密方式,比如 MD5,或者去掉这个加密算法。