性能测试知多少

Posted 2021-04-28 PM天秤座的楼外楼

产品提测时被性能测试问“这个服务性能要求是多少？”测试部门期望能得到对应接口TPS压到50还是100，返回时间是100ms还是200ms的回答，然后压力测试的脚本就跑起来，逐个接口进行压测。但作为产品我怎么知道报多少合适呢？

本文框架概览

0.性能测试指标的来源？

1.性能测试的目的（为何要做性能测试？）

2.性能测试的几个指标

3.性能测试的场景设置思路和策略

4.常用的性能测试的工具

5.简要总结

00

—

性能测试指标的来源？

1、产品和运营要给出业务估算：

这个服务，在多长时间段，多少人会访问

2、性能要求上，通常情况下的APP应该如何？

页面访问的2、5、8原理（用户进入服务2s内要展示完所有内容，超过5秒用户就无法忍受了，超过8秒就没有人再等了，直接关闭服务）

因此页面的渲染时间+资源文件的载入时间+接口的获取时间需要保证1s~2s内完成

3、这个条件下接口获取时间多长合适？

无脑建议200ms以内（考虑到你页面也要2s打开，还要给其他工作留时间）

4、怎么通过业务量来计算TPS多少合适呢？（案例说明）

案例1：秒杀型算法

某业务，类似秒杀型，用户估算有2W左右，每个用户平均请求2次接口（查询用户信息接口、查询业务接口）， 这些用户大概率会在2分钟内会访问我们的系统，业务要保证用户2s能打开页面。

TPS是系统每秒钟处理的任务数量，给定业务场景，我们就需要先计算出来每秒需要系统处理多少任务，从而反推在压力测试的时候，需要给多大的TPS了。

首先，整个系统的总请求数=用户（2W）* 每个用户请求数（2次）= 40000次

其次，每秒要求处理的请求数=总请求数/时间（切换到秒） 即约350（333向上取个整吧）。

最后，TPS并发数量与每个请求所消耗的时间，可实际计算出每秒实际能够处理的请求数。

即每秒实际处理请求数量=tps数量 * 1000【1秒，需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】

因此，我们只要保证 每秒实际处理请求数>每秒要求处理的请求数 就可以了。

最终结果就是

TPS数量 > 每秒要求处理的请求数 * tps返回时间【按200ms计算】/1000ms

带入数据计算

tps>(350 * 200)/1000，具体tps>70。

因此可让压力测试人员按照tps100来压接口，返回在200ms以内就满足性能要求。

当然如果实际tps50的返回时间为100ms，则按照这个粗略的公式来推算，也是能够支撑的（350 * 100/1000=35，也就是说tps高于35，返回100ms以内也是可以的）

案例2:

如：一个100w访问的服务，每天访问集中白天8小时，每个用户大约会请求3个接口，每天早上9点是峰值。

首先计算日均请求数（每秒）

按8小时 100w访问量、平均3个接口请求计算

每秒日均请求数=100w（访问量）* 3（每个访问量平均请求接口数）/8（小时）/3600（切换成秒），结果就是每秒请求100次。

按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。

如考虑日常服务的峰值，则按4 * 日均，即每秒请求400次，则tps>80即可，因此可推荐按tps=100来做接口的压力测试。

总结

时间段越短，数据也越接近于瞬间并发

如果用整日的数据来计算总请求数，需要按照日流量分布来估算一个峰值数据，日常APP可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】

如果觉得以上繁杂，反正你也可以参考这个结论：

没啥人用的服务 tps 20，返回有300ms就行了

十万到百万级的服务，响应能达到tps50 /200ms就可以了

后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）

秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量）

01

—

性能测试的目的？

1.评估系统的能力：测试中得到的压力水平和响应时间数据可以用于验证系统是否达到规划时的水平。

2.识别体系中的弱点：将系统的压力增加到一个极端水平，从而发现系统薄弱环节并修复系统瓶颈。

3.验证系统稳定性和可靠性：长时间的测试可能导致程序发生内存泄露等引起的隐藏问题，在一个生产负荷下执行测试一定时间，评估系统可靠性是否满足要求。

4.系统调优：重复执行性能测试，以验证系统调优是否取得预期效果。

02

—

性能测试的几个指标？

性能测试的指标--- 并发用户数

现实系统中操作业务的用户（在同一个时间点，同时请求服务的客户数量，系统同时处理的事务数），在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 “挂”在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。

比如大家常说的：『 我的网站可以承受一万并发。』在通常情况下指的是：如果同时有一万名用户访问网站，所有人都可以正常获得服务，而不会有超时或连接拒绝情况发生。

对于并发用户数的评估：（设置压力测试的目标并发）

1. 可以选取线上系统在高峰时刻一定周期内使用系统的人数，这些人数可以认为是在线用户数，并发用户数取其 10% 就可以了。例如在 1 小时内使用系统的用户数为 10000，一般建议取 10% 左右作为并发用户数。
2. 未上线系统或新上线系统：因没有历史数据可供参考，故只能通过业务发展趋势来预判各项指标。
3. 公式法：

