如何从性能分析与调优视角重新审视性能测试？

《软件性能测试分析与调优实践之路》(第2版) 是清华大学出版社出版的一本图书，作者为张永清，全书共分为9章，如下图所示 图书介绍：《软件性能测试分析与调优实践之路》(第2版)->关注清哥聊技术公众号，了解更多技术文章 本文是接着 《软件性能测试分析与调优实践之路》(第2版) 读书笔记（一）总体介绍（上）-真正从性能分析与调优来看性能测试 继续往下讲。 6）、性能分析与调优实践（索引与分库分表） 分库分表时，插入数据时，可以按照如下图所示的方式来进行分库分表的写入数据。 查询数据时可以按照如下图所示的方式来进行查询，下图中的路由表非常的关键，用于能快速的定位到需要查询的数据是在哪个分库和分表中。 7）、性能分析与调优实践（层层过滤） 　　层层过滤的重点如下： 在不同的层级尽可能过滤掉对应层级的所有该过滤的无效请求，让最末端进入到数据库中的请求都是有效的请求。 错误前置，提前抛出异常。对于异常的请求，越早抛出异常，越有利于减轻系统的处理能力和节省资源的占用。 避免重复请求以及通过机器人的恶意请求，从而降低系统的处理压力，更好的保护系统。《软件性能测试分析与调优实践之路》(第2版) 读书笔记 7、性能分析与调优实践（常见性能问题） 1）、性能指标曲线频繁出现大幅度抖动 （1）系统可能在频繁的出现Full GC。Full GC是Java 应用程序垃圾回收的一种机制，一般如果出现了Full GC，应用程序就会出现短暂的停顿。关于Full GC的介绍，可以参考纸质书5.1.7小节中的介绍。此时可以先去看一下应用程序的GC日志，如果是Full GC 非常频繁，并且又没有出现内存泄漏，那么可以参考纸质书5.4.1 小节中介绍的如何减少GC 来解决这个问题。《软件性能测试分析与调优实践之路》(第2版) 读书笔记 （2）系统某一次查询、修改或者删除数据耗时很长，导致了整体性能的不稳定。比如，在性能压测查询时，大部分参数化传入的参数，查询出来的结果数据都很少，但是可能某几个参数查询出来的数据量非常大，导致系统在处理这些数据量大的数据时耗时较长。《软件性能测试分析与调优实践之路》(第2版) 读书笔记 （3）系统在查询时，可能有时候能命中缓存，有时候命不中缓存。命中缓存时，查询会很快；不能命中缓存时，需要去查询数据库，但是查询数据库的时间肯定比缓存长，所以就会造成系统性能的不稳定。通常情况下数据库也会有缓存，如果命中了数据库的缓存，查询也会更快；如果没有命中，那查询的耗时肯定也会变久。《软件性能测试分析与调优实践之路》(第2版) 读书笔记 （4）如果系统是分布式部署，那么可以检查一下分布式处理系统中每个节点的处理能力是否一致，如果不一致，可能也会导致系统频繁抖动。《软件性能测试分析与调优实践之路》(第2版) 读书笔记 （5）服务器连接不够用导致的连接批量释放然后再突然批量连接，一旦批量释放连接后，系统TPS马上就会上涨，因为此时可以建立连接了。当连接满了后，请求就无法处理了，从而不得不等待，进而造成TPS突然下降。 2）、在提高并发用户数时，系统的TPS和平均响应时间一直无法提升 通常，检查后会发现应用服务器的CPU、内存等资源都没有达到使用的上限，但是系统却出现了处理的瓶颈，那么说明系统一定是有地方“堵住了”。此时需要继续做如下检查： （1）性能压测时，点击率是否真的上来了。如果点击率或者单位时间内的请求数没有上来，那说明是压测机器无法提供更大压测能力。尤其在大型的分布式系统中，单台压测机往往是不够用的，因为单台压测机不论是网络连接，还是带宽以及自身CPU、内存等都会存在很大限制，性能压测不止是服务器资源会有很大消耗，提供压测能力的压测机也会很大的资源消耗。 （2）检查网络带宽的使用情况，排查瓶颈是否因为网络带宽限制而导致。此时，需要检查网络带宽的环节包括压测机到Web服务器、Web服务器到应用服务器、应用服务器到数据库服务器等所有存在网络请求交互的地方。如下图所示。（《软件性能测试、分析与调优实践之路》(第2版)，作者张永清，转载请注明出处） （3）参考纸质书5.3.2小节中使用jstack命令行工具，查看Java系统的线程堆栈，从线程堆栈中直接分析当前系统的瓶颈是因为在等待什么资源，而且该资源可能是一个隐形的不容易发现的资源。 （4）如果对于第（3）点运用不熟的话，可以用最笨的方式就是根据请求处理的链路过程，从上而下或者从下而上按顺序去排查。此时需要坚信一点，系统肯定是“堵在什么地方了”，仔细通过checklist去检查，一定能够找到这个“堵住”的位置。