在这里要强调一下，性能测试不是用Jemter和Loadrunner等工具，模拟几个用户跑个场景，再导出个测试报告，然后出去跟人家说我会压力测试。这是丢人的，人家都笑话你。 完整的压测流程：业务场景->性能指标->测试策略->性能脚本->分析系统->问题定位->性能报告。话题跑偏了，言归正传，今天的话题是【压力测试瓶颈分析】，服务端出现性能瓶颈，分析思路如何展开。一、压测目的
观察系统的负载能力，测试系统在高负载的情况下的稳定性，评估系统当前的性能情况，解决性能的瓶颈。
二、服务端常见问题
CPU性能瓶颈有两种情况：
CPU高、TPS低和CPU低、TPS也低
有同学问：“不是还有CPU低，TPS高的情况吗”，这个情况不就是CPU没有压力，性能达标呗。
分析过程：
先定位进程->查看哪个进程使用率较高，找到被测服务的进程号->分析进程中，资源使用率高的线程->导出对应的线程日志，进程定位具体的原因。
思路图
内存性能瓶颈表现为两种：
内存泄露和内存溢出
引起内存泄露和溢出的原因如下：
分析内存的过程：
查看内存资源->判断Gc的回收是否异常->导出内存日志->分析具体的泄露对象。
常见的分析工具：MAT、profile、ha456.jar
思路图
注意
大多数的中小型公司，对于性能的要求偏低，甚至不要求性能。这类公司大多业务形态散，迭代较快、市场占有率低。即使遇到性能问题，不愿意花费时间和人力成本，进行性能调优。一般通过加服务解决问题，对应了那句“通过钱能解决的事都不是事”。建议大家挑选性能相关工作，一定要找大厂，一定要找大厂，一定要找大厂。大厂让你施展才华的机会才会更多。
总结
1、性能调优和性能定位的原则，每次只改一处。改完后进行回归，如没有解决问题，回滚到修改前，再次寻找可能出现的问题点进行优化再回归
2、性能问题跟很多的因素有关，问题可能出现在任何节点，可能是程序，可能是中间件，也可能是配置的原因。所以在定位问题的时候，一定要熟悉数据的流转，这样你在排查问题的时候，脑子才能保持清醒。
