企业官网建设流程全解析

郑州做网站哪家最好,青岛网站优化公司,太原做网站哪家好,网站设计北京新#x1f345; 点击文末小卡片#xff0c;免费获取软件测试全套资料#xff0c;资料在手#xff0c;涨薪更快 最近组内在进行服务端高并发接口的性能压测工作#xff0c;起因是2023年2月2日#xff0c;针对胡某宇事件进行新闻发布会直播#xff0c;几十万人同时进入某媒体…点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快最近组内在进行服务端高并发接口的性能压测工作起因是2023年2月2日针对胡某宇事件进行新闻发布会直播几十万人同时进入某媒体直播间造成流量激增从监控上可以看出QPS到达某峰值后部分进入直播间即调用的接口这类接口属于高并发接口在短时间内承载非常高的QPS以及对应接口的下游均出现了非常严重的服务可用性下降部分接口可用性下降到了60%并且 接口平均响应时间从500ms毫秒飙升到 6 s经过分析得出可用性下降以及接口平均响应时间飙升的原因为数据库服务挂掉出现线上数据库服务挂掉这样的异常事件可以看出我们对整个直播系统的架构并没有认识到性能瓶颈主要的盲点如下一个微服务当中的高并发接口究竟能抗多大的QPS当超过性能极限的QPS后是否有限流/降级/熔断的策略在执行或者直接对功能进行云控开关限制流量高峰期当中系统是否能正常提供服务是否有隐藏问题解决这些盲点的方法就是进行容量压测本篇文章我将带大家体验容量压测的全流程本文主要内容为什么是容量压测容量压测的全流程前期准备发压执行压测结果和性能调优什么是容量压测容量压测Capacity Testing 是一种软件性能测试方法主要用于评估系统在特定负载下的容量。其目的是确定系统可以处理的最大工作负载以及在达到容量极限时系统是否能够保持其性能和稳定性容量压测和一般接口压测的区别容量压测和一般的接口压测都会模拟实际生产环境下的负载情况通过不断增加并发用户数来逐渐加大负载两者的区别在于容量压测需要压到系统开始出现性能问题或崩溃而一般的接口压测只需要满足在性能测试方案当中指定的并发用户数即可不需要压到服务有损压测常用的性能指标概念介绍在容量压测试过程中需要监控系统的各项性能指标如响应时间、吞吐量QPS、资源使用率CPU、内存和网络、服务可用性、错误码等并记录压测结果QPSQPSQueries Per Second表示每秒查询率用来衡量系统每秒能够处理的请求数量日常接口压测中通过制定压测方案先确定要压到的QPS数量压测执行完毕后若没有性能问题则表明该接口能扛住对应的QPS用来衡量对应系统的吞吐量好坏TPSTPSTransactions Per Second表示每秒事务处理量即系统每秒能够处理的事务数量。一个事务可能包含多个请求因此完成一个事务所需的时间往往比处理一个请求的时间更长这就导致了TPS 通常比 QPS 更低系统的复杂性和实现方式不同可能会影响到每个事务或查询的处理时间实际情况下大多数场景QPS和TPS两者近似相等响应时间响应时间是指从客户端发一个请求开始计时到客户端接收到从服务器端返回的响应结果结束所经历的时间响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成一般取平均响应时间计算方式响应时间发送时间约等于0网络传输时间N1N2N3N4服务器处理时间A1A2A3响应时间一般会随着并发用户数负载上升不断升高并发用户数并发用户数系统同时存在处理的请求数量并发用户数常简称为并发数并发用户数是衡量系统负载的关键指标并发用户数越多系统的负载就越高负载用户负载指的是当前正在访问或使用某个系统、应用程序或服务的并发用户数。当提到负载或用户负载可以代指并发用户数计算方式并发用户数QPS*平均响应时间 论证计算方式见下方吞吐量介绍吞吐量吞吐量指的是单位时间内系统处理的请求数量系统吞吐量由QPSTPS、并发用户数、平均响应时间共同决定多数情况下QPS和TPS近似相等而QPS由并发用户数和平均响应时间决定所以对于服务端来说系统吞吐量一般直接用QPS来作为量化指标换句话说别人问起某系统的吞吐量有多高就是指这个系统能抗的QPS有多大计算单位请求数/秒最常用 页面数/秒访问人数/天页面访问量/天计算方法吞吐量请求总数/总时间并发用户数/平均响应时间QPS利用计算并发用户数的经验公式来验证QPS的计算方法的正确性通过查看上图论证过程可以得知计算 并发用户数计算QPS的正确性资源利用率不同系统资源的使用程度通常用占用最大值的百分比或均值的百分比来衡量通常需要关注的资源有CPU内存磁盘线程数等压测中需要关注Web服务实例数据库实例缓存实例的资源利用率CPU利用率是重点指标服务可用性服务可用性为异常请求数量占请求总数的占比在性能测试中根据实际情况需要关注对应压测服务接口以及接口下游服务的可用性数据库服务缓存服务可用性等计算方式服务可用性 100 - 请求异常数量 / 请求总数 * 100实际例子计算并发用户数看完这些概念是不是还是感觉一脸懵逼用一个实际的场景来1秒内并发地来了160个请求那么此时QPS和并发用户数都怎么计算呢从上面计算公式可以得知QPS为160但无法计算并发数前面我们知道了并发数QPS平均响应时间。但这里缺少了响应时间假设响应时间为100 ms0.1s并发用户数为1600.116系统同时1s内在处理16个用户的请求这就是系统支持的并发用户数性能指标之间的联系并发用户数与资源利用率/吞吐量/响应时间这3个指标之间关系密切。随着并发用户数增大资源利用率吞吐量响应时间都会发生不同的变化引用一张非常经典的性能指标图片来说明它们之间的关系该图来自2005 年 Quest Software 的白皮书《Performance Testing Methodology》在这个图中横坐标为并发用户数衡量系统负载的重要指标纵坐标有3层含义分别是资源利用率CPU/内存下面统称为CPU吞吐量对于衡量服务端吞吐量一般用QPS代替下面统称为QPS响应时间通过此图可以看到三条曲线、三个区域、两个点以及三个状态描述三条曲线QPS紫色、CPU绿色、响应时间深蓝色三个区域轻负载区Light Load、重负载区Heavy Load、塌陷区Buckle Zone两个点A点为最优并发用户数The Optimum Number of Concurrent Users、B点为最大并发用户数The Maximum Number of Concurrent Users三个状态描述资源饱和Resource Saturated、吞吐下降Throughput Falling、用户受影响End Users Effected用大白话解读一下这张图假设刚开始系统只有一个用户CPU工作处于不饱合状态。一方面该服务器可能有多个CPU但是只处理单个进程另一方面在处理一个进程中可能IO等待阶段因为没有其他用户所以没有其他请求进程可以被处理这个时候会造成CPU等待随着并发用户数的增加未超过A点CPU利用率逐步上升平均响应时间也在增加QPS相应也增加而当并发数增加到很大时超过B点每秒钟都会有很多请求需要处理会造成进程线程频繁切换真正用于处理请求的时间变少每秒能够处理完的请求数反而变少即QPS开始下降但用户的请求等待时间响应时间也会持续变大最后超过用户的心理底线综上所述在最小并发数和最大并发数之间一定有一个最合适的并发数值在最佳并发数下QPS能够达到最大。但是最佳并发并非是一个最大的并发到达最大时的并发可能已经造成用户的等待时间变得超过了其最优值对于一个系统来说最佳的并发数需要结合QPS以及用户的等待时间来综合确定有小伙伴就有疑问了QPS怎么还会下降呢从数学的角度来解释一下原理见下图表示并发用户数和响应时间关系的深蓝色曲线以B点为分界点在横坐标[1,B]以及[B,正无穷]区间内增长速率有所不同当并发用户数没有到达点B时曲线的斜率小于1所以在初期由于并发用户数的增速比平均响应时间更快分子比分母涨得快所以QPS不断上升并发用户数超过点B后曲线呈现出指数增长并发用户数和响应时间的曲线的斜率大于1并发用户数的增速比平均响应时间还慢分母比分子涨得快所以QPS下降从QPS的计算公式可以得出QPS是由并发用户数平均响应时间两者共同决定谈到QPS时一定需要指明是多少并发用户数下的QPS否则毫无意义因为单用户的40QPS和 20个 并发用户下的40QPS是两个不同的概念前者说明该应用可以在一秒内串行执行40个请求而后者说明在并发20个请求的情况下一秒内该应用能处理 40 个请求当QPS相同时越大的并发用户数代表了服务的并发处理能力越好容量压测的全流程容量压测也是属于性能测试和一般的性能测试流程相同需要值得注意的是如果是使用线下环境压测压测流程如下而对于直接使用线上环境生产环境压测则无需进行流量构造压测环境部署预热这3个环节场景设计在进行性能测试之前第一步是进行压测的场景设计是指针对单接口还是多个接口有关联需要组合起来同时压测由于本次容量压测只针对高并发的单接口通过查看监控平台某时间段的接口请求流量情况以及查看代码得知代码架构和调用时机我就确定好了高并发接口的范围并没有花时间在场景设计上高并发是指在同一时间内系统或应用程序所处理的并发请求量非常高。在一个系统或应用程序中如果同时有大量的用户或进程访问同一个资源或进行相同的操作就会出现高并发的情况。这种情况下系统或应用程序需要同时处理大量的请求如果处理不当可能会导致系统响应变慢、延迟或崩溃等问题高并发处理能力是一个系统或应用程序的重要指标之一。为了提高高并发处理能力通常需要采用分布式、缓存、负载均衡、异步处理等技术来优化系统的性能数据构造在本次压测的接口当中有部分接口的参数需要动态获取不能写死否则会命中缓存起不到压测的效果。如下方接口参数param2参数的值为从文件当中读取一批提前生成好的数据。平时在进行压测时通常我们可以通过用Python写一些造数脚本满足性能测试数据构造的需求另外接口信息如URL和请求参数也需要提前配置好发压工具可以使用Jmeter、Loucst、Loadrunner等{param1: 123456, param2:${id}, param3:10000006, param4:6.7.5 }流量构造压测前若使用线下环境压测需要提前进行流量构造对于流量的构造也有下面几种不同的策略拷贝和线上流量完全相同的流量到线下对线上流量进行染色使用线上流量构造部分线下流量完成构造线下流量压测环境部署为了避免对生产环境影响也可以使用线下环境进行压测如果使用线下环境需要提前部署好压测环境预热对于线下环境部署好压测环境一般不能马上进行压测需要进行预热也就是等机器空跑5-10分钟这是因为在环境刚启动的时候系统的响应时间CPU内存环境刚启动的时候均处于不稳定的状态执行压测实时监控前面的准备工作都做完成了就可以开始压测在进行压测过程中注意通知开发一起关注监控。常见的监控指标机器内存使用率机器包括部署程序实例数据库服务缓存服务、CPU利用率和代理层服务以及下游可用性响应时间错误码等结果分析和调优性能测试后发现的问题多种多样我总结了一些常见的调优方法增加限流/熔断/降级策略增加功能限制开关在达到某一QPS峰值后利用云控开关关闭此功能从而阻止流量激增对后端服务带来的影响增加服务器资源如果应用程序的性能瓶颈是由于服务器资源不足导致的可以考虑增加服务器资源。例如增加CPU、内存或网络带宽等优化数据库查询如果应用程序的性能瓶颈是由于数据库查询效率低下导致的可以考虑优化数据库查询。例如使用索引、减少查询结果集、缓存查询结果等优化代码如果应用程序的性能瓶颈是由于代码效率低下导致的可以考虑优化代码。例如使用更有效的算法、避免重复计算、减少数据库操作等缓存如果应用程序的性能瓶颈是由于频繁的数据访问导致的可以考虑使用缓存。例如客户端可使用本地缓存、后端使用Redis缓存等。负载均衡如果应用程序的性能瓶颈是由于流量集中在某个服务器上导致的可以考虑使用负载均衡。例如使用Nginx、HAProxy等工具进行负载均衡以上是一些常见的性能调优案例具体情况需要根据应用程序的特点和性能瓶颈来确定。同时在执行性能调优时需要谨慎考虑对应用程序的影响并进行充分测试以确保解决方案是可行和有效的结束语在本次压测当中也出现了很有意思的问题在这里分享一下1简单SQL竟然出现了慢查询根本原因是同一行SQL并发写操作执行命中锁导致阻塞2数据库链接超时排查后竟然不是数据库服务本身的问题根本原因是部署Web服务机器实例CPU利用率飙升导致无法及时处理数据库链接压力测试在越发复杂的大型互联网系统架构下起到至关重要的作用希望本篇文章对你有所收获最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。