项目性能优化
性能问题分析
-
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)
常用压测工具:
-
Apache JMeter : 可视化的测试工具
-
Apache的ab压力测试
-
nGrinter 韩国研发
-
PAS 阿里测试工具
-
MeterSphere :国内持续测试的开源平台
-
等等
JMeter压测环境架构图:
压测目标总的来说有4条:
-
负载上升各项指标是否正常
-
发现性能短板
-
高并发下系统是否稳定
-
预估系统最大负载能力
案例:SpringBoot项目不做任何配置,TPS上限是多少?
Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试,它最初被设计用于Web应用测试,但后来扩展到其他测试领域。
它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器, 等等。
JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。
另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
手把手带你创建压测案例
目标:完成压测案例,评测SpringBoot项目的吞吐量(TPS)上限。
步骤:
-
创建测试计划
-
配置线程组、http请求、断言、结果监听器
-
执行测试
-
查看测试结果,分析测试结果
实现:
1)新建测试计划
2)配置线程组:
线程属性说明:
-
线程数:20, 线程数量,这里设置了20个线程
-
ramp-up:表示在指定时间之内把这些线程全部启动起来。如果n=1,那就表示要在1s以内把50个线程全部启动起来。
-
循环次数: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,里面有各种软件测试+开发资料和技术可以一起交流学习哦。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!