经典公式1：

一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据

1）平均并发用户数为 C = nL/T

2）并发用户数峰值 C’ = C + 3*根号C

C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度

C’是并发用户数峰值

举例1：假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。

平均并发用户数为：C = 400*4/8 = 200

并发用户数峰值为：C’ = 200 + 3*根号200 = 243

 

举例2：某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用改系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。

则一个月最后一周的平均并发用户数为（朝九晚五）：

n = 170000*0.5*0.7/5 = 11900

C= 11900*5/60/8 = 124

吞吐量计算为：F = Vu * R / T 单位为个/s

F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间

 

通用公式2：

对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。

比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！

 

通用公式3：根据PV计算并发数公式：

比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：

1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：

246.92*3=740

通用公式4：根据TPS估计并发数：

公式为 C = (Think time + 1)*TPS

 

通用公式5：根据系统用户数计算：

并发用户数 = 系统最大在线用户数的8%到12% 或 8%到15%

性能测试的指标---并发

并发分为狭义和广义两类。

狭义的并发，即所有的用户在同一时间做同一件事情，这种操作一般针对同一类型的业务或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试；

广义的并发，即多个用户对系统发出了请求或进行了操作，但这些请求和操作是丌同的。对整个系统而言，仍然有很多用户同时进行操作。广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试场景

性能测试的指标---吞吐率

吞吐率是指单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。

用来衡量服务处理请求的效率，计算方式为 （ 总处理请求数 / 总耗时或者总页面数/总耗时 ）从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。从网络的角度来说，也可以用字节数/天等单位来考察网络流量。

HTTP 服务的吞吐率通常以 RPS（Requests Per Second 请求数每秒）作为单位。吞吐量越高，代表服务处理效率就越高。换句话说就是网站的性能越高。

注意：吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子，并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。

但是在性能测试中，二者之间通常会呈现出一种关联关系。当并发数增大时，吞吐率通常也会随之上升（ 多用户发挥出并行处理优势） 。但在并发数超过某个边界值后，吞吐率则会下降 （用户过多，花在上下文切换的开销急剧增大，又或者内存消耗过多）。

性能测试的指标---处理能力（TPS）

TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

TPS就是每秒事务数，但是事务是基于虚拟用户数的，

TPS = 并发用户数/(响应时间 + Thinktime)

假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；

如果 某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；

如果某笔业务响应时间是1s,那么1个用户在1秒内只能完 成1笔事务，要想达到1000TPS，至少需要1000个用户；

因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

对于 TPS（RPS）的评估：（设置压力测试的目标RPS）

1. 线上系统：通过线上系统在高峰时刻 10 分钟内完成的业务量，计算出在单位时间内的处理笔数，即 TPS（RPS） = 业务笔数/单位时间（10*60，以秒为单位）。
2. 未上线系统或新上线系统：因没有历史数据可供参考，故只能通过业务发展趋势来预判各项指标。

性能测试的指标---响应时间（RT)）

响应时间指的是客户端发出请求到得到响应的整个过程所经历的。指从客户端发一个请求开始时，到客户端接收到从服务器端迒回的响应结果线束经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。通常以毫秒（ms）作为单位。

与并发数的关系：一般来说，随着并发数增大，单个用户的响应时间通常会随之增加。这很好理解，餐馆吃饭的人越多，单个顾客等待的时间就越长。

与吞吐率的关系：更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。

平均响应时间指的是所有请求平均花费的时间，如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。

百分位数（ Percentile - Wikipedia ）是一个统计学名词。以响应时间为例， 99% 的百分位响应时间 ，指的是 99% 的请求响应时间，都处在这个值以下。

拿上面的响应时间来说，其整体平均响应时间虽然为 2.98ms，但 99% 的百分位响应时间却是 100ms。

相对于平均响应时间来说，百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间，比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。

平均响应时间：所有请求的平均响应时间，取的平均值

95%percentile ：统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组n个观测值按数值大小排列。如，处于p%位置的值称第p百分位数。

例如有100个请求， 每个请求的响应时间分别是 1-100 平均分布

平均响应时间：1-100 的平均值，即 50.5

95% percentile ：按从小到大排序，累计第95百分位，也就是 95 （即样本里95% 的数据都不高于这个值）

性能测试的指标---资源利用率

资源利用率是指系统资源的使用程度，比如服务器（网络以及数据库）的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。除了上述资源，我们还应该考虑数据库连接池使用情况，JVM内存使用情况，sql执行效率等。

性能测试的类型

1.性能测试

指以系统预期性能指标为前提，对系统不断增加压力，以验证系统能否达到预期性能 。

2.负载测试

主要用于描述常规的性能测试，通过模拟生产运行的业务压力和使用场景组合来测试系统的性能是否满足生产要求

3.压力测试

压力测试是为了发现在什么条件下应用程序的性能会变得不可接受

4.稳定性测试/可靠性测试/疲劳测试

