一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?

“尽管大促活动前加班加点做测试,到了活动当天仍然是危机频发,高并发的关键时刻又出乱子了,紧急排查故障,处理完之后 1 个小时过去了。时间不等人,顾客也不等你,一

如今,大促销已成为常态。相信这样的场景在电商领域并不少见。此时,平台总会进行各种排查测试,做好防备上述困境的准备,但往往是防不胜防。事实上,随着移动互联网的盛行,超高并发压力不仅仅存在于电商领域。在线教育、在线办公、社交娱乐等领域也深受其影响。

为什么需要性能测试?

“性能测试的重要性不言而喻,如果性能测试做得不好,将会带来灾难性的问题。”

众所周知,性能异常包括5种典型场景:

用户访问量瞬间激增;服务器上的流量满载;系统资源长期居高不下、占用;服务接入时超出最大限制,服务范围太窄;虽然可以访问网站,但是延迟极高。第一种情况经常发生在抢购场景中。抢购前五分钟大量流量的积累,往往会导致前期服务器带宽不足。用户在抢票过程中体验会非常差,进而影响平台的营业额。

第二类服务器的CPU满载也是很常见的。一般来说,复杂业务系统的单机监控性能消耗基本在20%左右,单机剩余计算率一般只有70%~80%。复杂场景下频繁访问可能会导致CPU瞬间超过90%。基于此,如果在性能测试时没有很好地测试激增场景,那么对于服务器来说将是一个比较大的灾难。

第三种情况是普通负载均衡设备满载流量。现在大多数企业都使用云厂商的负载均衡设备。基本上,PPS 连接是有上限的。如果没有良好的估计,当上限已满时,后续用户将遇到连接错误,通常是HTTP 503 错误。

第四种情况是系统超载,超出访问限制。测试过程中的主要问题是容量估算不足。如今,大规模业务的系统扩容和切换至少需要90秒左右才能完成业务的快速接管。因此,早期性能测试的容量评估在过程中做热切换和热部署场景是非常有必要的。场景搭建好后,可以通过横向扩展快速接手业务,快速解决一些复杂的性能问题。

第五种情况,网站访问没有问题,但网站访问延迟极高,部分服务接口大面积超时,影响用户体验。

在研发过程中,我们会发现,无论是研发还是测试,一般罪魁祸首都是一些小规模的代码错误,进而导致一些功能和性能问题,造成巨大损失。因此,严格的需求评估是非常有必要的。如果你能很好地分析常见和异常业务场景,那么上线后一旦出现问题,你就能轻松应对。

整个需求过程中,运维人员不需要特别赶时间做一些编码操作。如上图所示,测试场景的设计、测试流程的梳理、测试数据的管理以及执行的顺序都要在前期确定。然后性能测试执行器会完成汇总操作,汇总测试结果,记录各个节点上出现的性能问题。形成整个测试的分析报告,包括调优数据和参数配置数据。

最终运维人员依靠线上的性能数据来配置索引排序方式。一般来说,有三种方法:正常运维时的参数配置、系统异常时的参数调整、紧急异常或灾难性问题时的调整方法。

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?

如果性能测试做得不好,直接的经济损失将是难以估量的。以电商企业为例,亚马逊的研究数据显示,电商的访问速度每降低100毫秒,营业额就会减少至少1%。或者说,相比618、双11等场景,如果用户体验差,无法支付,损失可想而知。

哪种测试方法更有效?

“移动互联网时代,企业如何针对频繁的市场活动和快速的产品迭代进行有效、准确的性能测试?”

随着移动互联网的快速发展,电子商务、在线教育、票务等企业业务数量大幅增长,超高并发的价值不断突破和前进。同时,随着业务的复杂化,整个IT系统的架构也在快速演进,从单一主机发展到1000台应用主机,分布式CDN节点数量超过4000个,链路节点设备层数超过10层,分布式微服务架构盛行。在此背景下,传统的性能测试面临诸多问题:

搭建1万用户并发测试环境需要10台物理主机;测试环境部署时间超过5天,环境复用率低; 10000个并发用户的License授权费用超过100万;工具脚本、数据、报表管理分散,存在重大安全风险; loadrunner、Jmeter等测试工具操作复杂,学习成本较高,普通测试人员难以掌握。随着传统性能测试的衰落,云压力测试迅速吸收养分迎头赶上,迎来了性能测试创新变革的春天。

