压测2.0:云压测 + APM = 端到端压测解决方案

本文涉及的产品
性能测试 PTS,5000VUM额度
应用实时监控服务-用户体验监控,每月100OCU免费额度
应用实时监控服务-应用监控,每月50GB免费额度
简介: 压力测试是确立系统稳定性的一种测试方法,通常在系统正常运作范围之外进行,以考察其功能极限和隐患。与功能测试不同,压测是以软件响应速度为测试目标的,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。
从压力测试说起

压力测试是确立系统稳定性的一种测试方法,通常在系统正常运作范围之外进行,以考察其功能极限和隐患。与功能测试不同,压测是以软件响应速度为测试目标的,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。

至于为什么产品或业务系统在通过功能测试后还需要进行压力测试,原因很简单,因为它重要,为什么重要?众所周知,响应速度是用户体验的核心指标之一。 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.0
图1.传统的压测现状

传统的测试方法下很难去做到对整个系统去做一次大型的压力测试,这种情况下只能把每个系统独立开来,对他进行性能测试,然后对整个核心系统去做分析,确定系统的短板,对短板进行压力测试

通常需要用预估的方式,业务部门估算今年的交易额,应用部门估算,网络部门估算,基础架构部门估算。最后的结果就是如果需要1000台服务器,那么就准备1500台。如果需要5 G 的 CDN 带宽,那么就准备7.5 G 。几乎所有资源都多准备50%。

压测1.0时代的压测缺点很明显

  • 测试过程缓慢,周期过长
  • 并非聚焦于全球客户的体验
  • 非常昂贵的授权费用及硬件投入
  • 为实验室测试而设计,对生产或线上环境无能为力
  • 不能针对当今复杂的应用及架构提供实时的反馈

基于云计算的全链路压力测试我们称之为云压测,这个阶段我们叫压测2.0。云压测通过遍布云端的压力模拟服务器,来制造“真实用户访问”,这个过程可以覆盖到真实交易系统的全链路,全业务测试系统,并且革命性的使用云资源这种轻属性资产,对几乎来自全世界互联网和移动互联网的压力进行测试。云压测模拟测试完全还原真实用户网络访问状况

压测1.0
图2.“云压测+ APM ”进入压测2.0时代

当产生压测需求时,我们布置在各主流云厂商(AWS、阿里云、Azure、青云、腾讯云、金山云、UCloud等等)的压测虚机自动下发压测脚本,进行云端托管式部署云端压测机启动,对用户系统进行压测。同步压测,同步产出压测数据。

利用云计算优势,当需要进行模拟大规模用户访问时,只要多开云主机就能实现,需要模拟100万的用户访问,再开100台云主机。

云压测的准备时间基本上就是由云主机启动时间来决定,这在压测1.0时代是根本不可能实现的。云压测是在云主机发起的,因此反映了真实的用户访问环境,而压测1.0时代的传统压测方式则必须在内网的模拟环境下进行。

压测1.0

压测2.0时代有点同样明显。

  • 迅速部署
  • 实时统计
  • 真实世界的规模和模拟
  • 分布式的用户
  • 高效且持续
  • 除去了硬件投入

压测1.0时代的 LoadRunner VS 云压测

比较维度 LoadRunner 云压测
采用技术 研发于90年代,基于c 生于21世纪,基于 Java 及大数据
测试创建 需要 c 编程,测试门槛较高 全可视化操作,上手快
部署方式 纯内网,基于物理服务器 内外网兼顾,云,虚机,物理机
部署时间 长,几周或几个月 很短,数分钟或数小时,测试更频繁
部署费用 昂贵,硬件,人员,时间,其他 便宜,压侧端可全云托管,按小时分钟计费
测试规模 小,一般不超过2000并发规模 可大可小,从100到1千万
统计报表 很有限,非实时,依赖后期数据处理 TB级实时汇聚显示,即测即发现问题
云压测 + APM = 端到端的性能优化解决方案

压测1.0
图5.云压测 + APM 典型应用场景

