你好，我是小牛，目前在一家准一线互联网大厂做测试开发工程师。
对于一般公司普通测试工程师来说，可能性能测试做的并不是很复杂，可能只是编写下脚本，做个压测，然后输出报告结果，瓶颈分析和调优的事都丢给开发去做。
在一些大厂都有专门的性能测试团队去定位分析系统性能瓶颈，并进行调优。
但是，这并不意味着对于那些不想进大厂或者限于学历暂时无法进入大厂的人学习性能测试就没有意义了。
相反，我觉得很有意义，首先，做性能测试有利于你更好的理解系统架构以及整个链路数据的流转调用情况，从而加深你对业务的理解，更好的进行手工业务测试。
其次，学好性能测试对于你跳槽找工作面试来说是一大利器。之前不止一次提过，对于想拿高薪或者想进大厂的同学来说，其实就是看你编程，自动化，性能这几块掌握的怎么样。
至于其它工具使用，测试思维说实话都比较虚，也比较基础，没什么亮点。
那么接下来详细聊聊如何定位分析性能瓶颈，并调优呢？首先，说一下相对专业一些的性能测试在压测之前一般是怎么做的？
压测之前，一般会先对各个数据流转系统做好监控，比如服务器硬件资源cpu，磁盘，网络，io以及数据库服务器，数据库连接数，是否有sql慢查询，包括线程状态，JVM，中间件redis，nginx等等做监控。
关于如何做监控就看公司性能测试这块投入成本和建设的怎么样了，比如有的公司有自己的监控平台，可以同时监控很多东西。
像一些规模不大的团队简陋一点的可以借助于现有的开源平台和工具做监控。
比如Grafana+Prometheus可以监控服务器操作系统资源和数据库。jvisualvm可以监控JVM和线程状态，包括线程阻塞，死锁等等。nmon可以监控linux服务器，cpu，磁盘，内存，网络等。
除了这些工具还可以使用一些命令来做一些简单监控，比如监控cpu可以用top命令，内存用free命令等。监控中间件redis可以用info命令，监控nginx连接数使用netstat命令等等。
为什么讲性能瓶颈分析之前要先讲监控呢？
原因很简单，监控就像是人的眼睛一样，或者说就像是做手工测试时定位分析bug需要先去看日志报什么错一样，那么一通百通，性能测试问题瓶颈定位分析也是如此。遇到问题需要结合监控来看。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】
下面列几个经常遇到的性能测试问题定位分析思路，抛转引玉~
一.TPS压上不去什么原因，怎么排查？
这个原因比较多，压测整个链路上任何一个环节有瓶颈或者问题都有可能导致
- 首先是压力机压力不够，比如用我们笔记本基本压不到那么高TPS， 所以我们公司有自己的压测平台，分布式集群压测。
- 网络带宽，单位时间内网络传输数据量过大，超过带宽处理能力
- 数据库连接数太少，最大连接数不够
- Cpu，内存，磁盘硬件资源达到瓶颈
- 中间件redis也有可能存在瓶颈比如缓存穿透，缓存过期等等
- 存在大量线程阻塞，线程死锁等
- 中间件消息队列拥堵
这个定位分析方法其实就是结合监控一个一个去排查，查看究竟哪条链路有问题，这也是性能测试比较复杂或者难的地方，需要你对每一个组件和链路都懂，然后还需要大量经验积累，才能在最短的时间内找到问题所在。
二.响应时间过长，什么原因怎么分析？
一般响应时间过长有下面几个原因：
- 服务器硬件资源cpu，内存，磁盘达到瓶颈，可以使用监控命令排查
- 网络问题导致，比如丢包，带宽不够等等
- 线程出现死锁，阻塞等问题可以用jstack查看
- 中间件比如mq消息队列拥堵排队等
- 数据库层面sql不够优化，没有索引，联合索引失效等，数据库连接数不够。
关于响应时间这个问题定位分析，我们还可以使用jprofiler工具去统计每个方法耗费时间定位到代码级别
三.压测过程中cpu过高或者飙升如何定位分析？
- 使用了复杂的算法，比如加密，解密。
- 压缩，解压，序列化操作。序列化可以把Gson组件换成fastjson提升 性能
- 代码bug，死循环。
下面是定位分析过程，尽量定位到代码级别再去开发看问题。
- 查找进程，使用top命令进行排序查找出占用cpu最高的java进程
- 根据进程查找对应线程，使用top-H –p<pid>查看线程占用情况
- 使用jstack命令查询线程堆栈信息，定位到代码级别，Jstack<pid>|grep –a 线程id
以上，就是性能测试瓶颈分析的一些定位思路，供大家参考。
END今天的分享就到此结束了，点赞关注不迷路~
