压测性能分析进阶：XRunner云原生探针

  慢慢变成衡量应用是否可用、好用的关键衡量指标之一。性能测试不同于功能测试、接口测试，性能更多关注于

  这里用户的“不好用”就是性能测试的核心重点。通过种种监控手段采集相关性能数据后，基于业务分析在各链路上的耗时、判断系统瓶颈是做性能测试、性能优化分析必不可少的环节。但是在当下这种靠自身能力或传统安插Agent、日志等应用性能监控技术逐渐失效，已经没办法满足用户的性能需求以及越来越快的系统迭代速度。

  尤以当下企业全面转向云计算，以容器、微服务架构、DevOps为核心的云原生架构成为降本提质增效的最优路径背景下，大规模容器集群产生更大的业务负载能力、更高的流量突发能力。容器架构的动态变化，对性能监控、分析的范围影响也慢慢变得大与不可预估。因此，如何在云原生时代下更好开展质量领域性能测试，是我们为企业在市场上提供竞争力的弹药之一。

  1）模拟用户业务流程操作，通过录制手段或脚本编辑生成性能测试脚本，对脚本进行参数化、管理、思考时间、集合点设置完成整体性能脚本

  那么我们做性能测试的目的是什么呢？大多数同学刚开始做性能测试的时候，都是做完性能脚本调试、设置完压测模型、执行完脚本，看下系统的CPU、内存、吞吐量、事务TPS，在输出一份测试报告就结束了。

  这种流程和测试报告在过去10年前或许是可接受的，这受限于当初的技术架构（单体、前后端）和监控分析手段，但在当下技术架构、业务场景、客户的真实需求、研发模式、敏捷转型、研发效能等诸多内、外环境的变化，企业对性能测试的目的越来越多样化、针对性。

  2、确定系统的最大用户数：比如系统在100000个用户下平均响应时间4秒

  3、确定系统的最佳配置：比如在Centos7、8C16G、500G配置下，某业务支持50000个用户同时访问，平均响应时间1秒

  性能测试目的确定后，往往都是基于此目的去做性能压测实施和监控数据分析，这里怎么样开展压测实施流程先不展开介绍，我们主要就监控数据分析这部分大家比较少谈的线、

  传统环境下性能监控颗粒度较粗传统环境下系统的应用都是一定要通过物理层网络设施进行流量转发，因此传统环境下，业务应用流量

  但采集到的流量数据无法和业务对应起来，基本都是系统资源上如CPU、内存、吞吐量或者本身服务器（如Tomcat）自带的指标等数据，无法分解到具体某个URL和业务上。

  技术架构升级的性能监控难点过去在单体架构、前后端分离、SOA架构上都能够直接进行物理层网络设施流量采集，随之信息化建设的发展，企业全面转向云计算，微服务架构、容器、DevOps大行其道。

  业务性能需求常态化得益于互联网的快速的提升，各种技术的迭代使其能够很好的满足慢慢的变多的业务形态，比如当下最流行的直播、赛事转播等，这些业务能够让我们身边任何一个人都能随时随地的参与和访问，不能离开性能保障。

  面对传统性能监控的窘境，以及现阶段技术上的框架推动、敏捷开发和自动化监控部署也对性能监控发起了挑战。

  异构环境下流量采集部署目前主流的开源项目底座、国内主流云厂商底环境、信创环境都支持云环境、宿主机、IDC机房部署、流量采集。

  网络接口、数据包捕获通过部署在私有云宿主机，或公有云工作负载的操作系统层，能轻松实现对：

  宿主机统信数据治理与输出对符合特征的流量进行实时解析，可以实时输出如下四种数据类型：

  通过云网一体化性能保障平台（XRunner）的性能诊断探针的实施，能带给企业如下价值体现：