与压测1.0时代只关注于后端性能不同,云压测关注前端和后端性能,从前端的不同物理位置、不同运营商链路、宽带、窄带、带宽、 CDN 、防火墙、负载均衡,到后端的应用软件、数据库、硬件资源、系统配比等,云压测在测试环境中还原真实业务环境

云压测和 APM 结合,全链路全业务接口压力测试,全面覆盖前后端所有环节真正实现端到端性能优化解决方案,全方位提升用户体验。

OneAPM 为更多企业提供全栈式的性能管理以及 IT 运维管理服务。阅读更多文章,请访问 OneAPM 官方技术博客

点击此处,免费申请 OneAPM 云压测产品试用

相关实践学习
通过云拨测对指定服务器进行Ping/DNS监测
本实验将通过云拨测对指定服务器进行Ping/DNS监测,评估网站服务质量和用户体验。
相关文章
|
22天前
|
存储 Prometheus 运维
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案。该集成结合了ARMS的基础设施监控能力和Prometheus的灵活配置及社区支持,实现了全面、精准的系统状态、性能和错误监控,提升了应用的稳定性和管理效率。通过统一的数据视图和高级查询功能,帮助企业有效应对云原生挑战,促进业务的持续发展。
30 3
|
4月前
|
存储 监控 数据可视化
性能监控之JMeter分布式压测轻量日志解决方案
【8月更文挑战第11天】性能监控之JMeter分布式压测轻量日志解决方案
102 0
性能监控之JMeter分布式压测轻量日志解决方案
|
测试技术
《超大规模性能测试的云端解决方案及案例分享》电子版地址
超大规模性能测试的云端解决方案及案例分享
57 0
《超大规模性能测试的云端解决方案及案例分享》电子版地址
|
存储 算法 Java
性能测试--内存泄漏、内存溢出的解决方案
内存泄露 :是指程序在申请内存后,无法释放已申请的内存空间就造成了内存泄漏,一次内存泄漏似乎不会有大的影响,但内存泄漏堆积后的后果就是内存溢出
878 0
|
移动开发 监控 Cloud Native
手淘TMQ云上性能测试解决方案,解放你的双手
阿里QA导读:10月20日,阿里云移动研发平台EMAS应用质量管理沙龙,首站杭州取得圆满成功!此次沙龙邀请到淘宝高级技术专家韩锷,阿里云技术专家尚仁、玄工、宝文、州牧和大家进行分享交流。现场围绕无线性能测试解决方案、无线App线上质量监控实践、云原生移动DevOps解决方案、热修复服务展开分享交流。阿里云EMAS联合手淘技术,现场重磅发布了TMQ & MQC无线性能测试解决方案,方案基于上云场景进行共建,打造出通用的高标准性能分析工具。
587 0
手淘TMQ云上性能测试解决方案,解放你的双手
|
监控 程序员 开发工具
巧用友盟+U-APM 找出Unity开发游戏启动慢问题解决方案
随着游戏用户的增加,得到越来越多的用户反馈:“游戏打开慢”。使用友盟+U-APM应用性能监控平台找出问题的信息统计,及时快速定位解决问题,以免带来更大的损失。
巧用友盟+U-APM 找出Unity开发游戏启动慢问题解决方案
|
新零售 监控 应用服务中间件
阿里云 APM 解决方案地图
PM是近5年来伴随着云技术、微服务架构发展起来的一个新兴监控领域。在国内外,无论是云厂商(如AWS, Azure,等)还是独立的公司(Dynatrace, Appdynamics,等),都有着非常优秀的APM产品。
8016 0
|
2月前
|
移动开发 监控 Android开发
Android & iOS 使用 ARMS 用户体验监控(RUM)的最佳实践
本文主要介绍了 ARMS 用户体验监控的基本功能特性,并介绍了在几种常见场景下的最佳实践。
316 13
|
4月前
|
运维 监控 数据可视化
ARMS的微服务监控
【8月更文挑战第23天】
76 6
|
7月前
|
监控 Java 索引
APM Server监控
APM Server监控