文档

如何设置单实例并发请求数上限

更新时间:

SAE支持通过PTS工具进行性能压测,以便系统性地模拟真实场景下的高并发请求,从而有效地评估应用在不同负载条件下的性能表现。本文介绍单实例并发请求数与QPS的关系、如何根据业务场景选择规格配置以及PTS压测配置。

术语定义

  • 单实例并发请求数上限:配置SAE每个实例可同时执行的请求数上限。如果初次评估,建议使用压测工具PTS或者JMeter压测摸底极限值。默认情况下,每个实例可以同时接收10个请求,您最多可以将单实例并发请求数上限设置为1000。

    下图展示了单实例的并发请求数上限与应对并发请求所需实例数量的关系。

    image
  • QPS(Queries Per Second):每秒向服务器发送的请求数量峰值,即每个API每秒可以允许请求的并发上限数。当用户在SAE上部署应用对外提供服务时,QPS可用来衡量该应用每秒能够响应和处理的客户端请求数量,包括但不限于HTTP请求、数据库查询或其他类型的API调用。

  • RT(Response Time):响应时间,指的是业务从客户端发起到客户端接收的时间。

单实例并发请求数和QPS换算

  • 请求的端到端耗时=请求执行时长+请求端到端的延迟,单位:秒。

  • 单实例能承受的QPS:QPS=(1/请求的端到端耗时)×单实例并发请求数,请求的端到端耗时单位:秒。

  • 单个应用能承受的QPS:QPS=(1/请求的端到端耗时)×单实例并发请求数×最大实例个数,请求的端到端耗时单位:秒。

举例说明:假如一个应用请求的端到端耗时为0.1s,单个实例并发请求数为2,最大实例个数为6,那么这个单实例能承受的QPS为(1/0.1)×2=20,单个应用能承受的QPS为(1/0.1)×2×6=120。

规格选择

如何根据实际业务场景进行调优单实例并发请求数和规格?

SAE提供了多种实例规格,每种规格的CPU、内存配置以及可处理的并发能力都不同。因此,在选择最适合的规格配置时,需要结合业务运行逻辑与详尽的性能压测结果进行综合评估。对于配置单实例并发请求数,只对总时长计费,能够降低成本,但是过高的单实例并发请求数会导致实例性能恶化,从而导致延时增大。因此,根据压测基线数据进行分析,可以得到单实例性能恶化的转折点(即拐点),选取拐点附近的并发度值,可以作为单实例性能与成本平衡的最佳并发度参考值。

综上所述,在进行压测后得到的最大并发数位置,可以作为推荐的并发请求数量配置标准,以确保系统高效稳定运行。

image
说明

通过压测获得的并发请求数阈值数据,可以作为业务首次上线的初始值,但需注意,这个数值不能直接等同于线上环境的理想配置标准。

使用PTS进行性能压测

  1. 登录PTS控制台

  2. 在左侧导航栏选择性能测试 > 创建场景,然后单击PTS压测,创建PTS压测场景,填写压测场景名。

  3. 场景配置页签中,填写被压测业务的API名称,然后单击GET,填写压测URL。

    image

    说明
    • 压测URL可以是公网访问地址,也可以是自定义域名。

    • 如果使用公网访问地址进行压测,公网访问IP白名单不为空,会导致PTS压测机无法访问应用公网地址,建议临时删除白名单。

      image

  4. 单击调试API

  5. 登录SAE控制台,在目标实例的版本列表页面,单击新建版本,在新建版本面板的容量设置区域,将应用的单实例并发请求数/秒,设置为最大值1000。

    image

  6. PTS控制台施压配置页签中,压力来源选择公网压力模式选择并发模式(虚拟用户模式)递增模式选择自动递增最大并发填写1000,递增百分比填写10%,单量级持续时长设置为1分钟,压测总时长设置为11分钟。

    image

  7. 量级及数据配置区域,串联链路的最大并发权重设置为100,起始百分比设置为1%,然后单击保存去压测

    image

  8. 在左侧导航栏选择性能测试 > 报告列表,在目标压测报告操作列单击查看报告,在报告详情页面查看压测数据。

    分析数据后,可以发现在并发度80左右的时候,RT开始出现拐点,即再增加并发度后实例的性能会恶化。因此建议将性能基准并发数设置在70~80左右,此时的基准单实例QPS为1600左右。如果需要对更细粒度的并发请求数下的实例性能进行测试,可以将递增模式设置为手动调速,以便在压测过程中实时进行调速。

    image