云压测的概念诞生于2005年,随着云计算技术的快速发展,利用云资源实现弹性、可扩展、可自由扩展的分布式压力生成模型。云压力测试利用云资源,实现一站式性能测试,可以模拟系统的各种异常场景。用户不再需要购买包括服务器、机房在内的各种资源,可以节省大量的资源成本和人力成本。目前,Soasta等国外公司和瑞祥云等国内公司的云压力测试产品已成为传统性能测试平台的最强对手。

与传统的性能测试方案相比,云压力测试有四大优势:

简单易用:3分钟即可生成云压测脚本。由于所有测试资源都部署在云端,因此可以秒级启动。同时可以秒级返回测试数据,同步定位性能问题。全栈监控:云压测产品基于分布式云计算服务,可以基于位置快速响应,还可以实现同步监控数据回溯,实现全栈监控数据采集,全面覆盖网络层、服务器层和操作系统。层和应用层。大规模部署:大多数云压测厂商的测试节点可以覆盖全球,可以实现基于位置的按需定制。他们还可以实现全链路真实节点,达到千万级并发请求。高性价比:SaaS服务天然具有灵活性的优势。云压测产品可按需计费,无需部署硬件。很容易实现集成测试管理服务,团队还可以实现小组协作,大大提高性能。工作效率。如何开始高质量的性能测试?

“云压测平台可以帮助用户解决哪些性能问题?如何解决?”

一般来说,分析性能问题需要从网络层、操作系统层、应用服务器、服务器问题四个层面入手。网络层面,主要问题是带宽不足、网络抖动异常。如果采用机房IDC部署,还需要考虑交换机的汇聚比;在操作系统层面,一个典型的问题是参数标准化,比如Sysctl和一些网络参数。配置问题;在服务器端,在CPU监控过程中,需要区分哪些进程的CPU使用率过高。如果进程使用率太高,还需要分析一下进程使用率是什么样的。如果磁盘IO读写过高,则需要考虑是否有更好的SSD硬盘。

如果想要更系统地分析性能测试问题,更全面地探讨性能问题,那么系统、完整的测试流程是必不可少的。

完整的测试流程如上图所示,从需求分析开始,到测试规划、脚本编写、测试准备,然后进行综合分析,最后出具评估报告。报告中会包含监控数据、配置数据等一些指标。输出。

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?

在云压测中,需求分析过程需要关注几个重要点,包括网络信息的收集、防火墙信息、防病毒墙、负载均衡设备、软硬件加解密、应用的结构化部署、用户信息的收集等。运营。习惯使用评估等等,这些点分析得更全面之后,就可以创建一些更真实的场景。

在测试规划中,更重要的是了解各个地区访问时间的差异。例如,对比北上广深的一些偏远山区,这些地区在接入过程中的响应时间是否基本一致,如果不是,运维人员需要分析问题比如服务器的摆放、CPN配置是否合理等。

在剧本编写方面,需要简化流程,让业务人员也能参与编写。这样做的好处是业务人员也可以参与测试。在分析测试场景时,最接近市场的业务人员可以比一些常规技术人员分析得更透彻。

在测试准备过程中,监控工具应该尽可能全面。除了典型的五个主要项目外,还需要包括一些错位的预制快速输出。被监控的软硬件机器必须具备类似自动报警的功能。一旦发生大规模问题,可以给运维人员快速提示,以便其快速响应。

在综合分析过程中,需要注意的是,预估的基础数据量和测试数据量与生产需求基本一致,这样测试结果与真实的在线访问结果基本上不会相差太大,并且会非常准确。参考价值。

分析过程可以借助工具来完成。提前分析各个节点需要输出的内容,组织整个测试流程。只有最终的报告或者调优指标参数才会有一定的参考价值,整个测试的输出结果才有望成为后期运维高质量部署的参考。

生产事务日志分析的重要性不言而喻。从上图来看,有大量关于业务分布状况的pin信息。这可能是访问异常的场景,需要对响应时间过长的请求进行全面分析。分析包括正常基本量、交易高峰期、特殊交易日、生产故障报告、环境满载模拟等,如果这些模拟都到位的话,基本上不会出现大的错误。

在生产环境压力测试中,测试数据准备过程比较长,数据清理时可能会出现数据丢失或遗漏的情况。针对这个问题,瑞享云根据长期的性能测试经验总结了四种方法:

