《软件性能测试、分析与调优实践之路》第7章有哪些常见性能问题分析总结？

1. 性能指标曲线频繁出现大幅度抖动->关注清哥聊技术公众号，了解更多技术文章 如图7-5-1所示，TPS和平均响应时间出现频繁的上下抖动。频繁抖动说明系统并不是一直在稳定地运行，中间会有短暂的停顿，就是持续运行了一段时间后，马上会停顿一下，然后又继续运行，持续地这样交替进行，造成了系统的频繁剧烈抖动。 图7-5-1 造成频繁抖动现象的原因可能有以下几种：（节选自《软件性能测试、分析与调优实践之路》(第2版)，作者张永清，转载请注明出处） （1）系统可能在频繁的出现Full GC。Full GC是Java 应用程序垃圾回收的一种机制，一般如果出现了Full GC，应用程序就会出现短暂的停顿。关于Full GC的介绍，可以参考本书5.1.7小节中的介绍。此时可以先去看一下应用程序的GC日志，如果是Full GC 非常频繁，并且又没有出现内存泄漏，那么可以参考本书5.4.1 小节中介绍的如何减少GC 来解决这个问题。 （2）系统某一次查询、修改或者删除数据耗时很长，导致了整体性能的不稳定。比如，在性能压测查询时，大部分参数化传入的参数，查询出来的结果数据都很少，但是可能某几个参数查询出来的数据量非常大，导致系统在处理这些数据量大的数据时耗时较长。 （3）系统在查询时，可能有时候能命中缓存，有时候命不中缓存。命中缓存时，查询会很快；不能命中缓存时，需要去查询数据库，但是查询数据库的时间肯定比缓存长，所以就会造成系统性能的不稳定。通常情况下数据库也会有缓存，如果命中了数据库的缓存，查询也会更快；如果没有命中，那查询的耗时肯定也会变久。 （4）如果系统是分布式部署，那么可以检查一下分布式处理系统中每个节点的处理能力是否一致，如果不一致，可能也会导致系统频繁抖动。 （5）服务器连接不够用导致的连接批量释放然后再突然批量连接，一旦批量释放连接后，系统TPS马上就会上涨，因为此时可以建立连接了。当连接满了后，请求就无法处理了，从而不得不等待，进而造成TPS突然下降。 2．在提高并发用户数时，系统的TPS和平均响应时间一直无法提升 如图7-5-2所示，当遇到这种情况时，说明系统已经出现了瓶颈，此时可以先去检查服务器的CPU、内存资源的消耗情况。 图7-5-2 通常，检查后会发现应用服务器的CPU、内存等资源都没有达到使用的上限，但是系统却出现了处理的瓶颈，那么说明系统一定是有地方“堵住了”。此时需要继续做如下检查： （1）性能压测时，点击率是否真的上来了。如果点击率或者单位时间内的请求数没有上来，那说明是压测机器无法提供更大压测能力。尤其在大型的分布式系统中，单台压测机往往是不够用的，因为单台压测机不论是网络连接，还是带宽以及自身CPU、内存等都会存在很大限制，性能压测不止是服务器资源会有很大消耗，提供压测能力的压测机也会很大的资源消耗。 （2）检查网络带宽的使用情况，排查瓶颈是否因为网络带宽限制而导致。此时，需要检查网络带宽的环节包括压测机到Web服务器、Web服务器到应用服务器、应用服务器到数据库服务器等所有存在网络请求交互的地方。如图7-5-3所示。（节选自《软件性能测试、分析与调优实践之路》(第2版)，作者张永清，转载请注明出处） 图7-5-3 （3）参考本书5.3.2小节中使用jstack命令行工具，查看Java系统的线程堆栈，从线程堆栈中直接分析当前系统的瓶颈是因为在等待什么资源，而且该资源可能是一个隐形的不容易发现的资源。 （4）如果对于第（3）点运用不熟的话，可以用最笨的方式就是根据请求处理的链路过程，从上而下或者从下而上按顺序去排查。此时需要坚信一点，系统肯定是“堵在什么地方了”，仔细通过checklist去检查，一定能够找到这个“堵住”的位置。这就如同自来水的供水系统一样，如果某个用户突然反馈说，我家自来水水压很小，水压一直都上不去，那么自来水公司的维修人员上门之后，肯定是从这个用户家作为起点，然后对供水链路中的每个环节进行排查，直到找到是哪个环节出现了拥堵。 （节选自《软件性能测试、分析与调优实践之路》(第2版)，作者张永清，转载请注明出处） （5）如果按照前面四点还是找不到问题原因的话，那么可以尝试减少中间环节从而减少不确定因子的影响，再进行压测对比，先确定问题可能的范围，然后再在某个明确的范围内查找具体的原因。比如如图所示，将Web服务器去掉，让压测机的请求直接对应用服务器进行压测。如图7-5-4所示。 图7-5-4 3．在提高并发用户数时，系统的TPS缓慢下降而平均响应时间缓慢上升 如图7-5-5所示，当系统出现TPS下降而平均响应时间缓慢上升，可能是系统已经出现了性能的拐点，达到了最大的处理能力了。