性能测试

性能测试，评估系统整体性能的测试，主要指标有响应时间、吞吐量、资源利用率等。

📌 需要关注的指标

吞吐量、响应时间和用户数量: 刚开始吞吐量随着用户数量的增加逐渐变大，当达到一定程度时，逐渐平缓直到变成一条平线；而响应时间随着用户数量的增长逐渐变大。

关注的指标: 并发数、响应时间、TPS-每秒处理事务数、QPS-每秒处理查询数、服务器资源。

🎬 场景: 并发数太高，吞吐量小，影响得到的响应时间准确性。

需要从小并发往上递增加压，TPS随之往上增长；当TPS不涨时，此时的并发数就是最佳并发数。

而当在最佳并发数下出现响应时间过长的情况时:

🤔 分析原因:

网络延迟: 检查网络状况，确保网络带宽和稳定性满足测试需求。（局域网一般影响不大）
服务器性能: 检查服务器CPU、内存等资源使用情况，判断是否由于资源不足导致性能下降。
接口设计: 检查接口是否涉及复杂计算或大量数据处理，这些操作可能导致响应时间延长。
代码优化: 分析代码实现，看是否存在可以优化的地方，如减少数据库查询次数、使用缓存等。

🔎 处理方法:

优化网络: 如果网络延迟是主要原因，可以尝试升级网络设备、优化网络配置或选择更稳定的网络环境进行测试。
升级服务器: 如果服务器性能不足，可以考虑升级服务器硬件或增加服务器数量来提高处理能力。
优化接口设计: 对于涉及复杂计算或大量数据处理的接口，可以尝试优化算法、减少数据处理量或采用异步处理方式来提高响应速度。
优化代码: 对代码进行性能分析，找出性能瓶颈并进行优化。可以考虑使用更高效的算法、减少数据库查询次数、使用缓存等技术来提高响应速度。
引入缓存机制: 对于经常访问的数据或计算结果，可以将其缓存在内存或缓存数据库中，以减少对数据库的访问次数，提高响应速度。
使用分布式缓存: 将经常访问的数据缓存到内存中，以减少数据库的访问次数，提高接口的响应速度。

📌 OOM

服务器内存足够大，出现OOM的原因分析：

内存泄漏: 程序设计时的失误，代码运行完成后未能正确回收/释放资源。结果导致程序性能下降，最终可能引发系统崩溃。
内存溢出: 内存泄漏会引发内存溢出，程序试图分配超过实际可用的内存大小。
高并发请求
不合理的内存分配
多进程/多线程的资源竞争

通过长时间压测，可以发现内存泄漏问题，报错OutOfMemory 或 OOM。

或者压测结束后，CPU使用率一直未下降，可能也是内存泄漏问题。

📌 性能测试流程

🚁 1.准备项目环境

服务器操作系统-Centos7.6、资源情况-4核CPU、8G内存、部署方式-Docker、压测网络-局域网

🚁 2.准备测试环境

测试机操作系统-Windows10、测试工具-JMeter、堆内存小于机器内存的70%(available*0.7，free值太小时可能需要手动清缓存)

JMeter堆内存配置默认为:

'-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m'

🚁 3.搭建监控平台

服务器资源、组件(db、mq、redis)通过Prometheus、Grafana监控，具体的进程监控通过命令行查看

🚁 4.了解压测目的

测试环境压测结果供生产环境做参考
基准测试-版本迭代时，根据历史版本的压测结果作为基准，进行比较
复现生产问题，分析问题现象

🚁 5.准备压测脚本

业务流程 + 脚本设计

初始并发数可以设置为：系统用户数 * 5% 或 20%

🚁 6.场景设计

🔧 1）性能测试需求

具有明确的指标，如行业常规水平：响应时间-不超过3秒、错误率-不超过0.2%、CPU、内存使用率小于80%等。

🔧 2）业务场景分类

单业务
组合业务/混合场景
比例业务，按业务流程访问占比，通过吞吐量控制器控制各流量

🔧 3）场景模式分类

基准场景/单用户场景
负载测试：测试在不同用户量的级别下，软件的性能表现。
压力测试：测试系统在极端条件下的表现，是否会挂掉。
容量场景：估算软件最大用户数
稳定性场景：长时间的压测测试，检查是否存在OOM内存溢出。

🚁 7.开始测试

