登录接口性能优化日志

本地原始效果吞吐量在10左右，平均响应时长5000ms左右。（机器配置，32g,8核）
经代码优化，主要有以下手段，1.减少服务间的调用请求，2.数据加缓存
代码优化后的效果，吞吐量提升了4倍，响应时间减少了75%

放到线上后查看效果，没想到，差到爆，吞吐量1.9/s,平均相应时间28.9s。无法忍受。
1.原始结果

3.查看系统jvm，发现 cpu跑满. 

 

于是判断，本接口用到jwt生成，消耗较多的cpu资源，因此，cpu资源不足成为接口性能瓶颈

下一步加资源，验证吞吐量
5.将单个pod. cpu加到2核，发现依然跑满正在上传…重新上传取消

6.将pod 副本加为2个2核正在上传…重新上传取消

7加到4个2核

正在上传…重新上传取消

8加到8个2核

正在上传…重新上传取消

9.4个4核,效果不如8

正在上传…重新上传取消转存失败重新上传取消

10.16个1核，效果同8

 

转存失败重新上传取消转存失败重新上传取消

11.20个1核转存失败重新上传取消

12.22个1核

正在上传…重新上传取消

得出结论，该服务需要加解密属于计算密集型，性能跟cpu核心数相关性较高。建议线上环境配置较高的cpu核心数，不过单个cpu调大但减少pod数量，效果不佳。

调整后的10分钟图形显示

正在上传…重新上传取消正在上传…重新上传取消

 
最终效果，登录接口吞吐量在60/s,  响应时间在1.2s之内。即以目前的资源状态，可以支撑5万用户在15分钟内登录，并且体验基本流畅。预计可满足前期并发需求。
未来扩容，如果流量暴增，可以在10分钟内水平扩增资源，完成数倍以上的吞吐量提升。