性能测试-并发测试心得

一些关键名词

吞吐量

指的是在一定时间内系统处理请求或传输数据的能力，具体到性能测试中的话，就是指单位时间内系统处理并完成的请求数量或者是系统传输的数据量。

例如，吞吐量可以表示为系统每秒处理HTTP请求次数，或者是系统每秒钟完成的事务数量（TPS）。

这个指标很大程度体现了系统的处理效率和负载承载能力。

对于这个指标，影响其的因素与CPU、磁盘的I/O紧密相关。

例如，一个Web应用在每次请求时都会去查询数据库，在并发数增加后，数据库就会占用大量CPU和磁盘的I/O资源，就会导致其他的软件被迫等待数据库执行完后才能使用CPU，如果是这种情况，那么这个Web应用的接口设计就存在一定问题，吞吐量就不会太高

响应时间（Response Time，RT）

指的是从客户端发起一个请求到服务器处理完成并返回响应结果所需要的时间间隔，简单来说，就是客户端从发起请求到收到响应的过程。这个时间会包括下述阶段：

网络传输时间：请求在网络中传播到服务器所需的时间
服务器处理时间：服务器接收到请求后，对其进行解析、执行业务逻辑以及数据处理所需的时间
数据库查询时间：如果涉及到数据库操作，那么还包括数据库查询和返回结果所需的时间
生成响应时间：服务器构建并准备响应数据所需的时间
网络返回时间：服务器将响应数据传回客户端所需的时间

在进行性能测试的时候，对于这个指标通常会关注最小响应时间、最大响应时间和平均响应时间，以及特定百分比（如90%、95%或99%）的响应时间

最小响应时间：这个指标表示在测试期间所有请求中响应最快的情况，用于了解系统在理想状态下处理请求的能力。但单一的最小值并不能代表整体性能，因为实际运行环境中的大多数请求可能并不会达到这个速度
最大响应时间：最大响应时间反映出系统处理请求最慢的情况。如果最大响应时间过高，说明系统存在明显的性能瓶颈或异常情况，这直接影响用户体验，需要重点排查和优化
平均响应时间：平均响应时间是所有请求响应时间的算术平均值，它提供了一个总体上系统的平均处理速度。然而，平均值容易受到异常值的影响，如果系统中有极快或极慢的响应时间，平均值可能无法准确反映大部分请求的真实响应情况
特定百分比的响应时间（如90%, 95%, 99%）：这些统计值代表了在所有响应时间中，有相应百分比的请求响应时间小于等于该值。例如，90% 表示有90%的请求响应时间不超过该数值。这些统计数据对于理解和改善用户体验非常关键，因为它们揭示了大部分用户（或请求）的实际响应时间情况，尤其是95%和99%常被用来衡量系统的尾部延迟和性能瓶颈

TPS

通常指的是一秒钟内系统成功处理事务的数量，这里的事务可以是一次登录、一次交易、一次网页加载等。

通过TPS可以了解到系统在不同负载条件下的处理能力上限，可以通过这个指标的突然改变来判断“拐点”（详见下文）

PV和UV

PV（Page VIew）：指的是每一次页面查看或页面访问。每当用户访问网站的一个页面时，无论该用户是首次访问还是刷新同一个页面，都会被计为一个PV。PV反映的是网站内容被访问的总次数，是衡量网站流量规模和受欢迎程度的一个重要指标。如果一个网站一天内被访问了1000个页面，那么这一天的PV就是1000

UV（Unique Visitor）：指的是独立访客数，即在一定统计周期内访问网站的不同用户数。通过识别浏览器的Cookie或IP地址等信息来区分不同的访问者。即使同一位用户在一天内多次访问网站，也只会计入一个UV。UV强调的是访问网站的人数而非访问次数，它能更准确地反映网站的受众群体大小。

PV着重于网站内容被访问了多少次，而UV则是关注有多少不同的个体访问了网站。在评估网站流量和用户黏性时，PV和UV都是非常重要的统计指标。

为什么需要性能测试？

简单而言：

追求更大的并发（担心用户太多，搞垮系统）
追求更短的响应时间（觉得系统太慢）
追求更低的成本（降低服务器配置）

具体而言：

