当我们开始做性能测试的时候，一定要得出结论，并且能给出优化方案和具体实施才可以，否则都是空谈。
今天介绍几个具体的案例，可以给刚入门做性能测试的同学一点启发。
如何判断已经达到系统瓶颈？
做性能压测的时候，把并发线程数按照阶梯式不断累加上去，观察cpu是否有达到80%以上。
如果有，即已经达到系统瓶颈，此时也不用再压下去，压下去只会把系统打爆掉，应该去查看此时的TPS是否满足预期，如果满足预期设定的值，则可以不用考虑隐患（前提是预期值要设置的合理），如果不满足预期的TPS，就需要根据具体性能瓶颈，提出优化改进建议。
而优化改进建议就通过观察是哪个地方的瓶颈最明显，最值得修改，就对该地方作出优化，比如RDS、连接池、Redis、代码逻辑、系统配置、JVM服务等等。
粗略几个影响点：
-
系统内存容量太小–影响系统性能
-
算法过于繁琐–影响系统性能
-
慢sql–影响RDS性能
-
数据库连接过多，超出容量–影响系统的连接池性能
-
redis请求过多–影响Redis性能
如何分析瓶颈所在？
首先遇到TPS低于20，RT大于2000ms的压测结果，那么肯定不是一个正常的结果，此时要观察各个服务的指标情况。
根据时间区间，在pinpoint上面看接口请求分布，拉到具体的接口分布列表，查看当前测试接口的详情，查看调用链路是有哪些。
根据调用链路，可以看到有做了数据库的连接（涉及到连接池），有查询redis，或者还有系统算法的内容。
根据每个环节的耗时，有没有耗时特别长的，比如大于100ms的那种，比如连接数据库时间特别长，那么就可能是在连接池连接的时候较慢，原因是并发数太多，容量不够，排队等待的时间太久了。
给出建议：需要增加连接池的容量。
也可以查看系统cpu的情况，根据cpu占比中的系统或者JVM的占比是否异常高，如果是系统的占比异常高，则可能是代码中算法复杂，比如if循环较多。
除了cpu，还有可能是其他指数会有异常飙高。
看得多不如操作一把来的快，最好的方式就是自己写一个程序自己做性能测试，然后通过优化代码和慢sql等等，观察性能是不是好起来了，实践出真知。
最后给大家准备了一份软件测试资料包！
以上内容，对于软件测试的朋友来说应该是最全面最完整的备战仓库了，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。有需要的想伙伴可以关注公众号：程序员二黑，免费领取！
加油吧，测试员！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。
未来的你肯定会感谢现在拼命的自己！