项目压测优化实践思路

项目性能优化

性能问题分析

• 01-性能优化的终极目标是什么？

用户体验 = 产品设计(非技术) + 系统性能 ≈ 系统性能 = 快？

应用性能是产品用户体验的基石，性能优化的终极目标是优化用户体验。当我们谈及性能，最直观能想到的一个词是“快”，哪到底怎么才是快呢？如何又为慢！

• 02-什么样的体验叫快呢？

• 3S定理：Strangeloop在对众多的网站做性能分析之后得出了一个著名的3s定律“页面加载速度超过3s，57%的访客会离开”。

• SEO排名：速度在Google、百度等搜索引擎的PR评分中也占有一定的比例，会影响到网站的SEO排名。

• 03-怎么让系统快起来呢？

性能优化

• 04-应用性能调优是个大工程

• 后端：RT、TPS、并发数 。TPS和RT的影响因素：数据库读写、RPC、网络IO、逻辑计算复杂度、JVM

• Web端：首屏时间、白屏时间、可交互时间、完全加载时间...

• 移动端：端到端响应时间、Crash率、内存使用率、FPS...

首屏时间是指从用户打开网页开始到浏览器第一屏渲染完成的时间，是最直接的用户感知体验指标，也是性能领域公认的最重要的核心指标。

首屏时间 = DNS时间 + 建立连接时间 + 后端响应时间 + 网络传输时间 + 首屏页面渲染时间

FPS是体现页面顺畅程度的一个重要指标。

端到端响应时间是衡量一个API性能的关键指标，比纯后端响应时间更全面，它会受到DNS、网络带宽、网络链路、HTTP Payload等多个因素的影响。

端到端响应时间 = DNS解析时间 + 网络传输时间 + 后端响应时间。

• 05-影响性能的关键要素

产品设计：产品逻辑、功能交互、动态效果、页面元素

12306购票案例查询按钮的设计

基础网络：网络 = 连接介质 + 计算终端

• 连接介质：电缆、双绞线、光纤、微波、载波或通信卫星。

• 计算终端：PC、手机、可穿戴设备、家具家电...

• 基础网络设施，互联网，局域网(LAN)、城域网(MAN)、广域网(WAN)

代码质量&架构

• 架构不合理

• 研发功底和经验不足

• 没有性能意识：只实现了业务功能不注意代码性能，新功能上线后整体性能下降，或当业务上量后系统出现连锁反应，导致性能问题叠加，直接影响用户体验。

移动端环境

硬件及云服务

• 架构不合理：业务发展超越架构支撑能力而导致系统负荷过载，进而导致出现系统奔溃、响应超时等现象。另外不合理的架构如：单点、无cache、应用混部署、没有考虑分布式、集群化等也都会影响性能。

• 研发功底和经验不足：开发的App、Server效率和性能较低、不稳定也是常见的事情。

• 没有性能意识：只实现了业务功能不注意代码性能，新功能上线后整体性能下降，或当业务上量后系统出现连锁反应，导致性能问题叠加，直接影响用户体验。

• 多数的性能问题发生在数据库上。由慢SQL、过多查询等原因造成的数据库瓶颈，没有做读写分离、分库分表等。

压力测试

主机环境

阿里云：5台4C8G机器，4台压力机2C4G

服务器环境：1台压力机，1台应用服务主机，1台数据库与缓存服务器，1CICD服务器

• hero01：CICD服务器4C8G：Nginx、JMeter、CICD

  内网ip：172.17.187.81（I/O优化）25Mbps峰值

• hero02：数据库与缓存服务器4C8G：MySQL、Redis、MQ、ES

  内网ip：172.17.187.78（I/O优化）25Mbps峰值

• hero03：应用服务器01-4C8G：Application

  内网ip：172.17.187.79（I/O优化）25Mbps峰值

• hero04：监控服务器02-4C8G：Grafana、Prometheus、InfluxDB

  内网ip：172.17.187.80（I/O优化）25Mbps峰值

网络中的Mbps和MBps，及两者的换算关系

• Mbps = Megabit per second (Mbit/s or Mb/s)

• MBps = Megabyte per second

• 1 Mbps = 0.125 MB/s

• 25Mbps = 3.125 MB/s

什么是压力测试？

什么是压测？

压力测试（英语：Stress testing）是针对特定系统或是组件，为要确认其稳定性而特意进行的严格测试。会让系统在超过正常使用条件下运作，然后再确认其结果。

压力测试是对系统不断施加压力，来预估系统服务能力的一种测试。

为什么对系统压测呢？有没有必要。压不压测要看场景！

一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行压力测试。

目的是什么？

• 当负载逐渐增加时，观察系统各项性能指标的变化情况是否有异常

• 发现系统的性能短板，进行针对性的性能优化

• 判断系统在高并发情况下是否会报错，进程是否会挂掉

• 测试在系统某个方面达到瓶颈时，粗略估计系统性能上限

压测性能指标有哪些？

以上主要的四种性能指标【响应时间、并发用户数、吞吐量、资源使用率】它们之间存在一定的相关性，共同反映出性能的不同方面。

在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。

三条曲线：

• 吞吐量的曲线（紫色）

• 利用率（绿色）

• 响应时间曲线（深蓝色）

三个区域：

• 轻负载区（Light Load）

• 重负载区（Heavy Load）