记录每次压测的数据，包括：并发量、请求数、错误率、平均响应时间(ms)、90%请求响应时间(ms)、吞吐量(tps)、cpu使用率（最高峰）、内存使用率（最高峰）。
观察现象，分析软件指标，rt、错误率是否异常。
查看硬件资源情况，CPU、内存、网络、磁盘等是否异常。
分析cpu飙升的进程，通过top、ps查看对应应用，看是否有error级别的日志。
初步分析问题原因，优化后进行回归验证。

📌 性能测试报告

概述: 编写目的、项目背景、系统简介、测试目标
性能测试环境: 服务器软硬件环境、测试环境与配置、人员与时间安排、测试工具
性能测试用例场景: 核心业务、复合业务等
性能测试分析与调优: 压测结果数据分析，记录调优方案，用于后续项目的参考
性能测试结论汇总完整的性能测试报告

📌 面试题

🚁 API慢怎么分析

核心：链路追踪，定位耗时最长的环节。

针对环节深入分析：

数据库查询慢：检查慢查询日志、SQL执行计划。
第三方服务慢：对方无法优化的情况下，非强关联的接口通过异步方式进行优化。
内部方法慢：用性能分析工具（如Arthas的trace命令）定位具体方法。
缓存有效性：查看缓存命中率（如Redis的hit_rate），若命中率低（如<50%），说明缓存失效或未命中，导致大量请求穿透到数据库。

🚁 在执行性能测试时，您如何确定并发用户数和测试数据量

确定并发用户数

业务场景分析：分析系统的历史数据或用户行为日志，考虑用户的使用习惯，了解高峰时段有多少用户同时访问。
性能目标：根据业务需求设定系统的预期负载，逐步增加并发用户数，了解系统在不同负载下的表现。
资源限制

确定测试数据量

生产环境数据规模及数据复杂性
测试目标：如验证某个特定功能的性能则使用较小的数据集；验证系统在极端情况下的表现，则需要大规模数据集。

🚁 您在性能测试中遇到的最大的挑战是什么？您是如何解决的？

最大的挑战：模拟真实用户行为和负载，以及在复杂的分布式系统中准确识别性能瓶颈。

用户行为的复杂性：用户行为通常包括多种操作路径、思考时间、页面跳转、异步请求、缓存行为等。
数据量与并发规模
测试环境与实际环境差异：包括软硬件配置、缓存、CDN等。

如何解决

使用ELK等日志分析工具，收集真实用户访问路径、波段最大请求数。
设计压测脚本时，模拟用户思考时间、文件上传、异步请求等行为，利用分布式测试节点模拟大规模并发用户。
模拟真实数据：使用脱敏的生产数据的子集，或工具生成符合业务逻辑的数据。
减少环境差异：硬件配置、网络拓扑、数据库性能等方面与生产环境保持一致。无法复现的在测试报告中标注环境差异，并进行归一化处理（如按比例放大响应时间）。
全链路监控与分析，部署APM工具如skywalking，监控每个组件的性能表现（如JVM、数据库查询、缓存命中率）。

APM工具的作用

核心作用：让分布式系统的性能问题变得可观测

分布式链路追踪：定位请求全流程的性能瓶颈
服务性能监控：实时掌握系统健康状态
服务依赖与拓扑可视化：梳理系统架构关系
故障定位与根因分析：从现象到本质的快速排查
容量规划与性能优化：避免过载与资源浪费
用户体验管理：从端到端优化用户感受

🚁 TPS波动怎么分析

影响TPS波动的因素有：

外部因素：网络波动（如延迟忽高忽低）、数据库锁竞争（如并发更新同一行数据）、第三方服务延迟（如支付接口响应时间波动）。
内部因素：线程池配置不合理（如队列满导致拒绝请求）、GC频繁（GC期间无法处理请求）、缓存失效（如缓存过期后大量请求穿透到数据库）。
负载不均衡

分析步骤：

监控工具查看TPS波动的时间点，是否与缓存失效时间（如每天0点缓存刷新）、定时任务重合。
查看资源指标：同步查看CPU、内存、IO、网络的波动情况（如TPS下降时，数据库IO飙升）。
数据库监控工具查看慢查询、锁等待情况。
检查线程池是否存在队列满或拒绝次数多，可能线程池配置不足。
链路追踪：用APM工具链路追踪，定位耗时最长的环节，检查是否有某个服务的响应时间突然变长（如第三方服务调用）。
验证负载均衡：分布式系统中，查看各节点的TPS分布，若某节点TPS远高于其他节点，说明负载不均衡。