压测基准数据

使用性能测试 PTS(Performance Testing)工具,针对SAE单实例在不同配置规格及不同并发用户数场景下的QPS进行了压力测试。本次测试的地域设定为华北3(张家口),采用registry.cn-zhangjiakou.aliyuncs.com/serverless_devs/sae-demo:helloworld-f395abd5da77镜像作为基准镜像进行测试,该镜像是基于Express框架构建的简单逻辑的Node.js的Web应用,对此简单逻辑的应用进行压测得到不同规格的性能数据。

下表展示了不同规格配置在不同QPS下的执行时长与并发数的数据。

说明
  • 由于0.5 Core 1 GiB和1 Core 2 GiB的资源配置相对较小,为了更精确地捕捉其性能表现,我们选择了更细致的QPS粒度进行探测。

  • 在此次测试中,RT表示在SAE执行环境内部的请求响应时间,不包括客户端到SAE的网络延时。客户端到SAE的延迟约为50 ms,即下列测试数据中请求的端到端耗时为50 ms+RT

  • RT avg指所有请求完成所需的平均时长。

  • 通过QPS和请求的端到端耗时计算各个规格下的实例并发数,并对其进行了取整处理。

小实例规格

QPS(次/秒)

执行时长与并发数

0.5 Core 1 GiB

1 Core 2 GiB

230

RT avg

0.8 ms

0.8 ms

并发数

11并发

11并发

400

RT avg

4 ms

0.8 ms

QPS

21并发

20并发

500

RT avg

34 ms

0.8 ms

QPS

42并发

25并发

650

RT avg

0.8 ms

QPS

33并发

850

RT avg

1.6 ms

QPS

43并发

950

RT avg

7 ms

QPS

54并发

1000

RT avg

13 ms

QPS

63并发

大实例规格

QPS(次/秒)

执行时长与并发数

2 Core 4 GiB

4 Core 8 GiB

8 Core 16 GiB

12 Core 12 GiB

16 Core 16 GiB

470

RT avg

0.9 ms

0.9 ms

0.7 ms

0.7 ms

0.7 ms

并发数

23并发

23并发

23并发

23并发

23并发

880

RT avg

1.3 ms

0.9 ms

0.9 ms

0.8 ms

0.8 ms

并发数

45并发

44并发

44并发

44并发

44并发

1300

RT avg

1.6 ms

1.2 ms

1.2 ms

1.2 ms

1.1 ms

并发数

67并发

66并发

66并发

66并发

66并发

1700

RT avg

3.2 ms

1.7 ms

1.7 ms

1.7 ms

1.7 ms

并发数

90并发

87并发

87并发

87并发

87并发

2000

RT avg

4.2 ms

2.4 ms

2.5 ms

2.4 ms

2.3 ms

并发数

108/并发

104并发

105并发

104并发

104并发

2400

RT avg

4 ms

3.7 ms

3.5 ms

3.5 ms

并发数

129并发

128并发

128并发

128并发

2600

RT avg

7 ms

6 ms

7 ms

6 ms

并发数

148并发

145并发

148并发

145并发

2600

RT avg

11 ms

11 ms

11 ms

10 ms

并发数

158并发

158并发

158并发

156并发

2800

RT avg

19 ms

并发数

193并发

基于以上基准数据分析,可以得出如下结论:

对于2 Core 4 GiB规格的实例,当QPS从470次/秒提升至1700次/秒的过程中,平均响应时间(RT avg)出现了显著上升的变化趋势。当QPS增加到1700次/秒时,响应时间增长尤为明显。随着QPS的不断增加,响应时间增长幅度放缓,在QPS增至2400次/秒时系统处理能力已达到极限,并呈现出明显的性能瓶颈。通过QPS和请求的端到端耗时计算得到该实例对应的最大并发数约为90并发。

据此,我们可以合理推测,对于这个2 Core 4 GiB规格的实例而言,其能够有效处理并发请求的最大性能上限可能是90并发。因此,为了确保服务质量和系统的性能稳定性,建议在实际业务场景中对并发用户数加以控制,避免超过此临界值导致系统性能急剧下滑。