• 塌陷区（Buckle Zone）

两个点：

• 最优并发用户数（The Optimum Number of Concurrent Users）

• 最大并发用户数（The Maximum Number of Concurrent Users）

三个状态描述：

• 资源饱和（Resource Saturated）

• 吞吐下降（Throughput Falling）

• 用户受影响（End Users Effected）

常用压测工具：

1. Apache JMeter : 可视化的测试工具

2. Apache的ab压力测试

3. nGrinter 韩国研发

4. PAS 阿里测试工具

5. MeterSphere ：国内持续测试的开源平台

6. 等等

JMeter压测环境架构图：

压测目标总的来说有4条：

1. 负载上升各项指标是否正常

2. 发现性能短板

3. 高并发下系统是否稳定

4. 预估系统最大负载能力

案例：SpringBoot项目不做任何配置，TPS上限是多少？

Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。

 它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。

JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。

另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

手把手带你创建压测案例

目标：完成压测案例，评测SpringBoot项目的吞吐量（TPS）上限。

步骤：

1. 创建测试计划

2. 配置线程组、http请求、断言、结果监听器

3. 执行测试

4. 查看测试结果，分析测试结果

实现：

1）新建测试计划

2）配置线程组：

线程属性说明：

1. 线程数：20， 线程数量，这里设置了20个线程

2. ramp-up：表示在指定时间之内把这些线程全部启动起来。如果n=1,那就表示要在1s以内把50个线程全部启动起来。

3. 循环次数：2000，表示把 20 线程 循环2000次，也就是说让线程循环调用接口2000次

3）配置HTTP接口：

【代码】

选择keepalive方式，表示使用了长连接。使用长连接可以防止频繁的建立连接，关闭连接消耗性能。

一般浏览器都支持keepalive，如果这里不勾选，这样我们的压测的部分性能消耗会发生在建立，关闭连接上，导致我们的压测数据不准确。

4）配置断言：

JMeter断言常用有两种，一种是响应断言，一种是响应时间断言，如果响应内容不满足断言的配置，则认为这次的请求是失败的。

• 响应断言：判断响应内容是否包含指定的字符信息，用于判断api接口返回内容是否正确。

• 响应时间断言：判断响应时间，是否超过预期的时间，用于判断api接口返回时间是否超过预期。

（1）断言添加方式：右击测试计划的http请求，选择添加-->断言-->加响应断言和断言持续时间。

（2）配置响应断言：我们接口正常返回code值为20001，如果接口返回code值不是20001表示接口异常，为了测试，这里修改为接口返回code值不为20001则表示访问失败。

（3）配置断言响应时间：设置请求接口时间超过10毫秒，则认为请求失败。

（4）验证断言配置：发起http请求，由于返回内容code值不为20001，以及访问时间超过10毫秒，所以认为访问失败。

5）配置结果监听：

• 配置监听器：监听压测结果【聚合报告和汇总结果很类似，看一个就行】

• 聚合报告：查询结果信息聚合汇总，例如样本、平均值、通吐量、最大值、最小值...

• 察看结果树：记录每一次压测请求

• 图像结果：分析了所有请求的平均值、中值、偏离值和通吐量之间的关系。

• 汇总结果：汇总压测结果

• 汇总图：将压测结果以图像形式展示

压测结果

1）聚合报告：

样本（sample）: 发送请求的总样本数量

响应时间【单位ms】：

• 平均值（average）：平均的响应时间

• 中位数（median）: 中位数的响应时间，50%请求的响应时间

• 90%百分位（90% Line）: 90%的请求的响应时间，意思就是说90%的请求是<=1765ms返回，另外10%的请求是大于等于1765ms返回的。

• 95%百分位（95% Line）: 95%的请求的响应时间，95%的请求都落在1920ms之内返回的

• 99%百分位（99% Line）: 99%的请求的响应时间

• 最小值(min)：请求返回的最小时间，其中一个用时最短的请求

• 最大值(max)：请求返回的最大时间，其中一个用时最长的请求

异常（error）: 出现错误的百分比，错误率=错误的请求的数量/请求的总数

吞吐量（throughout）: 吞吐能力，在这里相当于TPS

Received KB/sec----每秒从服务器端接收到的响应数据量Sent KB/sec----每秒从客户端发送的请求的数量

2）察看结果树：

记录了样本中的每一次请求

3）汇总图与图形结果

图形结果：分析了所有请求的平均值、终止、偏离值和通吐量之间的关系

横坐标：为请求数量，单位个数

纵坐标：响应时间，单位ms

4）汇总报告【类似于聚合报告】

样本（sample）: 发送请求的总样本数量

响应时间【单位ms】：

• 平均值（average）：平均的响应时间

• 最小值(min)：请求返回的最小时间，其中一个用时最少的请求

• 最大值(max)：请求返回的最大时间，其中一个用时最大的请求

• 标准偏差：度量响应时间分布的分散程度的标准，衡量响应时间值偏离平均响应时间的程度。标准偏差越小，偏离越少，反之亦然。

异常（error）: 出现错误的百分比，错误率=错误的请求的数量/请求的总数

吞吐量TPS（throughout）: 吞吐能力，这个才是我们需要的并发数

每秒接收 KB/sec----每秒从服务器端接收到的数据量

每秒发送KB/sec----每秒从客户端发送的请求的数量

平均字节数

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！