压测2.0:云压测 + APM = 端到端压测解决方案
压力测试是确立系统稳定性的一种测试方法,通常在系统正常运作范围之外进行,以考察其功能极限和隐患。与功能测试不同,压测是以软件响应速度为测试目标的,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。
至于为什么产品或业务系统在通过功能测试后还需要进行压力测试,原因很简单,因为它重要,为什么重要?众所周知,响应速度是用户体验的核心指标之一。 SmartBear 数据表明,如果 Amazon 的加载时间延长1秒,那么一年就会减少16亿美元的营收。用户与网站互动的过程中,如果加载时间超过3秒,57% 的用户会流失。可见,通过压测来优化产品体验和性能是多么的重要。
压测1.0 VS 压测2.0传统的压测方法通常的做法需要准备大量的环境,如测试的压力机,安装测试工具,录制测试脚本,对服务器不断施加“压力”,通过这种方式来确定系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试,这个阶段我们称之为压测1.0。
压测1.0时代的主流压测工具有 LoadRunner , SilkPerformer , Ratinal , QA Load , Jmeter 等等, LoadRunner 为传统压测1.0时代最主要的代表产品。
图1.传统的压测现状
传统的测试方法下很难去做到对整个系统去做一次大型的压力测试,这种情况下只能把每个系统独立开来,对他进行性能测试,然后对整个核心系统去做分析,确定系统的短板,对短板进行压力测试。
通常需要用预估的方式,业务部门估算今年的交易额,应用部门估算,网络部门估算,基础架构部门估算。最后的结果就是如果需要1000台服务器,那么就准备1500台。如果需要5 G 的 CDN 带宽,那么就准备7.5 G 。几乎所有资源都多准备50%。
压测1.0时代的压测缺点很明显。
测试过程缓慢,周期过长 并非聚焦于全球客户的体验 非常昂贵的授权费用及硬件投入 为实验室测试而设计,对生产或线上环境无能为力 不能针对当今复杂的应用及架构提供实时的反馈基于云计算的全链路压力测试我们称之为云压测,这个阶段我们叫压测2.0。云压测通过遍布云端的压力模拟服务器,来制造“真实用户访问”,这个过程可以覆盖到真实交易系统的全链路,全业务测试系统,并且革命性的使用云资源这种轻属性资产,对几乎来自全世界互联网和移动互联网的压力进行测试。云压测模拟测试完全还原真实用户网络访问状况。
图2.“云压测+ APM ”进入压测2.0时代
当产生压测需求时,我们布置在各主流云厂商(AWS、阿里云、Azure、青云、腾讯云、金山云、UCloud等等)的压测虚机自动下发压测脚本,进行云端托管式部署云端压测机启动,对用户系统进行压测。同步压测,同步产出压测数据。
利用云计算优势,当需要进行模拟大规模用户访问时,只要多开云主机就能实现,需要模拟100万的用户访问,再开100台云主机。
云压测的准备时间基本上就是由云主机启动时间来决定,这在压测1.0时代是根本不可能实现的。云压测是在云主机发起的,因此反映了真实的用户访问环境,而压测1.0时代的传统压测方式则必须在内网的模拟环境下进行。
压测2.0时代有点同样明显。
真实世界的规模和模拟 分布式的用户 高效且持续 除去了硬件投入压测1.0时代的 LoadRunner VS 云压测
云压测 + APM = 端到端的性能优化解决方案
图5.云压测 + APM 典型应用场景
与压测1.0时代只关注于后端性能不同,云压测关注前端和后端性能,从前端的不同物理位置、不同运营商链路、宽带、窄带、带宽、 CDN 、防火墙、负载均衡,到后端的应用软件、数据库、硬件资源、系统配比等,云压测在测试环境中还原真实业务环境。
云压测和 APM 结合,全链路全业务接口压力测试,全面覆盖前后端所有环节真正实现端到端性能优化解决方案,全方位提升用户体验。
OneAPM 为更多企业提供全栈式的性能管理以及 IT 运维管理服务。阅读更多文章,请访问 OneAPM 官方技术博客
点击此处,免费申请 OneAPM 云压测产品试用聊聊传统压测和全链路压测的区别 随着互联网行业不断发展,系统架构越发复杂,业务场景越发多样化,对性能测试的要求也越来越高。传统压测方式已经无法满足业务和技术的发展需要,全链路压测,就是在这样的背景下应运而生的。作为性能测试领域新阶段的最佳实践,全链路压测在更多公司被探索和应用的过程中,也遇到了种种挑战。
全链路压测(4):全链路压测的价值是什么? 大促的典型特点是流量大,对系统的冲击比较高。那么精准的测量线上系统的容量,对处理能力薄弱的节点进行扩容升配,优化性能就是很有必要的。
全链路压测(1):认识全链路压测 后来他们内部复盘,一番讨论后,为了避免后续的大促再次出现类似的问题,决定在生产搞压测,这就是现在被很多测试同学所熟知的生产全链路压测的背景由来。
全链路压测(7):核心链路四问 很多企业都会有自己核心的业务范围,这些核心业务也往往是主要的企业利润来源。以电商企业为例,为用户提供商品的购买服务,为商家提供商品的管理和上架及定价展示,利润大多为撮合用户和商家交易所带来的服务费以及广告等相关费用。
全链路压测(8):构建三大模型 单机单接口的压测,可以通过梯度增加请求的方式,观察随着请求的增加,其性能表现&资源损耗的变化。在目前的微服务架构下,整体链路的性能瓶颈,取决于短板(木桶原理)。因此,单机单链路基准测试的目的,是在全链路压测开始前进行性能摸底,定位排查链路瓶颈。
全链路压测第一次实践 电商业务本身比较复杂,且当前阶段我们微服务架构下,各个服务间依赖高,调用关系复杂,且没有较为清晰的链路梳理,理论上来说,只有一部分系统才是核心链路。所以,面临的第一个挑战,就是从错综复杂的系统中梳理出核心业务链路。
全链路压测探索实践之路 全链路压测是一个很复杂的工程,其中涉及到多个服务。对整个业务系统进行梳理,确认流量传递的上下游和范围,是首先要做的事情。
全链路压测(14):生产全链路压测SOP 从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。对于没有太多经验的同学来说,全链路压测的落地,大多还是基于个人的经验和熟悉的领域,即都是在局部作战,缺乏全局的视角和可视化地图。从全局来讲,缺少适用于自己的全链路压测最佳实践。
全链路压测(12):生产压测必不可少的环节 在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。
Elasticsearch全观测技术解析与应用(构建日志、指标、APM统一观测平台) 立即下载
相关文章
- Vue移动端 Web App 点击穿透问题解决方案
- 系统自带模版在 emlog pro 1.8.0 底部信息错位问题暂时的解决方案
- 解决『MySQL Toad乱码问题解决方案』(mysqltoad乱码)
- 配置Linux SSH参数配置:最优解决方案(linuxssh参数)
- MySQL 5.1启动失败的原因及解决方案(mysql5.1启动失败)
- API优质代理错误问题解决方案
- CJ 2016 | 没有背包的VR无线解决方案来了,你准备好了么
- C语言驱动MySQL失去连接的解决方案(c mysql 链接断开)
- MySQL密码修改失败的解决方案(mysql不能更改密码)
- Redis给你带来的通用解决方案(redis通用解决方案)
- Oracle ETRM优化企业资源管理的最佳解决方案(oracle etrm)
- Redis自增高并发解决方案提高性能(redis自增高并发)
- Oracle 12c 实现高可用性集群部署解决方案(oracle12c 集群)
- C#设置子窗体在主窗体中居中显示解决方案