合集 – 性能测试(2)

1.性能测试分析定位03-262.性能测试工具对比评估04-02

收起

背景简介

当我们在性能测试过程中，遇到TPS无法上去、请求响应时间过长、各类资源利用率遇到瓶颈时，应该如何对它们进行分析定位。

压测过程中TPS上不去？请求响应时间过长？

硬件资源不足：服务器的CPU、内存、磁盘等硬件资源不足，无法支撑高并发的请求处理。可以通过增加硬件资源或者优化服务器配置来提升TPS。
网络带宽限制：网络带宽不足，导致服务器无法及时响应请求。可以通过增加网络带宽或者优化网络传输方式来提升TPS。
数据库性能问题：数据库的读写性能不足，无法满足高并发的请求。可以通过优化数据库结构、索引、查询语句等方式来提升数据库性能。
代码逻辑问题：应用程序中存在性能瓶颈或者死循环等问题，导致请求处理速度变慢。可以通过代码优化来提升性能。也可能存在死锁或其他同步问题导致线程或进程阻塞，从而影响TPS。
压测/肉机配置问题：压测工具的配置（如压测肉机数量、压测脚本、场景设计等）可能影响TPS的表现。如压力机可能无法虚拟出预期的用户数，或者压测脚本和场景设计不合理，都会导致TPS无法提升。
负载均衡：负载均衡器配置不当可能导致请求分配不均，从而影响性能。检查负载均衡策略，优化配置。
依赖服务问题：应用程序依赖的第三方服务性能不稳定或者响应速度较慢，导致整体性能受限。可以通过替换或者优化第三方服务来提升性能。
中间件瓶颈：如消息队列堵塞，或有其他排队机制导致无法绕过队列进行高并发请求。
服务配置问题：系统的配置参数不合理，如线程池大小、连接池配置等，也会导致响应时间增。

资源利用率遇瓶颈分析

应用cpu瓶颈如何定位分析

定位

导致应用cpu使用率高，并且使用核数超出机器的核数（如：申请的机器是4核16g，但核数最大显示6核），有可能是经常上下文切换频繁导致的（上下文切换：就是当前进程请求某种资源（如IO操作）而无法立即得到满足，需要切换到其他进程执行，等待资源就绪后再切换回来）；
程序使用复杂的算法如加/解密，或代码bug导致。

分析

减少上下文切换频繁，可以让配置进程数与压测的机器核数一样（因为一个核就有一个进程），配置完成再查看
如果配置好重新压测，cpu使用率依旧还是高，可以看看io是否很高（io操作：读取和写入磁盘上的文件或数据），如果io高，那么有可能出现堵塞
如果压测的请求响应时间也比较大，io和cpu也很高，那么有可能是代码有问题，查看火焰图，查看代码耗时是否比较大，还有mysql监控是否有慢查询等，或者连接数比较少导致
如果火焰图代码部分，有耗时比较大并且有慢查询的，可以进行sql语句优化
如果连接数比较少，设置大一点连接数去重新压，再观察性能情况
如果这些都配置好都修改好，还是有问题，可以考虑加资源或者考虑该业务是否可以进行异步处理来提高性能。

应用内存瓶颈如何定位分析

定位

在压测过程中，可以借助使用监控工具实时监测服务的内存使用情况，定期获取内存快照，监控的主要指标包括内存占用率、内存使用量、内存泄漏等。

分析

查看内存在压测完成后，过一段时间是否有下降趋势。如果没有下降趋势，查看火焰图，查看代码属于哪个函数使用的内存占比大导致，然后优化应用/服务代码后重新压，压测完成再过一段时间查看内存是否有下降，对比优化前后内存使用情况，确认优化措施是否有效。

应用磁盘瓶颈如何定位分析

定位

监控磁盘I/O，可使用系统监控工具（如Linux的iostat、iotop，Windows的Resource Monitor等）实时监控磁盘读写速度、等待时间等指标，看是否存在过高延迟或读写速率过低的情况。

分析

一般磁盘瓶颈就是io高，io高的话一般都是磁盘读写比较大导致，导致磁盘读写比较大，可能以下几种原因导致：

