下面是一个SaaS平台实际的优化案例，是一个app的登录功能，优化前TPS为十位数，优化之后达到两千以上。
1. 环境配置
生产环境服务器配置：
①nginx:2台4c4g
②api：6台4c4g
③plat：6台4c4g
④mysql:3台8c16g
⑤lvs:2台4c4g
⑥实名:2台
压力机配置:4台8c16g：
网络带宽: 内网带宽万兆
优化内容: 在压力机服务器配置上DNS解析，性有所提高
2. 压测及优化流程
开发环境压测跟踪问题，开发环境压测TPS 为 67.9
1. 初步发现问题：
JSON实例化导致线程Block
解决办法：
将FastJson替换Jackson
优化结果：
TPS由68TPS升为81TPS，稍有提升
2. 继续压测发现大量线程被锁：
KafkaProducer.sendMessage锁问题
com.systoon.jms.kafka.KafkaProducer.sendMessage
发现是kafa的消息发送模式的问题
解决办法：
将Kafka同步消息改异步发送
增加HttpClient 缓存池：
修改前：
修改为：
优化结果：
修改后由81TPS，升为300TPS左右； 提升明显，直接上升一个档次.......
3. 调整后上线一次，在生产环境压测，结果为：
进行400并发tps为165 平均响应时间：2300ms （开发环境与生产环境机器配置及网络环境不同，实际TPS会有一定波动）
经排查，发现问题：
发现JsonPath大量block线程
CPU使用率不足3%
就是说CPU远没有充分利用，但是TPS已经上不去了
Tomcat日志响应时间：
Server.xml
从NGINX监控看到的响应时间高达30S：
数据库SQL响应时间长
并发用户报错
解决方案：
参数化数据+垫底数据 ， 将FastJson替换JsonPath
原JsonPath处理方式：
修改：FastJson
继续优化：
再次上线生产环境，压测，结果：
TPS 由165 直接提升到1300，平均响应时间：2300ms 到300ms
nice ................，但是发现有少量请求提示系统错误
4. 继续排查优化........
优化消息队列消费端，以及清除线上kafka堆积消息，升级jms4.0.4
优化消息队列消费端业务代码：
消费端减少一次dubbo调用和增加缓存，
1000并发1000TPS，升为2000TPS
漂亮...............
继续，优化认证服务的登录逻辑，直接传入id，减少dubbo调用
由 2300TPS，升为2700TPS
but，遇到新问题：
问题分析：
因为共享变量没有加锁，在高并发时，发送消息出现空指针的问题
解决办法：
把共享变量修改为局部变量
修改代码优化结果：
ok，搞定，经过一系列的排查和优化措施，登录接口从67TPS 飙升到 2700TPS，可谓提升非常显著
3. 优化总结
关键性能问题如下：
1. DB端：
- SQL索引有无，起效，筛选率低的字段不需要索引
- select内容
- 读写分离
2. 业务优化：
- Log4j2 异步
- 缓存
- 异步（kafka）
- 简化业务步骤
- Sleep绝对不允许
- 用空间换时间
- 读性能远高于写
此为一个saas平台的登录服务接口的优化过程，系统tps与业务复杂度关系密切，优化方式不尽相同，但都有一定共性的方法，要跟踪整个调用链条，将各个环节的时间都打出来，定位跟踪具体时间是卡在什么环节，然后采取相应措施解决即可。同时尽量简化业务逻辑，减少调用次数，等等......
如果您觉得博主写的文章对您有帮助，可以请博主喝杯茶哦，O(∩_∩)O~
博主：诸葛本不亮
简介：毕业后做过多年程序猿、架构设计、项目经理、部门总监，待过传统软件公司，也在大型互联网公司负责过平台研发部，在这个行业浸淫十多年，在系统架构、SaaS平台搭建、项目管理以及部门管理等方面有着多年的一线实践经验。
目前与好友合伙创办了一个软件工作室，提供各类系统解决方案、咨询服务及技术合作，企业软件（SaaS平台、企业应用、商城、微信公众号及小程序开发）定制开发服务，大数据服务（数据采集及清洗、数据分析等），以及程序猿职业规划及转型咨询服务（程序猿转架构师、转项目管理、转技术管理等，可以提供相应的一线资料帮助您成功转型，获得大厂offer）。
微信号：danwang2138