数据嵌入。即测试库挂在生产应用下面,这样即使测试性能稍低,也基本可以测出真实接入过程的效果,而且数据基本隔离,不会被污染,使得以后更容易清理。非接口身份修改。常用的是http请求头中的user-agent字段的标识来区分。在请求识别中,可以选择一些不常见的请求头,后端会对这些数据进行业务分析并进行标记,以提高后期数据清理的速度。绕过数据路由。当业务流程非常清晰的时候,就可以将正常业务数据和压测数据分开处理,然后对压测数据表进行跟踪和清理。如果您只在网上做查询交易,瑞祥云主要是清理流量表和记录表,不会影响正常业务。接口字段标识修改。在关键数据表中预留压测字段的标识位,压测阶段可以直接填写标识类型的信息,以后可以直接据此进行数据清洗。通过以上的分析,相信大家对压力测试的方面以及注意事项有了比较深入的了解。那么,让我们回到原来问题的探索上来。云压测平台可以帮助企业解决哪些性能问题?主要在于4点:

真实的商业流量模拟。基于云压力测试,不仅可以模拟成百上千用户的真实访问,还可以实现灵活多变的用户行为模拟,实现用户的快速扩展。同时还可以快速验证网络流量质量,通过正常流量验证全网络流量状态。如果企业使用类似F5物理硬件设备的负载均衡,也可以验证物理设备硬件的PPS值是否能够满足高并发要求。资源监控。除了快速检测CPU、内存、磁盘之外,还可以监控数据库资源使用情况,监控一些中间件资源。操作系统应用优化。云压测平台可以为整个压测过程中的Limit参数配置提供非常好的测试基础,还可以对Tomcat连接数、Jboss连接数进行实时调优。定位性能问题。结合一些常见的APM工具,可以快速追踪一些慢事务,分析应用和数据库中的一些常见问题,并进行场景模拟,比如慢事务场景模拟、网络层高吞吐量测试场景模拟等。写在最后

用户评论

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
虚伪了的真心

这个标题太吸引人了!高并发系统崩溃,简直是噩梦,性能测试方法很重要,想知道哪些是正确的。

    有6位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
仅有的余温

高并发系统崩溃,真是太可怕了!性能测试必须得做,不然真的会后悔莫及!

    有16位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
减肥伤身#

性能测试方法很重要,否则高并发系统一旦崩溃,损失惨重!

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
空巷

如何选择正确的性能测试方法,才能避免高并发系统崩溃?

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
初阳

性能测试,一定要做好,不然高并发系统崩溃,可就麻烦了。

    有20位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
傲世九天

高并发系统崩溃,如何预防?性能测试是关键!

    有17位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
ー半忧伤

性能测试,选择正确的测试方法,才能避免系统崩溃。

    有10位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
寒山远黛

高并发系统崩溃,真是令人头疼!性能测试怎么选?

    有12位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
一生只盼一人

性能测试怎么做,才能避免高并发系统崩溃?求指点!

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
为爱放弃

高并发系统崩溃,该如何应对?性能测试方法很重要!

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
巴黎盛开的樱花

高并发系统崩溃的风险,性能测试如何规避?

    有16位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
惯例

高并发系统崩溃,性能测试很重要!

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
关于道别

性能测试方法,选择对了,才能避免高并发系统崩溃。

    有9位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
oО清风挽发oО

高并发系统崩溃,如何避免?性能测试不可忽视!

    有14位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
抓不住i

高并发系统崩溃,性能测试方法选对了吗?

    有5位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
麝香味

性能测试方法,直接关系到高并发系统的稳定性。

    有7位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
闷骚闷出味道了

高并发系统崩溃,性能测试要做好,才能防患于未然。

    有12位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
龙吟凤

性能测试的重要性,在高并发系统崩溃时体现得淋漓尽致。

    有8位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
♂你那刺眼的温柔

高并发系统崩溃,性能测试方法要选对,才能保证系统的稳定性。

    有19位网友表示赞同!

一旦“高并发”系统遭遇“崩溃”,你是否选择了正确的性能测试方法?
矜暮

性能测试方法的选择,直接影响着高并发系统能否稳定运行。

    有11位网友表示赞同!

原创文章,作者:xiaobian,如若转载,请注明出处:https://www.xinyuspace.com/5617.html

(0)
xiaobianxiaobian
上一篇 2024年8月29日
下一篇 2024年8月29日

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注