软件可靠性：在规定条件下，在规定时间内，软件丌引起系统失效的概率可靠性测试：在有使用代表性的环境中，持续运行系统某些功能，验证系统稳定性的过程

5.容量测试

确定测试对象在给定时间内能够持续处理的最大负载或工作量使测试对象处理大量的数据，以确定是否达到了将使被测对象发生故障

6.网络性能测试

测试网络带宽、延迟、负载和端口的变化对用户的响应时间的影响，主要是测试用户数目不网络带宽的关系，评估网络的依赖程度

HPS（Hits Per Second） ： 每秒点击次数，单位是次/秒。

TPS（Transaction per Second）： 系统每秒处理交易数，单位是笔/秒。

QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。

RPS 即（Request Per Second）： 每秒请求数，通常用来描述施压引擎实际发出的压力大小。PS：并发数过低时可能达不到预期的 RPS，并发数过高时可能压力过大压垮服务器

03

—

性能测试的场景设置思路和策略

做性能测试需要一套标准化流程及测试策略。在做负载测试的时候，传统方式一般都是按照梯度施压的方式去加用户数，避免在没有预估的情况下，一次加几万个用户，导致交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内；较为适合互联网分布式架构的方式，是用TPS模式（吞吐量模式）+设置起始和目标最大量级，然后根据系统表现灵活的手工实时调速，效率更高，服务端吞吐能力的衡量一步到位。

无论并发模式还是TPS模式，场景就是一个压测模型，压测模型中有串行的事务（如添加购物车+购物车下单+付款）也有并行的接口（在不同串联链路中的压测API），最终组成一个复杂或者简单的场景。然后根据新业务上线的目标、或者日常峰值的等比例目标、或者重大业务活动的预估支撑能力去设置每个API的目标能力（TPS是一步到位的按照吞吐能力设置的，推荐TPS模式，比如前面提到的添加购物车+购物车下单+付款这种流程就是一个漏斗模型，TPS设置为逐渐变小的模型即可），当然也可以在初期的测试中更谨慎一点，将目标量级设置得整体低一点，当最终能力达到之后建议可以调整原定目标量级到120%或者150%，验证限流准入/高可用基础设施的抗压能力。目标量级即当前压测场景中这个压测API的施压上限。而起步量级可以从5%或者10%开始，过程中视业务指标数据和被压测端的整体负载临时调整。

04

—

常用的性能测试工具

1、jmeter

Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

2、Apache Benchmark

Apache Benchmark简称 ab，是apache自带的压力测试工具

3、Locust

Locust是一个Python编写的分布式的性能测试工具。当并发压力要求较高时，就需要用到Locust的多进程分布式运行模式。

locust因为是基于python的压测框架，而python的GIL限制，无法直接利用多核处理器，手动打开多个locust进程来利用CPU多核，才能充分使用压测客户机；

从字面意思上看，大家可能第一反应就是多台压力机同时运行，每台压力机分担负载一部分的压力生成。

的确，Locust支持任意多台压力机（一主多从）的分布式运行模式，但这里说到的多进程分布式运行模式还有另外一种情况，就是在同一台压力机上开启多个slave的情况。

这是因为当前阶段大多数计算机的CPU都是多处理器（multiple processor cores），单进程运行模式下只能用到一个处理器的能力，而通过在一台压力机上运行多个slave，就能调用多个处理器的能力了。

比较好的做法是，如果一台压力机有N个处理器内核，那么就在这台压力机上启动一个master，N个slave。当然，我们也可以启动N的倍数个slave，但是根据我的试验数据，效果跟N个差不多，因此只需要启动N个slave即可。

4、PTS

性能测试 PTS（Performance Testing Service）是具备强大的分布式压测能力的 SaaS 压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。

PTS 目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在 PTS 平台上，您可以用最低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量最佳配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

PTS压测流程说明：

1. 在 PTS 控制台上，准备压测 API 数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。

2. 压测启动后，PTS 后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。

3. 通过随机调度全国上百个城市和运营商的内容分发网络 CDN （Content Delivery Network）节点，发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。

4. 通过压测引擎向您指定的业务站点发起压测。

5. 压测过程中，通过集成云监控、ARMS（应用实时监控服务）产品，结合 PTS 自有的监控指标，实时采集压测数据。

6. 在 PTS 控制台，实时展现压测数据，进行过程监控；压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

05

—

简要总结

系统的性能由TPS决定，跟并发用户数没有多大关系。

系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。

建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。

一般情况下，大型系统（业务量大、机器多）做压力测试，10000～50000个用户并发，中小型系统做压力测试，5000个用户并发比较常见。

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能 ，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到串联链路（场景）中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。同样的，如果系统间的吞吐能力差别很大，那么同样的并发下TPS差距也会很大。

---

行业：B端产品经理（SaaS+PaaS）

兴趣爱好：喜欢摄影和户外溜达，户外领队一枚，从你的全世界路过，然后，陪你路过全世界；