读写的数据太大导致
开发写的代码有问题
可能带宽比较小导致
sql语句写的不规范导致，或者数据库连接数比较少导致，也有可能是mysql配置参数问题，如：数据库缓存配置小，导致不够用，才一直进行磁盘的读写操作（io包括磁盘IO和网络IO）

如果代码都没问题，连接数都没问题，myslq配置也正确，但io还是很高的，可以增加资源来解决后继续进行压测。

数据库内存瓶颈如何定位分析

定位

监控数据库内存使用情况：在压测过程中，使用监控工具实时监测数据库的内存使用情况，包括内存占用量、缓冲池使用情况等。可以通过数据库管理工具或者操作系统工具来监控；
分析数据库缓冲池：查看数据库的缓冲池配置，了解缓冲池的大小、命中率等。如果缓冲池命中率低或者缓冲池过小，可能会导致频繁的磁盘读取，从而影响性能；
检查数据库索引：检查数据库表的索引情况，确定是否存在缺失或者无效的索引。缺失或者无效的索引可能导致数据库执行大量的全表扫描，增加了磁盘IO的负担；
分析数据库查询语句：分析服务对数据库的查询语句，了解查询的复杂度和效率。复杂且低效的查询语句可能会导致数据库内存的过度消耗，从而影响性能；
查看数据库日志：查看数据库的错误日志和慢查询日志，了解是否存在异常和性能较差的查询。通过分析日志可以找出潜在的性能问题和优化的方向；
检查数据库配置：检查数据库的配置参数，例如内存限制、并发连接数等。如果配置参数不合理，可能会导致内存不足或者并发连接过多，从而影响性能。

分析

数据库使用内存高，一般是请求接口需大量的内存进行存储数据，如果内存不够用，会导致请求的接口失败，接口请求失败会导致响应慢等，还有可能会一直分配内存，导致有阻塞从而导致io高，磁盘读写也高，cpu使用率也高，网络io也会高，导致失败不断请求，网络io肯定高，可以新增资源通过负载均衡来解决。
根据分析结果，优化数据库查询语句和索引，例如调整查询条件、添加合适的索引等。同时，也可以考虑调整数据库的配置参数，如增加内存限制、调整并发连接数等。

网络io瓶颈如何定位分析

定位

可以通过使用网络监控工具如Wireshark、netstat命令等，来查看网络流量、带宽使用率、包丢失率、延迟等指标。如果这些指标异常，可能是网络IO瓶颈；
检查网络设备，如路由器、交换机、防火墙等，查看其配置和性能。确保设备的带宽和性能能够满足需求，如果设备配置不合适或者存在故障，可能会引起网络I/O瓶颈。

分析

网络io高，一般是写入读取的数据量大，需要很大的网络流量，如申请的带宽比较小也会导致，可将测机器的带宽网络申请至万兆以上来解决。

带宽瓶颈如何定位分析

定位

排查系统/服务运行在云环境中，检查云服务商的网络带宽限制；
检查系统有多个服务器，检查负载均衡策略是否合理。不恰当的负载分配可能导致某些服务器的带宽过度使用。

分析

出现带宽比较小的情况，通过增加带宽来解决遇到的瓶颈；
可以增加并发连接数进行测试，观察带宽利用率的变化。如果带宽利用率随着并发连接数的增加而增加，说明带宽瓶颈可能是由于连接数的限制引起的。

redis内存瓶颈如何定位分析

定位

使用Redis的监控工具或者第三方监控工具，实时监测Redis的内存使用情况，包括内存占用量、内存碎片、最大使用内存等指标。
查看Redis的日志文件，观察是否有内存相关的警告或错误信息，如内存使用过高的问题。

分析

如果压测完成，redis的内存不变，一直不会下降，有可能应用/服务存储的key值没有设置过期时间导致，这很容易导致内存泄漏，需检查对应的代码，看是否存储内存的值未设过期时间；
检查缓存策略是否有过多的数据被缓存，或者缓存更新策略导致了大量的无效内存占用；
以上方法无法解决内存瓶颈问题，可以考虑扩容Redis集群，增加节点的数量和内存容量，以提高整个系统的内存处理能力。