评估系统容量和性能极限。例如，电商平台在大型促销活动期间（如双十一）可能面临数十倍于平时的用户访问量。通过性能测试，可以模拟这种高并发场景，预估系统在短时间内处理大量请求的能力。假设测试结果显示系统在10万并发用户下仍能保持稳定的响应时间和较高的TPS，那么平台就能有信心应对实际促销期间的大流量冲击。
发现和解决系统瓶颈。例如，一款多人在线游戏进行性能测试时，随着玩家人数的增加，数据库查询、网络通信、服务器CPU和内存使用率可能会上升。一旦到达某个阈值，响应时间可能急剧增加，这表明系统存在瓶颈。通过性能测试定位问题，比如发现数据库查询优化不足，进而调整索引、缓存策略或升级硬件设施来解决问题。
指导系统优化和扩展。例如，个企业级内部应用在新功能上线前进行性能测试，发现随着并发用户数增加，系统的吞吐量并未按预期线性增长。经过分析，发现是因为某种业务逻辑造成了大量线程阻塞，通过优化代码结构和采用异步处理方式，使得系统在同等资源条件下处理更多请求，提高了系统的可扩展性。
成本效益分析。企业在选择云服务提供商时，可以通过性能测试比较不同云服务方案的成本效益。例如，通过测试确定在何种资源配置下既能满足业务需求又能最大程度节省成本，避免过度配置资源导致浪费，或资源不足导致用户体验下降。

性能测试需要得到怎样的结论？

性能指标

接口在不同并发用户数的响应时间。例如，在并发用户数从100增加到1000的过程中，接口的响应时间可能从最初的100ms增加到500ms，表明随着并发用户的增多，系统的响应速度在降低。
TPS。例如，在并发用户数为500时，系统的TPS能达到1000，但是当并发用户数为1000时，系统的TPS仅提升到了1200，说明在这个区间中，系统的可扩展性有限，接近饱和点。
并发用户数与响应时间、吞吐量的关系曲线。通过图形，可以更加的直观的看出随着并发数增加到什么程度的时候，系统的TPS开始下降。

系统瓶颈

CPU、内存、磁盘I/O、带宽等

例如，对于两个Web应用，他们都用于处理用户上传的图像并进行实时处理（如缩放、裁剪等）和存储到数据库。

A应用在高并发的情况下，能始终保持50%以下的内存占用，CPU在高峰期也能维持在60%以下

B应用在高并发的情况下，会经常触发垃圾回收机制，会导致响应时间增加，CPU峰值常在95%以上，就会导致大量数据库的I/O操作需要等待，进一步增加响应时间

那么B应用暴露的问题可能就是：

创建了需要不必要的对象，导致内存占用高，频繁触发垃圾回收机制，也可以使用更加高效的垃圾回收机制
可能有密集型的CPU操作，应该进行减少密集型操作，使用多线程、异步等方式来分散CPU负载
数据库有大量I/O操作，可以考虑优化数据库查询语句、引入数据库缓存机制、采用读写分离或分布式数据库方案等手段降低磁盘I/O带来的性能瓶颈

稳定性和可靠性

在高并发的场景下，系统是否会出现错误，例如死锁、超时
以及处理高并发后是否会清理一些环境数据？例如，在高并发场景下，系统处理完大量请求后，应确保没有遗留的打开文件、数据库连接未关闭，以及内存泄露等问题，这对于系统的长期稳定运行至关重要

影响性能测试的因素有哪些？

并发访问方式

一次性全部并发
阶梯式增长并发
持续稳定并发

系统资源

服务器的硬件配置：CPU、内存、磁盘等物理资源，可能会在高并发的时候，进行I/O资源的抢夺，从而影响并发结果
针对于查询类或修改类的接口，数据库也会影响并发测试，例如数据量大小、索引效率、锁机制、是否缓存
线程池大小、连接池的管理，都会影响并发结果

当然，如果在不同的并发测试中上述内容没有被修改，那么上述内容也不是当次并发测试的影响因素

如何确定接口或者系统可以从哪些方面进行优化？

Jmeter如何快速确定拐点？

拐点

这个概念最开始是从性能测试的图形化结果中引申出来的，可以很显然的看到某个指标从一种状态到另一种状态的关键时刻

具体来说，在进行压力测试的时候，随着并发的用户数的增加，系统的吞吐量（或TPS），一开始可能会随着负载的增长而增长，但当达到某个特定的负载水平时，系统的性能就不会再按比例提升，甚至开始下降。

此时，系统的响应时间会明显增加，错误率可能也会随之增高，这个曲线的由增变缓或由降变增的转折点就被称为“拐点”

实例

接口文档

对单个接口进行压测，测试出一些关键数据

接口：https://keewood-v2-service.t.cn-shenzhen.aliyun.kkgroup.work/v4/console/dictionaries/{id}

文档：https://teamshare.t.cn-shenzhen.aliyun.kkgroup.work/application/DT001/automated_testing/template/view/auto_test_api_manage?projectid=613331460681805825&cid=620940619036807169