压测

一、常态化压测介绍1.什么是常态化压测常态是指：“失常的状态”；“化”在这里是示意转变为某种性质或状态。 “常态化”的含意就是：趋势失常的状态。 那么常态化压测顾名思义就能够解释为，让压测趋于失常的状态，趋于正当；因而通过调研给了如下定义：常态化压测是指在某个产品或零碎上进行自定义周期（常态化）的、零碎主动执行的、可验证后果的压测过程。目标是检测产品或零碎的稳定性、可靠性和性能，确保它们可能在不同的场景下失常运行。 2.为什么要进行常态化压测随着业务的一直增长，撑持业务零碎的压力也逐步减少，会面临如零碎越来越厚重、逻辑越来简单、迭代节奏越来越快等繁冗的状况。咱们以后并没有做到在每次变动时疾速辨认出性能危险，检测产品或零碎的稳定性、可靠性，而且咱们还在一直的投入人力老本在压测这件事件上也是不合理的，所以咱们要将性能验证融入到咱们日常的工作中，把压测做到常态化，做成平时的一件事。 3.常态化压测的价值快进快出，最小单位安顿压测工作，缩小人员投入尽早辨认性能稳定，防止危险后置可复用性高，压测模型、业务模型可复用业务可用性保障[]() 二、常态化压测实际1.常态化压测流程介绍借助泰山平台中的Forcebot工具，进行常态化压测执行。设置常态化压测工作，配置压测执行打算，依照预设的数据模型、基线值等进行执行。在累积一段时间的压测后果后，能够对基线值、压测指标进行调整和调优，而后持续进行自动化周期性的压测。同时跟进后果，及时关注最近业务和零碎的变动。 明确压测指标明确常态化压测的指标，能够辨别日常和极限两个场景。依据不同的场景设置不同的压测指标，第一次实际以单接口的日常流量为主，观测日常流量下的性能稳定，确定失常范畴值。 常态化打算依据接口的优先级，接口服务的流量，日常迭代代码改变的频率，设置对应的打算。外围接口、流量较大、代码改变频繁的接口，常态化压测的周期倡议短一些，能够一周1-2次，且放在每次上线后进行；如果是非核心、流量小的接口，能够每周或每双周进行一次。 压测后期筹备确定测试场景依据理论场景，设计压测场景，包含用户数量、申请类型、申请频率、申请参数等，以尽可能模仿实在的业务场景。编写压测脚本，设置依照实在申请数据比例设置参数化，以便于进行自动化测试。 压测中期关注在压测过程中，次要是无人值守的状态，所以须要提前辨认压测可能带来的危险，以及面对不同的危险须要采取的措施。 同时还要关注压测过程中如果呈现性能稳定，零碎收回的预警形式是否及时、预警内容是否精确。 压测前期跟进每次常态化压测打算执行后，都须要关注本次的后果：① 后果合乎预期，则要关注下指标的稳定； ② 若后果并不合乎预期，则要刨根问底，找到问题的所在； ③ 跟进问题直到解决，解决后从新验证。 []() 辅助性能-流量染色流量染色指依据流量协定，设置对应的流量染色规定，对指定的流量进行染色标记，并在整个调用链中携带该标记。 通过流量染色，能够实现压测流量隔离，同时能够保障日常压测对生产流量无影响。然而对于常态化压测来讲，流量染色并非必须，而是精益求精的性能，能够进一步保障咱们的流量对生产无影响。 []() 2.首次进行常态化压测实际2.1 筹备阶段① 获取基线值数据 []() ② 压测脚本、场景、数据模型筹备 ③ 压测环境筹备 ④ 压测打算制订 2.2 执行阶段[]() []() []() []() 2.3 调优阶段以7-10天为一个周期，记录数据。不思考非凡节日、非凡流动的场景，验证基线数据的可信赖性。如发现高于30%的概率，每天的数据都不合乎基线值，可调整基线值的浮动范畴，以保结证后果在日常值的范畴内。 调优的过程也要关注，在数据统计过程中代码的改变，如果确定是代码的改变影响了整体的性能，这就要依据理论的场景和影响范畴进行评估。 2.4 复盘阶段通过一段时间的常态化压测，须要对整个流程和后果进行复盘，好的复盘后果可能帮忙咱们防止后续的一些“坑”。参加常态化压测的所有人员一起，次要关注一下几个方面： ① 数据是否正确，是否达标，是否可信赖 ② 常态化压测流程、打算相干问题 ③ 压测过程中的性能问题总结 三、常态化压测总结① 倡议笼罩场景 能够依据本人所负责的业务进行考量，如果不会呈现很大流量的状况下，倡议笼罩日常场景即可满足需要；如果须要思考大流量并发的场景，倡议笼罩日常的根底上，在笼罩极限的场景。 ② 关注危险管制 常态化压测要做到的是模仿生产实在场景，实现日常自动化压测，尽量做到无人值守，所以提前辨认出可能的危险是十分必要的，同时要列出不同的危险项对应的动作。 ③ 常态化压测只是辅助验证业务性能的一种伎俩 不是说咱们进行常态化压测之后就不须要进行性能测试了，两者之间是没有抵触的。 寄语：每个人负责的工作是不同的，不同人会有不同诉求，对同一件事也会有不同认识，不过苏轼有句话：“犯其至难而图其至远”，意思是说“向最难之处攻坚，谋求最远大的指标”。只心愿咱们能在工作中克服各种艰难，去实现最久远的、可继续的指标。 作者：京东物流 冯海艳 起源：京东云开发者社区 自猿其说Tech

本文内容次要介绍，618医药供应链品质组一次军演压测发现的问题及排查优化过程。旨在给大家借鉴参考。 背景本次军演压测背景是，2B业务线及多个业务侧独特和B中台联结军演。 景象当压测商品卡片接口的时候，cpu达到10%，TPS只有240不满足预期指标，然而TP99曾经达到了1422ms。 排查对于这种TPS不满足预期指标，然而TP99又超高，其实它的起因有很多中可能，通过之前写过的文章对性能瓶颈的一个剖析形式《性能测试监控指标及剖析调优》，咱们能够采纳自下而上的策略去进行排查： 首先是操作系统层面的CPU、内存、网络带宽等，对于团体外部的压测，机器的配置、网络带宽，这些因素运维人员曾经配置到最优的水平了，无需咱们再关怀是否是因为硬件资源零碎层面导致的因素。 接下来从代码层面和JVM层面进行排查，可能是我的项目代码中呈现了线程阻塞，导致线程呈现期待，响应工夫变长，申请不能及时打到被测服务器上。对于这种猜想，咱们能够在压测过程中打线程dump文件，从dump文件中找到哪个线程统一处于期待状态，从而找到对应的代码，查看是否能够进行优化。这块同开发一起剖析整个接口的调用链路，商品卡片接口调用经营端的优惠券的可领可用接口，通过查看此接口的ump监控那个，发现调用量其实并不高。接下来通过查看经营端机器的日志发现，调用可领可用优惠券接口曾经超时了，并且机器CPU曾经偏高，使用率均匀在80%以上。是什么起因导致调用可领可用接口大量超时，成为了问题的关键点。 首先咱们代码层面剖析，这个可领可用优惠券接口还会调用一个过滤器进行过滤，于是猜想是不是这个过滤器接口把CPU打满了，然而通过监控过滤器接口的ump中能够看到它的TP99并不是很高，阐明它的调用量没有下来，这种猜想可能不成立。还好过后代码这设置了一个开关是否应用过滤器，咱们把过滤器的开关敞开后。再次进行压测商品卡片接口，发现还是没有解决问题，TPS依然不高，并且TP99还是很高。阐明这个猜想真是不成立的。 接下来咱们转换思路，查看JVM日志，是否从中寻找到一些蛛丝马迹，果然从JVM的GC日志中可看到Ygc和Fgc的工夫占用比拟长，其中Fullgc的工夫占用工夫达到了7165ms，并且从中能够查看jvm的参数配置，发现Xms 和Xmx配置的值都是1024，只有1个G。问题的起因找到了，这台被压测的机器JVM参数配置的Xms 和Xmx值太小了，如果-Xmx指定偏小，利用可能会导致java.lang.OutOfMemory谬误 对于JVM的介绍这部分比拟宏大波及到类加载形式、JVM内存模型、垃圾回收算法、垃圾收集器类型、GC日志，在这就不做具体阐明了，想要理解具体内容能够看看《深刻了解 JAVA 虚拟机》这本书。 此处简略阐明下什么是Ygc和Fgc，以及Xms、Xmx的含意。 JVM内存模型中，分为新生代、老年代和元空间，新生代又分为eden区、Survivor0、Survivor1区。对象优先在Eden区调配，当Eden区没有足够空间时会进行一次Minor GC，执行完第一次MGC之后，存活的对象会被挪动到Survivor（from）分区，当Survivor区存储满了之后会进行一次Ygc，然而Ygc个别不会影响利用。当老年代内存不足的时候，会进行一次Full GC，也就是Stop the world，零碎将进行运行，清理整个内存堆（包含新生代和老年代） ，FullGC频率过大和工夫过长，会重大影响零碎的运行。 Xms，JVM初始调配的堆内存 Xmx，JVM最大调配的堆内存 个别状况这两个参数配置的值是相等的，以防止在每次GC 后堆内存从新进行调配。 优化最初批改机器的JVM数配置 查看JVM配置参数 重启后再次进行压测，咱们的TPS指标上来了，并且TP99的值也上来了。达到了预期的一个指标。 总结其实对于一个性能瓶颈问题的剖析排查定位，犹如医生看病，须要望闻问切，通过表面现象逐层的去排除一种种的可能性，最终找到其根本原因，隔靴搔痒解决问题。本文介绍的也只是性能瓶颈问题中的一个小小的局部，其实在压测过程中还会遇到各种各样的问题，然而咱们把握了方法论，其实都能够依照雷同的思路去排查，最终找到本源。 作者：京东衰弱 牛金亮 起源：京东云开发者社区

作者：京东物流 王江波 一、常态化压测建设目标为什么做常态化压测？ 目前面临次要问题，性能问题滞后发现，给大促带来不可控危险。目前日常需要频繁迭代，系统配置的变更、上下游依赖的变动、服务器资源置换等诸多因素均会对系统性能产生肯定影响；日常很难做到对所有新我的项目或需要上线前后都进行压测，这就往往导致了很多性能问题推延到大促压测期间才被发现。 大促备战压测备战工夫紧、工作多，压测备战压力较大， 在11.11复盘中，有些部门工时统计中，压测占了较大一部分工作量。而且性能问题相较于其余问题，优化难度大、修复周期长，在大促备战多专项并行资源缓和状况下，频繁的零碎调优给整个大促带来不可控的危险因素。 基于此，引入常态化压测的伎俩，通过每周或每月的定期压测行为，继续把控系统性能体现，保障服务稳定性；同时将需要上线引起的性能问题前置裸露，及时定位优化问题；加重备战压力，晋升压测效率。 二、常态化压测施行流程2.1 常态化压测常态化压测是依照肯定周期或特定触发条件而进行的自动化压测行为，通过在单容器/集群的周期性压测，从而达到监控性能指标变动、及时发现服务性能衰减危险的指标。 2.2 施行策略通过三步走的形式，由浅入深，逐渐在平台技术部落地常态化压测： 第一步 单机试点： 因为首次应用常态化压测，通过隔离单机环境的形式，理解了常态化压测的压测思路、执行流程、压测平台能力反对及危险点摸排； 第二步 集群试点：在履约、根底平台抉择星级外围服务， 在线上环境试点小集群（2-3台）常态化压测工作执行，从线上业务影响、上下游依赖影响、压测平台能力反对、线上压测危险管控等多方面评估常态化压测在线上集群落地的可行性； 第三步 全面开展： 依据履约、根底平台的线上常态化压测集群实际，推广至全平台技术部，并联合Kit压测工具，建设外围服务性能数据看板，统计汇总压测后果性能报表，使服务性能趋势可视化展示；开明大促压测绿色通道，常态化压测达标的服务，大促压测绿通。 2.3 施行流程常态化压测接口：优先选择笼罩业务主流程的外围接口，ops-review的外围服务中星级认证的接口。 压测模版工作抉择基准： 1）依据大促生产峰值流量模型联合服务器资源应用状况设置压测模版工作； 2）梳理链路依赖接口调用，依照最差上游依赖的承载下限并联合本身接口性能从调用量的角度设立压测模板； 3）对于没有上游依赖的服务，依照零碎本身最佳解决能力，从吞吐量或cpu角度设立压测模版； 压测频率：链路长简单接口，倡议每天执行；自闭环的零碎举荐依照上线频率执行。 压测窗口期： 和产研确认业务低峰期间，指定常态化压测工作的执行工夫。 压测环境： 生产环境单机或者小集群进行常态化压测。 压测数据： 倡议应用R2录制线上的实在流量作为常态化压测的入参，保障压测后果的有效性。 压测后果： 每次压测后果测试同学值班跟进，对不达标的接口，行云bug继续跟踪，协同研发进行性能剖析、问题排查、压测工作保护。 压测工具：forcebot常态化压测及R2 三、常态化打算•2023-Q1在履约、根底进行常态化压测试点，造成最佳实际，并进行技术赋能分享。 •2023-Q2季度推广至平台技术部-配运和交易条线，618大促前平台技术部实现外围0级读服务125个基于jdos3.0的常态化压测建设。 四、基于流量录制的高保真压测双十一大促刚过，在大促备战时很重要的一个环节是对各大外围服务零碎进行压测，以保证系统在大促期间的稳定性，同时依据压测后果为大促扩容提供数据反对。那么如何进行高保真压测，使压测后果更靠近于线上真实性能体现？在整个压测过程中，压测数据的筹备是其中十分重要的环节，很大水平上决定了压测后果是否实在牢靠； 随着业务的一直倒退，不仅用户流量、业务场景越来越简单，服务的调用关系和模块也越来越繁多，数据结构越来越艰难，简略的数据集无奈模仿线上实在的业务流量，流量配比不实在容易导致压测后果失真。 目前各大公司进行模块级压测或者全链路压测根本都是采纳流量录制的形式，先对录制的流量进行存储，而后对流量进行编辑、过滤后通过压测引擎向被测服务发压；本章联合Forcebot压测平台，具体介绍如何应用R2平台录制线上流量进行高保真压测。 4.1 流量录制压测利用R2平台录制线上流量进行压测的根本框架图如下所示： 1、用户拜访线上服务，产生基于用户的实在流量； 2、测试人员在泰山平台R2工具治理端创立录制工作，工作启动时下发操作指令到ducc，再通过ducc下发录制指令到线上服务端（线上服务曾经开启pfinder并接入R2平台），开始录制线上流量； 3、录制的流量会上报至R2工具端，并且将采纳数据进行存储； 4、流量录制实现后，能够在Forcebot压测工具平台创立压测脚本，Forcebot平台曾经和R2平台对接，申请R2服务端获取回放流量地址，进行录制流量装载； 5、Forcebot平台获取到流量后，即能够失常通过压力机向被测服务发压，执行压测工作。 4.2 录制压测流量依据零碎架构及压测场景剖析，抉择须要录制流量的接口及场景。 •若压测时仅思考单个接口，那么录制单个接口流量即可； •而有的利用是多个外围接口，须要混合场景压测，在录制流量时须要同时对多个接口流量进行录制； •当然，你也能够在录制工作中设置仅录制申请或响应合乎某种特定业务场景的流量； ① 创立压测流量录制工作：抉择入口利用，设置录制工作的名称及文件大小，留神：个别在进行压测流量录制时，倡议录制所有场景流量，尽可能地高保真生产理论流量；在创立录制工作时，倡议录制文件大小不高于2G； 流量录制策略蕴含了手动录制、定时录制及周期性录制。在进行常态化压测时，为了防止流量过于老旧与以后生产流量偏差较大，能够在R2平台上创立一个周期录制流量的工作，按天或按周录制一遍生产流量，以保障压测数据的即时性。 ② 抉择要录制的起始服务，能够抉择多个接口同时录制，平台会展现出接口调用链路，能够针对调用链路上的服务或中间件等同时开启录制，而后抉择录制的实例，设置后工作之后就能够开始执行录制。 流量录制实现后，即可在forcebot压测平台创立压测脚本； 4.3 压测脚本创立4.3.1 单接口压测脚本在脚本治理中创立一个JSF回放脚本，编辑录制信息配置，抉择要压测的利用、对应的R2录制流量工作，Forcebot反对在京东私服平台上搜寻或者手动上传JSF文件（jar包），平台会主动而后解析jar包中的类和办法，调用jsfOpenApi获取接口别名和直连的ipPort。通过以上形式获取接口服务相干信息，疾速搭建jsf接口的环境。抉择要压测的接口、jsf别名以及压测的办法后主动会生成压测脚本；生成的脚本中默认关联了抉择的R2录制工作中的录制申请，能够间接进行压力测试。 ...

前言：得物在生产环境进行压测之前是通过在1:1还原的在独自环境进行压测的。这个压测计划除了不仿真外，服务外包含数据存储也是独立的一套。为了升高压测老本，同时保障压测的高拟仿真度，咱们采纳了全链路生产环境压测的计划。 全链路压测的外围问题之一是要解决数据隔离问题。压测的流量不能净化线上数据。咱们通过中间件平台研发的fusion脚手架，在RPC、Redis、DB、MQ、跨线程中透传压测标，如果是压测流量，产生的数据会写入影子库，实现了中间件层面可撑持全链路压测的根底能力。 之前咱们是应用的一个开源的压测平台。然而咱们通过几年的应用发现这个平台保护老本比拟高，架构设计也不太适宜得物的基础设施。因而咱们自研了得物的新压测平台（二开JMeter），并很好地撑持了大促压测。自研平台反对多种协定比方Dubbo、HTTP、GRPC、Websocket、Java等。并可反对多种发压形式，如指定QPS/TPS，指定线程数压测等等。压测完结后，可能主动生成全面的压测报告数据，帮助剖析、排查问题。压测平台底层齐全应用得物的基础设施，压测平台应用的压力机也全都容器化，让发压更稳固，老本更低。通过自建压测平台，实现了平台层面的全链路压测的撑持能力。 这里着重讲一下为什么要反对固定QPS模式压测，随着公司的业务倒退，对线上稳定性方面有了更高的要求和挑战，这势必要求可能摸底各个域利用的性能的瓶颈，针对线上的摸高，无疑是如履薄冰。因而依照并发数自觉的去压力测试，很有可能造成线上故障，可能把控压测的流量，且很精准，联合各个域给出的QPS/TPS目标值压测，很大水平缩小了大促筹备工夫，投入人力也逐年缩小，同时也缩小了因压测带来的稳定性问题。 1. 压测平台性能简介压测平台为了升高压测平台保护老本，压测流程提效，晋升压测的易用性和体验性，保障压测期间的稳定性而建设。面对当今大流量的时代背景，无疑不是一件摸底利用性能瓶颈的利器，也是一份技术保障。 新压测平台采纳JMeter引擎，外围特色性能如下： 反对全链路高并发压测反对多协定HTTP、Dubbo、Websocket、GRPC、JDBC、Java反对多种压测模式，并发模式，吞吐量模式反对内外网，全网通拜访压测反对在线脚本施压配置联动更改反对多种资源池模式，动静资源池即压力机动静容器申请，即用即启，即停即开释的高效资源利用模式以及固定资源池模式反对无主发压模式，高效发压破除主控机瓶颈反对压测机自监控反对主动生成全面的压测报告数据和压测QPS&响应工夫曲线图反对定时工作自动化脚本执行单笔调试性能 2. 压测平台架构设计整体架构和旧版开源压测平台比照： 3. 压测平台外围压测逻辑3.1 施压流程该阶段包含施压前场景的创立、压力机容器的动态创建、施压、压测报告上报。 压测执行时序图： 压测节点的流转： 吞吐模式限流的实现： 吞吐模式即固定QPS进行压测，实现逻辑如下图： 3.2 压测生命周期压测生命周期大体分三个阶段：压测前、压测中、压测后，接下来装置这三个阶段来进行讲述压测平台在每个阶段的次要工作和流程，心愿可能帮忙你了解压测逻辑和到底都做了哪些事件。 压测前 压测前的压测平台的筹备工作：压力机资源的预估和申请、压测脚本文件JMX的开发和调试、参数文件的开发和上传（上传到压测平台），压测线程组下接口QPS目标值的设置。 压测中 管控页面针对上传的JMX文件主动填充JMeter监听器BackendListener监听器并设置InfluxDB时序库实例地址进行压测数据的收集，利用得物自建的grafana进行压测数据的拉取进行渲染，其中监控包含：接口总申请数、总谬误数、总QPS/TPS、接口维度QPS/TPS、压力机维度QPS/TPS、均匀RT、95lineRT进行监控绘图直观展现，图如下： 压测后 压测报告在压测完结后进行计算生产，在压力机上报完结状态心跳时候，压测管控服务通过压测惟一编号进行异步获取InfluxDB中的压测数据，计算并存储到MySQL，折线图元数据信息通过JSON文件信息保留到得物自建的分布式文件系统HDFS。 压测后果 压力机CPU均匀使用率30%，内存均匀使用率50%，自建influnDB服务器内存、IO都很衰弱。 4. 压测总结压测平台次要解决JMeter集群去master中心化，解决掉单点瓶颈，须要思考三点： 首先，须要思考集群形式和启动形式（这里就不进行架构图展现了），JMeter中心化集群是通过配置文件配置各个节点的IP和PORT通Java的RMI协定进行近程启动各个slave节点，去中心化后，没有master节点进行治理，去除掉了集群配置文件，每个节点都是master节点，没有相互依赖关系，通过发送shell命令并发近程启动各个节点。 其次，要思考存储压测元数据存储DB（InfluxDB时序库）的压力。这点要阐明一下，因为JMeter集群上报压测元数据信息逻辑是通过slave节点通过Java的RMI协定上报给到Master节点（这里也就是Master节点性能瓶颈的起因），master节点在通过配置的监听器上报给到InfluxDB，去中心化后，不存在master-slave的概念，因而每个节点都要会上报压测元数据到时序库，因而influxDB存在较大的写压力和读压力，这里须要思考influxDB的性能优化了，如集群化部署、性能调优等。 而后，压测报告的收集聚合，压测中的监控联合grafana进行定制化配置聚合脚本语句实现，压测报告也是同样的原理，继承influxdb客户端写聚合脚本来进行计算存储。在解决了上述三个问题后，高并发的全链路压测就能够依据压测指标来进行压力机数量的配置来满足压测需要了。 5. 将来瞻望压测平台经验多轮大促压测的锻炼，目前已满足高吞吐压测的能力。  针对前面得物压测平台的倒退在提效、性能易用，性能自动化剖析等方面，咱们也做了后续布局： 通过数据荡涤与数据脱敏、数据放大，来结构压测数据，以缩小数据结构的压力；反对在线压测吞吐量的批改；反对在线编辑JMX次要组件（面向用户更傻瓜容易上手，屏蔽JMeter的学习老本）；反对用户提出的其余协定压测，eg: RocketMQ等；反对压测后果主动分析判断接口达标率；反对接口自熔断，无需人工盯盘；反对压测预案自动化；反对联动流量录制主动生成JMX脚本进行压测，可能联合相干性能剖析组件给出优化意见。得物压测平台始终在继续欠缺和晋升中，心愿本文能抛砖引玉，提供压测平台建设方面的一些参考教训。 *文/史一鑫@得物技术公众号

618又来了，往年的年中大考，你是不是又遇到了稳定性问题？ 每年这个时候，总有企业因为大促激增的流量导致系统稳定性呈现问题，数十倍的流量涌入零碎，总有一些企业因为没有做好事先筹备，最终影响用户的理论应用体验。 数列聚焦稳定性畛域多年，已帮忙网上国网、顺丰、T3呈现等50+企业建设稳定性保障体系，为了帮忙更多企业，去年6月咱们开源了首款生产环境全链路压测平台Takin。在这一年里，咱们的开源产品被来自各行各业的用户应用，为他们的零碎稳定性建设助力。 不齐全统计，企业信息均为开源用户提供 在开源一周年之际，咱们特地策动《Takin应用训练营》课程，让更多人更好更快地应用起来，帮忙企业降低生产全链路压测平台的开发复杂度，在无业务代码侵入的状况下，解决大促零碎保障问题，实现零碎“0故障”！报名课程即有机会取得SKG颈椎按摩仪、精美快客杯、sre书籍等好礼哦！ 话不多说，第一期收费课程曾经开始报名啦！欢送来撩！ 扫码回复【训练营】锁定限量收费名额！ 流动详情 转发流动还能获取《大促保障作战手册》、《压测材料包》 还不快口头？ 扫码立刻进入班级群！

4月27日，中国信通院主办的首届“寰球信息系统稳定性峰会”在北京隆重召开，数列科技作为《信息系统稳定性保障能力建设指南》的次要参编单位受邀缺席，并发表了主题演讲。与中国工程院院士廖湘科、网信办副局长观望、中国通信标准化协会副理事长代晓慧、信通院副院长魏亮、信通院云大所所长何宝宏等领导，中国铁路12306、京东、支付宝、浙江挪动等知名企业专家一起，独特探讨信息系统稳定性建设的当初与将来。 作为寰球第一家将全链路压测产品开源的企业，数列科技受邀成为首批信通院分布式稳定性实验室成员单位，同时数列联结创始人杨德华学生被聘为实验室高级技术专家，与23位资深专家及50余位各行业企业专家一起，踊跃共享、流传零碎稳定性常识与教训，推动寰球数据系统稳定性迈上新台阶。 作为国内较早提供零碎稳定性保障服务的企业，数列科技在过来5年服务了蕴含金融、电子政务、物流等泛滥行业的头部客户，在数字化利用渐深的当下，咱们能看到越来越多的大中型企业，正在面临着各类零碎稳定性问题。 零碎问题日益简单，稳定性保障形式也在随之改革，从单点压测评估、搭建模仿环境进行压测到生产环境全链路压测，过来10年，互联网头部企业曾经摸索出了一套卓有成效的稳定性建设形式。然而，更多传统行业、中型企业，则囿于各自的行业、零碎、组织个性，还在面临着破局的窘境。 中间件革新不是所有企业都能有这个人力和工夫投入，开源软件Takin 给了一种更好的抉择：无需革新业务代码，通过JVM层实现压测数据辨认和转发，疾速实现生产压测。Takin开源地址：https://github.com/shulieTech/Takin

随着数据化和信息化浪潮的深刻，零碎的架构在一直地演变，实现了从“单线程”到“多线程、多组件”再到“分布式、微服务”的一个逾越。目前国内外中大型企业根本都采纳的是分布式系统架构，复杂程度高。机器是异构的，不同的机器厂商，会呈现配置不同、运算、存储性能不同、网络提早、带宽不同的状况。业务零碎是分布式的，中间件也是分布式，网络也会有各种各样的节点，咱们没方法去保障每一个节点它都是相对可用的。这外面的任何一环呈现问题，都可能引发系统故障。2020年，新冠疫情使得实体经济蒙受重创，倒逼各行业减速进行数字化转型降级 。随着人们生产习惯的变更，数字经济开始锋芒毕露，一直扩张的宏大用户群体在一些特定的场景下同时涌入零碎，对分布式系统稳定性发动更高的挑战，导致故障频发。  国外亚马逊、谷歌云都曾挂机过，天猫双十一系统故障甚至上了微博热搜以及央视报道，就在2021 年，滴滴早顶峰也呈现零碎问题，就连美联储也逃不开系统故障。这些事变都在阐明一个事实——目前大多数的企业和组织并没有找到适合的系统故障应答形式，少数仍旧采取被动进攻的形式，后果往往不尽如人意。那么到底该如何保障宏大简单的分布式系统的稳定性，走出故障频发的困局呢？ 毛教师教你要学会“踊跃进攻”毛教师对中国的影响源远流长，他“踊跃进攻”的战略思想，是领导中国革命战争全局与国家军事奋斗全局的基本战略思想，奠定了中国稳固长足发展的基石。这对于咱们来说有很强的指导意义，不同的是咱们的奋斗对象是系统故障，指标是保障系统稳固。  《矛盾论》和《实践论》是毛教师思维的精髓凝聚，先来回顾一下：矛盾论次要讲的是矛盾具备普遍性与特殊性、主次矛盾以及矛盾的主次方面；实践论次要讲的是实际是认知的起源与倒退能源，实际也是测验认知的规范。 分布式系统的稳定性保障自身就比拟难，再加上顶峰流量场景，比方常见的双 11 或者是突发疫情导致行程卡的拜访比平时多 20 倍的状况，咱们该怎么保证系统的稳定性？想要解决这个问题，首先要去辨认它的主要矛盾和次要矛盾，进而再去扭转不稳固的现状。那主要矛盾是什么？咱们又该怎么做到“踊跃进攻”呢？ 笔者认为这个主要矛盾就是超大流量冲击超简单的零碎，仍旧靠单点去做评估，要晓得仅从单点去冲破，没有从全局去思考就没有把握能获得全局的稳定性。 “踊跃进攻”当然这不是嘴上说说就行的，具体还是要进行实际。咱们能够向平安行业取取经，“当初的平安是以合规作为测验规范，比方某个单位有没有安全设备，如果有了是不是代表有平安的能力？平安讲一百遍不如打一遍。”360团体董事长兼CEO周鸿祎在某次国内论坛上示意实战应该作为检验能力的唯一标准，而他所说的打一遍就是要对线上零碎做攻防演练。同理零碎稳定性保障也是如此，被动进行峰值流量零碎全链路压测、容量演练是解决主要矛盾的要害一步。 用实际教你如何正确构建踊跃进攻体系  先来看一组数据，2017年故障时长1106min到2020年的0min，这是怎么做到的？ 明天就借用物流行业的一家企业实践经验来通知大家如何构建踊跃进攻体系。该企业从2017年开始倒退快递业务，到2021年Q3， 支出从70亿快速增长三倍到当初的200亿，随着业务的一直扩张，企业的IT零碎也在经验着翻天覆地的变动，为了保障业务的稳固倒退，零碎的稳定性保障也逐步从被动进攻转向踊跃进攻。 测试环境压测2017年他们采纳的形式是搭建性能测试环境进行零碎压测，可消耗了大量的人力、硬件资源老本，最初失去的成果还是差强人意，当年双十一0点零碎还是呈现了故障，解体2小时导致无奈接单，损失惨重。因为测试环境的差异性，一些故障只有在线上才会浮现，当呈现故障后再进行排查定位修复这就是被动进攻，无奈保障系统继续稳固可用。 生产全链路压测意识到问题所在，他们想要参考阿里双十一，采纳生产环境来做全链路压测，被动进行生产环境零碎稳定性验证。这里就遇到了一个外围难点——实现数据隔离，阿里采纳的是通过革新中间件实现压测数据的辨认和转发到影子区域的计划，可这并不适用于所有的企业。许多企业与该物流公司一样存在中间件不对立、人才储备稀缺、老本考量的问题。 最终他们采纳了市面上成熟的开源产品Takin，利用JavaAgent字节码加强技术，无需革新业务零碎，从JVM层面来实现压测数据的辨认和转发。只有装了Takin的 Agent 探针，压测流量本人就会乖乖去到这个影子库外面。当然还有一个很重要的货色，如果我是一个领取申请，我不能把压测申请转发到支付宝或微信，Takin的挡板性能就能帮忙拦挡。此外也有一些 job 或者 check job，只有装置了探针，也能够虚构出 job 的影子过程去做这个事件。 平台工具只是实现目标的一个伎俩，具体的施行过程其实十分重要，也会影响到最终的保障成果，生产环境全链路压测在施行中有6项关键性的工作。 压测是一个团队协同配合的工作，演练一方面是演练零碎，另一方面是演练整个组织的这个应急反馈的体系，所以基本上整个过程 IT 团队的每个角色基本上都要参加进来。 通过生产环境全链路压测该企业在硬件资源投入方面缩小了63%，在人力投入方面缩小了65%，也达成了双十一顶峰期间的零碎0故障的指标。 7*24H生产巡检后面始终在讲通过演练去确保双 11 流量顶峰零碎没有问题，解决了主要矛盾，接下来要解决的次要矛盾了。业务量大、业务流程简单，零碎每天都要做公布，那怎么确保公布之后零碎是没有问题的？或者说如果某个laaS层或者 pass 层的组件出了问题，怎么确保外围零碎都是 OK 的？快递公司零碎是 7 24 小时的运作的，并不是每一个外围服务都会继续有流量，以订单服务为例，白天流量会比拟高，但到早晨就不高了，因为下订单的人都睡觉去了，而像直达服务它早晨才是流量顶峰。曾有过这样的难堪，早晨零碎订单服务做了变更，到了第二天早上流量才 100 它就呈现故障。很多时候可能都是这种非500或者非200的报错，甚至个间接抛一些 error 来，它并不是业务逻辑的谬误。为了缩小公布之后的零碎意外，利用Takin中Agent的数据隔离能力，实现了实在流量在跑的时候同步进行巡检，此外利用测试流量进行724小时的业务巡检。通过设定响应工夫、成功率去做零碎监测，当理论响应工夫/成功率超过预设值时，巡检零碎就会收回揭示，服务飘红/飘黄。 总结一下，巡检就是把非业务逻辑的报错，通过技术相干的指标给间接反馈进去。起初该企业还基于巡检以及TakinAgent在生产环境实现了混沌工程，被动模仿注入故障来进一步测验零碎的稳定性。 平安畛域有个“零信赖”理念：永不信赖，继续验证。简略来说就是认为你每一次拜访都是不平安的，而后一直地验证你的行为。映射到零碎稳定性保障畛域，当企业具备这种被动验证零碎稳定性的能力，验证的次数越多，你播种的价值就越大。提前发现零碎问题并解决，能力无效地保障业务的连贯性，同时可能将更多的工夫投入到解决业务的问题上，踊跃进攻的效益可见一斑。 文中提及的Takin产品外围代码已在Github上开源，有趣味的能够自行理解。 开源地址：https://github.com/shulieTech...

作者：灵苒 在理论的业务场景中，压测是必不可少的一环，无论是对服务器、数据库、网络等性能瓶颈的评估，还是如浏览、下单、领取等重要流量节点的业务连续性保障，亦或是搬站上云整体业务稳定性的预估，这些都须要性能压测来帮忙你建设对系统和业务的残缺认知。依据 Google 的统计，如果网站关上慢每 500 毫秒，用户访问量将降落 20%。依据 Amazon 统计，每慢 100 毫秒，交易额降落 1%。这些事件和统计数据为大家敲响了警钟，也主观阐明了性能压测对于企业应用的重要性。 压测是通过模仿用户行为对业务零碎发动申请，测算出零碎的承载能力，并对系统做一次全面的体检，压测后可依据压测体现优化零碎瓶颈，防止出现线上故障。 业界常见的压测软件 JMeter 和 PTS目前 JMeter 是性能压测畛域利用最宽泛的开源软件。 对于场景简略，要求测试并发量不高的状况下，JMeter 本地测试就能满足需要。但随着互联网用户的减少，对系统承载更大并发的需要日渐晋升，而单台 JMeter 施压机的施压能力有肯定下限，所以须要应用多台施压机，以进步 JMeter 的施压能力，这就要应用到 JMeter 的分布式施压性能。 但 JMeter 的分布式压测前置筹备较多，须要留神以下几点： 施压机的防火墙已敞开或关上了正确的端口。为 RMI 设置了 SSL 或禁用了它。所有施压机都在同一个子网上。如果应用 192.xxx或10.xxx IP 地址，则服务器位于同一子网中。所有施压机上应用雷同版本的 JMeter 和 Java。所有施压机都曾经拷贝了切分好的 CSV 数据文件、依赖 jar 包等。已配置好监控数据的收集。由此可见 JMeter 的分布式压测须要本人协调各资源，前置筹备比拟麻烦，对施行压测的人员来说压测效率低。 PTS 是阿里云研发的性能测试工具，最后次要为了模仿双十一流量洪峰，现在已走过十个年头，在场景编排、压测执行、压测监控剖析、报告总结等各方面能力绝对欠缺，可提供百万并发、千万 TPS 流量发动能力，并且还能齐全兼容 JMeter，可人造补救 JMeter 在性能压测中的劣势。对应用 JMerer 无奈绕过集群问题的用户是一个很好的抉择。 PTS 的 JMeter 压测极大的简化了 JMeter 分布式压测流程，同时也升高了压测过程中对施压机的保护老本。应用 PTS 的 JMeter 压测，用户只须要在控制台配置须要应用的机器数，毋庸用户提前准备多台已装置雷同 Java 和 JMeter 版本的施压机。同时毋庸用户依据施压机数量去切分 CSV 参数文件；压测完结后，PTS 会将监控数据汇总产生一个具体的压测报告供用户查阅。 ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 老板让你做一个 MySQL 的性能基准测试，测来测去发现明明机器配置很高，但 tps 就是上不去，为什么？ 首先咱们很容易想到的就是 InnoDB 缓冲池设置的不够大、 redo log 太小、数据没有充沛预热、 sysbench 线程数开的太少... 这些是很常见的起因，明天咱们来看一些不那么不言而喻的状况。 以下案例的硬件配置为：64core、256Gmemory、raid 10 15K 机械盘。 网络瓶颈一次压测后果是这样的： sysbench oltp_read_write --mysql-host=10.18x.xx.104 --mysql-port=3308 \--mysql-user=sysbench --mysql-password=sysbench --mysql-db=sbtest --tables=10 \--table-size=10000000 --report-interval=5 --threads=200 --time=600 run##后果：SQL statistics: queries performed: read: 4682958 write: 1337988 other: 668994 total: 6689940 transactions: 334497 (2783.82 per sec.) queries: 6689940 (55676.32 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.)后果 tps 只有 2800，显然对不起这么高的硬件，这时候就得察看负载了，个别最显著的一点就是 CPU 使用率低，比方这个案例在我的环境上 CPU 使用率只有36%，而网卡流量很高达到 124MB/s ，差不多就是千兆网卡的极限了(1000Mb/s / 8)： ...

中通快递作为国内出名综合物流服务企业，已间断5年稳坐行业市场份额榜首。受双11、618等大促流动影响，井喷式的业务流量对中通的零碎稳定性提出了更高的要求，过来的压测计划曾经无奈满足业务倒退的需要。测试环境等比缩放导致压测失真、宏大且简单的零碎链路梳理等都是辣手的问题，让咱们一起看看中通是如何利用大促零碎稳定性保障利器Takin来实现这项艰巨的工作的。 背景目前在中通性能测试次要分为线上和线下压测两种计划，在重复实际过程中咱们慢慢发现这两种计划都有着各自不足之处，且为压测工作带来了很多不便。以下就线上和线下压测的有余剖析，谈谈中通是如何一步步改良压测计划并解决问题。 线下压测计划中的有余在线下压测试过程中，为了缩小与实在环境物理资源上的差别，公司采取的是针对CPU与内存进行等比缩放的策略，如果是计算密集型利用，线上环境总的CPU核数为80，线下压测环境总CPU核数为8核，则为10:1的线上线下等比缩放策略，如果是IO（目前只看内存）密集型利用，线上内存总量如果为80G，线下压测环境内存总量为8G，也同样是10:1的线上线下等比缩放策略。很显著这种等比缩放策略在高TPS指标的压测场景下会失真，TPS指标越高，则失真越重大，因为咱们并不能对网络、中间件、数据库等一系列的因子也同样做出等比缩放。 线上压测计划中的有余在线上压测时，多以读接口为主，只有相当大量的写接口会做线上压测，这大量的写接口通常也须要被压利用的开发人员进行代码革新，以防止大量的压测数据对业务数据造成净化。所以这种线上压测形式无奈大范畴利用，同时这种对代码硬革新的形式，也减少了压测老本与危险，导致大家通常不违心面对线上压测，更不必提联结上下游一起进行线上全链路压测了，而这种不敢在线上大量压测的思维，也导致更多压测被放在线下以等比缩放的形式进行，其结果则是压测后果的失真，在2012年，某厂正是因为测试环境等比缩放压测，导致网络流量数据失真，引发了线上故障，才促使其下决心走上了线上全链路压测的路线。 引入技术解决方案因为有上述问题，公司引入了线上全链路压测产品，其特点是应用压测JavaAgent探针以字节码形式植入利用，这样业务利用则毋庸硬编码，就能够自动识别和兼容压测流量，并进行分流，将缓存和存储数据存储到影子区域，实现物理隔离压测数据，防止造成生产数据净化，就技术计划上看，线上全链路压测产品最外围的性能其实就是两点：流量染色与保障数据安全，示意图如下： 全链路压测部署&外围配置线上全链路压测agent装置部署 将pradar-agent.zip包上传到须要接入利用所对应的服务器/home/admin目录下，并间接解压.批改对应利用的启动脚本( 通常在公布平台中批改)，将批改后的前面这个命令增加到java -jar xxx.jar 的-jar之前（ -javaagent:/home/admin/pradar-agent/agent/pradar-core-ext-bootstrap-1.0.0.jar -Dpradar.project.name=该利用利用名 ）重新启动利用在pradar-web操作页面的利用治理页，查看是否胜利上报： agent装置齐全成后，在具体实施时，如果压测入口是http接口，则在申请头中带上“User-Agent：PerfomanceTest”，如果入口是dubbo接口，则在AttachementArgs中带上“p-pradar-cluster-test：true”，agent会将这类申请自动识别为压测流量，它会将压测标识向上游利用传递，并将数据分流到利用所配置的影子资源中，例如redis的影子key、影子数据库（表）、rocketmq上配置的影子TOPIC及生产组等等，由此将压测数据与正式数据进行隔离，防止了压测数据对正式业务数据的净化。 次要影子资源的配置缓存redis的影子资源，在探针辨认为压测流量时，会主动对要写入或者查问的key前加上"PT_"前缀来进行数据隔离，而MQ的TOPIC与生产组影子资源，须要在公司的ZMS配置核心，按业务TOPIC与生产组名称，去新增出带"PT_"前缀的TOPIC与生产组名即可。数据库资源的配置会简单一些，上面独自阐明。影子库配置如下图所示： 影子表配置如下图所示，都是把业务表名前加上“PT_”来示意为影子表，多个表应用逗号分隔： 挡板的配置在线上压测时，有可能会触发到资金扣款或者短信发送等敏感办法，如果大量的压测触发了这类办法，轻则造成骚扰，重则产生重大的资损，相似这样的办法，咱们则须要在梳理压测链路时进行辨认，并为此类办法加上挡板（Mock)，如下图示例，如此当压测探针辨认到压测申请(有压测标)时，则会执行咱们针对此办法所配置的Mock代码，如果是正式的业务流量（无压测标），则依然会执行原来的短信发送办法而不受影响。 链路接入与压测流程做线上全链路压测，很多人放心的一个问题就是，线上生产环境就这么间接压，不怕出问题么，那么除了进行错峰压测以外，中通压测团队为了平安有序的进行线上全链路压测，通过两期接入我的项目的摸索，曾经造成了一整套保障平安压测的施行流程，流程图如下: 全链路压测能够大抵分为三个阶段：1.需要定义与链路梳理阶段；2.测试环境部署及测试阶段；3.线上压测及后果产出阶段。 需要定义与链路梳理需要定义 明确压测的具体业务链路与范畴边界明确压测的目标，是达到指定性能指标，还是摸高进行容量布局具体的性能指标，tps(每秒申请数)/rt(响应工夫)/成功率/SA(以99%为例，指99%的申请响应工夫都在设置的rt范畴之类,也就是RT的达标率)链路梳理链路梳理是全链路压测最为重要也是最外围的环节，通常这个环节的品质，将影响全链路压测的整体施行效率。接下来具体说一下，链路梳理的目标步骤与须要拿到的要害信息 链路大图首先须要梳理出链路调用大图，刚开始不须要太细，但须要对入口/进口/利用名/数据库/缓存/中间件/资金影响/邮件/短信等，相似这样的一些要害信息能梳理到，因为窃密手册的起因，具体的链路图，这里就不放出了，能够用本文最下面的《压测流量链路示意图》进行脑补。 详细信息收集操作手册依据下面梳理的梳路大图，进一步明确具体细节，须要收集如下信息： 利用根底信息与部署信息 链路模块-指的是这次需要所确定的压测链路利用名-利用名称，在jvm中设置时-Dpradar.project.name的value内容利用负责人-个别为利用的主开发人员运维-能够进行agent安装包上传与装置，并查看agent相干日志的零碎运维人员测试负责人-此利用的测试人员DBA-能够进行数据铺底，影子库表创立，数据库性能监控的DBA人员性能指标-本次压测的指标利用的调用链类型与接口-指的是在全链路压测中，本利用在整个链路调用中所通过的接口办法名，以及对应的接口类型，在理解这个信息时，应该要理解分明这些接口办法的作用与逻辑，以此判断出是否须要对其加挡板(mock)，是否须要进行一些测试数据初始化的筹备工作。启动容器-例如tomcat或者jar形式间接启动实例数量-次要是对测试环境与线上环境的实例实进行统计，须要所有实例全副装置agent，不然可能导致压测数据流入到正式的数据库表中。利用入口信息与相干依赖信息 入口-压测的入口数据库jdbc连贯信息-次要是数据库的类型，连贯的域名（或者IP），端口，数据库名称，用户名与明码等相干的信息。用到的表-发动压测后，调用流经到该数据库时，会读哪些表，会写哪些表，数据逻辑是什么，都须要搞清楚，以不便判断怎么造出测试数据，是用影子库形式还是用影子表形式。文件门路-是否会在读写文件的相干信息.redis预设值-发动压测后，调用流经redis的业务与数据逻辑，比方面单的单号是从redis中读取的，则咱们能够依据压测量，在单号寄存的redis中预设（铺底）一批测试单号数据，留神对于redis中预设测试数据，须要思考过期工夫，另外测试数据的key键是在正式的key值前加上PT_来作为影子key。mq的topic-如果波及到mq，则须要建设影子topic与影子生产组，办法都是在正式的topic与生产组前减少PT_来作为影子topic与影子生产组，须要特地留神的是，影子topic/影子生产组与正式的topic/生产组都须要在同一个集群。es索引-在正式的es索引前，加上PT_作为影子索引.hbase-正式表前加上PT_作为影子表.不良影响-在明细信息收集过程中，须要梳理出此利用是否会有产生理论的资金/电话短信邮件/网安数据上报等一系列，有可能因压测而造成的不良影响，针对这些不良影响的调用办法，则须要以加挡板mock的形式绕开。至此，整个链路的业务，技术，数据信息都曾经理解得根本分明了，那么在这个根底上，则能够参考上一节中《全链路压测部署&配置》相干的内容，在测试环境将整个全链路压测环境给部署与配置得当。 测试环境调试全链路压测，向上追述，个别总是能找到一个页面或者APP入口，那么必然对应着一个http的接口，所以为了示意这个申请是全链路压测的影子申请，须要在http头中减少User-Agent:PerfomanceTest，如果入口就间接是一个dubbo入口的话，则在dubbo的Attachment Args里减少key:value为: p-pradar-cluster-test:true 当咱们在测试环境察看到压测流量都按咱们的预期，落入了相干的影子资源，而没有产生数据落入正式资源的状况后，咱们能够在测试环境进行大量数据的压测，如果一切正常，咱们就能够开始着手进入线上环境的压测流程了。 线上压测及后果产出阶段筹备阶段 提前准备线上必须的影子库表，铺底数据，影子topic/影子生产组建设等须要DBA与运维部门撑持的后期事项。提前在pradar-web操作页面的利用治理页对利用的相干配置进行配置操作。依照《中通-全链路压测上线打算模板.xlsx》编写上线打算，并招集相干人员(运维，DBA，开发，测试，我的项目PM)评审，提前约定灰度上线，全量上线，试跑压测用例，正式压测的相干工夫节点。灰度验证将agent安装包上传到相干利用的其中一台机器上，如果有预发机，最好是上传到预发机器，而后由开发在公布平台中批改jvm配置，配置好agent相干的参数，重新启动灰度机器，察看12小时以上日志，是否失常。 全量上线与试跑如果灰度没有问题，则告诉运维，将agent装置在利用的所有机器，全量重启指标机器。如果一切正常，则能够应用压测脚本进行线上试跑了，试跑计划应在上线打算中提前布局好： 正式压测 压测场景配置注：压测试场景配置最好在灰度公布后，就开始进行在pradar-web操作页面的零碎流程中创立一个流程（一个入口只须要创立一次）： 在操作页面的“业务流动”中创立一个业务流动，并与下面的“零碎流程”进行关联 在“压测治理”->“压测场景”中，创立一个压测场景，在业务流动中，将上一步中创立的业务流动减少进去，能够减少多个业务流动，以表明同时压测多个流动的场景，如果有数据文件且数据不能够重复使用的状况，能够抉择多个IP后，对此csv数据文件勾选“拆分”操作，最初还须要关注的是正式压测，须要应用“阶梯递增”模式，则您的Jmeter脚本中须要以"bzm-Concurrency Thread Group"形式创立线程组。 压测执行确认了压测工夫与相干人员后，编写压测打算，并告诉到相干人员按计划执行，同时要特地留神压测入口域名是否受到CDN与防火墙的流量限度，如果有，须要提前找运维与网络的撑持人员将压力机IP退出白名单。所有准备就绪，则按计划执行压测即可，在“压测场景”中点“启动”，正式发动压测。 压测后果以某场景为例失去如下压测报告： 漏数检测除了个别性能测试都要进行的监控以外，进行全链路线上压测试时，最大的区别是咱们大量应用了影子数据库表，影子数据库表用于与正式数据库表进行测试数据的隔离，且压测数据咱们都会加上辨认标识，比方PT结尾的订单号都是压测数据，但因为各种起因，大量的压测数据可能会导致部份或者全副压测数据被谬误的写入了正式数据库表，从而净化了实在环境的数据，导致各种生产故障，因而有必要实时的检测是否有测试数据被谬误的写入了正式数据库表，以便及时的进行压测行为，并疾速对进入正式库的谬误数据进行荡涤纠正，将损失降到最低。为此，咱们本人基于对数据库binlog的监听，设计了一套能实时监控压测数据对生产数据造成影响的工具，原理图如下： 全链路压测实际的思考应用压测探针形式进行线上压测以来，咱们曾经在订单，运单，面单等多个业务共62个利用中进行了接入，胜利反对了双11&618大促与淘宝&拼多多等大流量联结线上压测的场景，尽管初步能解决原来压测中存在的问题，但也引入了一些新的问题。 组织与工作模式问题先看看某大厂BU进行全链路线上压测的简化版组织及工作模式架构图： 中通全链路线上压测组织与工作模式图： 全链路压测系统接入简直牵扯到整个产研团队的各个方面，须要开发、测试、运维及供应商等团队充沛配合协同工作。图一中某大厂因为订单全链路压测属于公司级重点项目，由上至下的推动相干零碎革新和对立协调资源，各我的项目由开发负责人挂帅，开发、测试、运维相互配合，性能团队属于撑持团队，负责压测计划评审、工具反对、压测问题记录与答疑。图二中咱们的模式，全链路压测属于部门级我的项目，由性能测试团队负责主导，对接各方推动接入工作，其余相干方属于配合工作人员，性能测试团队须要协调各方资源，工作难度较高。 其它问题手工操作过多，自动化水平太低，比方探针的版本控制与部署，施压机的主动创立与调配等。流程推动线下化，没有造成对立治理的配置项、查看项、评审等流程在线化推动。测试脚本与测试数据在线化对立治理及可复用水平底。根本靠压测人员自行保护。压测所积攒的后果数据，无奈在线造成压测基线自动化比照，无奈达成压测后果在工夫线上的可视化统计与剖析。 最初中通通过引入全链路压测，确实解决了原来压测环境等比缩放压测的失真问题，然而，在面对整个在订单，运单，面单等多个业务共62个利用的压测，单从上下游数据层面交互就是一项简单的工作，另外还须要各个环节的人员合作等、工作量及复杂度是可想而知的。因而，此项工程并非一天两天能全副解决的，路漫漫其修远兮，前面咱们还将通过发动性能专项翻新流动，将公司性能测试总体价值推向更高阶的档次。

什么是 Takin？Takin 是基于 Java 的开源零碎，能够在无业务代码侵入的状况下，嵌入到各个应用程序节点，实现生产环境的全链路性能测试，实用于简单的微服务架构零碎。 Takin 外围原理图 Takin 有什么特点？Takin 具备以下 4 个特点： （1）业务代码 0 侵入：在接入、采集和实现逻辑管制时，不须要批改任何业务代码；（2）链路治理：可能帮忙业务和微服务架构剖析业务链路，以技术形式取得性能视角的链路信息；（3）性能瓶颈定位：性能测试后果能够间接展示整个链路中存在性能瓶颈的微服务架构节点；（4）数据隔离：能够在不净化生产环境数据和日志的状况下施行性能测试，能够在生产环境对写类型接口进行间接的性能测试。 Takin 与传统性能测试的区别微服务架构在古代零碎架构中已被广泛应用，业务复杂性和零碎复杂性双重作用使得保障和维持整个零碎的高可用性变得艰难异样，同时对研发效率也有较大负面影响。为了解决性能瓶颈保证系统的高可用，须要对系统实施性能测试，但传统的性能测试有仿真性、局部性和黑盒性三大问题。仿真性：传统的性能测试通常在测试环境或者性能环境施行，但这些环境都只是对生产环境的仿真，无奈真正代表生产环境。局部性：传统性能测试有时会在生产环境的繁多部分服务施行，或者只压测读类型的接口，但部分高可用不代表整体链路的高可用。黑盒性：传统的性能测试只能取得 TPS 等性能后果，无奈在简单的微服务架构零碎中定位和剖析存在性能瓶颈的服务节点。 Takin 界面在生产环境进行性能压测是公认的最优解决方案，但这也是一件极具挑战性的事件，容易净化现网的数据库、日志等数据，进行生产环境测试数据清理时操作简单且危险性高，为此，生产环境全链路压测技术应运而生。Takin 作为首款生产环境全链路压测开源产品，能够较大水平地帮忙企业降低生产全链路压测平台的开发复杂度，在无业务代码侵入的状况下，取得链路治理、数据隔离、性能瓶颈定位等生产压测外围能力。 Takin 的开源模块Takin 开源内容次要包含三个局部：Agent 探针、管制中台以及大数据模块。在 Java 应用程序中植入探针（agent），它能收集性能数据、管制测试流量的流向，将数据上报给大数据模块，大数据模块会进行一些实时计算并对数据进行存储，控制台则负责这些业务流程的治理和展示。三个局部各司其职，为业务提供无代码侵入的、常态化的生产环境全链路压测服务。 GitHub 开源地址如下： https://github.com/shulieTech... 开源社区：https://news.shulie.io 有问题随时找小树

简介： 在阿里淘宝双11 的过程中，长期以来都是在生产环节做全链路压测的，通过实际咱们发现在生产环境中做压测，实际上会和一个 IT 组织的构造、成熟度、流程等严密相干，所以咱们把全链路压测从简略的制作范畴内脱离进去，变成整个业务连续性的计划。 在阿里淘宝双11 的过程中，长期以来都是在生产环节做全链路压测的，通过实际咱们发现在生产环境中做压测，实际上会和一个 IT 组织的构造、成熟度、流程等严密相干，所以咱们把全链路压测从简略的制作范畴内脱离进去，变成整个业务连续性的计划。本文分四个方面为大家论述：第一，整个全链路压测的意义，为什么要在生产环节上做全链路压测；第二，对于落地的技术点和解决方案；第三，生产过程中做全链路压测流程上的倡议，思考到每个组织的承受度不一样，给大家提供一些倡议；第四，如何在第三方实现整个在生产环境中做业务连续性包含压测的后果。 全链路压测的意义 上图显示了三个问题，实际上是不同的 IT 组织在和测试交换的时候，这三个问题是比拟有代表性的。 很多测试同行说他们线下也做过性能测试，然而到了线上之后还是存在很多问题，因为不太可能会在线下模仿一个跟线上 1：1 的环境。在有很多第三方接口的状况下，大家也很少会去模仿线上整个场景。因而咱们在线下做了很多测试工作后，总结出了为什么很多从线下容量推导到线上容量的公司却最终成果不是很好，就是这样的起因。 当初所有的 IT 组织都在搞 DevOps，咱们的性能从一个月迭代一次到当初一周迭代一次，留给测试的工夫越来越短。功能测试工夫从之前的一周、两周缩短到当初三四天、两三天的工夫，那性能测试就没有方法按时上线，很有可能会呈现各种各样的性能问题，这会间接影响到企业的品牌影响力。 平时线上水位比拟低，很少达到高峰期，然而会呈现一些突发状况。比方像去年的疫情使得很多公司的业务变成在线业务。比方教育行业，之前是课堂上老师面对面的教育，当初抉择线上在线平台来做，这类突发的状况会使测试工程师，包含开发运维团队受到很大的困扰。在这之前我先介绍一个概念，这个概念是由《黑天鹅》的原作者 Nassim Nicholas Taleb 提出，概念核心是软弱与反软弱。 什么是软弱？软弱就像玻璃，大家晓得玻璃很脆易碎。软弱的反义词是什么？不是强韧也不是坚韧，可能是反软弱。什么是反软弱呢？比方乒乓球，大家晓得乒乓球在地上不必很大的力就能够毁坏掉，踩一脚就毁坏掉了，然而高速静止的状况下，乒乓球咱们施加的力度越大，它的反弹力度越大，阐明乒乓球在静止过程中有反软弱的个性。咱们的 IT 零碎实际上也是这样的。不论什么代码都不能保障是齐全没有问题的，咱们的基础设施可能也是软弱的，像服务器、数据库等总会有局限。咱们的框架也总是软弱的，将这些问题综合在一起，咱们心愿通过某些伎俩，比方通过预案、危险的辨认，或者通过一些熔断的伎俩，最终把这些货色组合在一起，让整个 IT 零碎有反软弱的个性。总之，咱们心愿通过一些伎俩使得 IT 零碎有足够的冗余，而且有足够多的预案应答突发的不确定性危险。 如何打造 IT 零碎反软弱能力呢？咱们心愿通过一些伎俩，比如说像线上的压测能力，提供不确定的因素，接着通过在这个过程中实时监控，包含预案的能力，最终把这些不确定性的因素辨认进去，并且在线上生产压测过程中对它做一些解决，更多可能会通过预先复盘等形式，做到对不确定性因素的辨认。接着咱们可能会在生产环境中通过之前的伎俩，在生产环境上做一个稳定性的常态化压测，实现长期稳固的场景，最终咱们可能达到反软弱能力所须要的整体监控的能力、经营防护能力，以及管控路由能力，这会让整个 IT 零碎具备反软弱的个性。 全链路压测解决方案如何在生产环境上做全链路压测？它须要用到哪些技术手段？ 压测过程演变 个别状况下，测试是怎么样从线下一点点往线上演变的？我把它分为四个阶段： 目前绝大多数 IT 能够做到的是线下单零碎压测，即针对单个接口或者单个场景做压测，同时也会做系统分析和性能剖析。但在简单的业务场景之下，咱们可能没方法去充沛发现问题，很多都是由开发或者测试同学自发进行的流动。 咱们成立了一个相似于测试实验室或者测试组织的机构，这样一个大的部门可能会结构出一批相似于生产环境的性能测试环境，在这下面咱们可能会做更多的事件，比如说做一个线下环境的全链路压测，并且咱们能够依据之前积攒的教训在下面做一些线下的回归，包含性能的诊断等。其实这一步相当于整个测试往前再走一步，对测试环境中的链路做一些剖析，在下面演变一些能力，比如说危险的管制等等。 目前绝大部分 IT 企业和互联网企业违心尝试线上生产环境的业务压测。这部分实际上和之前的第二阶段相差不多，然而在这个过程中人为的把它分为了两层：第一层是单纯的做全链路压测，很多 IT 公司曾经在非生产环节中做了只读业务的压测，因为这样不会对数据造成净化。而再往下一层 ，有些组织可能会在失常生产时段中做进一步的全链路压测，这种状况下咱们就会要求这个组织领有更高的能力。比如说咱们须要对整个压测流量做一些染色，可能辨别进去失常的业务数据，失常的流量和非正常的压测流量，可能有的会做一些环境的隔离，而在业务生产期间内咱们做生产的压测，须要思考到整个流量的偏移、限流，包含熔断机制等。不管怎样做业务，可能都会对最终的生产业务造成肯定的影响，真正呈现问题的时候可能须要有疾速的熔断机制。 做到压缩熔断渲染，包含对熔断的机制——有了这样的能力之后，最初一个阶段就是整个生产链路的全链路压测，包含读写，它就具备了根本能力。这个方面咱们其实更多的是通过引入库表，加上技术手段，在这个生产上做全链路压测，包含读业务、写业务等，同时咱们有系统故障演练和生产变更演练的能力，在这种状况下咱们可能最终具备了数据隔离能力、监控隔离能力和日志隔离能力。 全链路压测关键技术 对于整个全链路压测来说，咱们须要几个要害的技术： 全链路流量染色 可能通过在压缩机上做一些标识，比方加一个后缀，或者通过一些标识伎俩把流量读出来，扩散到相干的表里去。同时在全链路流量展现过程中咱们还须要做流量的辨认，对于压测流量通过的每一个中间件，每一个服务咱们都心愿可能精确的辨认进去，这个流量是来自于压测机还是来自于失常流量，这是第一步。 全链路的数据隔离 咱们须要通过哪些伎俩，比方通过影子库，通过运维的同学做一个和生产下面同样的影子库，而后切到影子库上，或者在生产库上做一个雷同的影子表，来做数据隔离。第一种形式平安度高一些，然而毛病在于咱们用影子库的时候整个生产环境是不可用的。生产影子库不能齐全模拟出整个线上的状况，因为影子表须要咱们有更高的技术水平，可能保障整个链路可追踪，包含整个数据如果一旦出错数据恢复能力等等。 全链路危险管控机制 也就是危险熔断机制，一旦真的发现生产环境的线上压测对咱们的业务造成了影响，咱们须要通过一些规定或者其余的指标来主动触发危险熔断，包含管控等等这样的伎俩，不论是提供施压机的流量，还是把生产零碎损坏的局部做业务隔离，这样的伎俩都是咱们做生产过程中全链路压测的必要伎俩。 全链路日志日志隔离 其实日志自身不会对全链路造成太大的影响，然而因为做数字化程度的晋升，日志基本上是BI同学包含经营的同学对整个业务剖析最重要的数据起源，如果咱们不做日志隔离很有可能会对 BI 决策造成肯定的影响，比方压测过程中咱们会大量采纳某个地区的流量对生产环境做拜访，BI 的同学可能会通过日志剖析发现某一个地区做大，导致他谬误的经营决策，所以说对于生产过程中的全链路压测来说，咱们须要在整个生产过程中做肯定的日志隔离，辨别进去失常的生产流量和压测流量之间的存储。 全链路压测和业务连续性平台外围性能 这部分是真正想作为全链路压测和业务连续性平台所须要的性能。 首先是有来自于全地区的压测流量工具，这个流量工具具备的性能包含全地区流量开掘、流量革新相干的性能。整个压测辨认，包含影子存储一部分的性能。黄色的局部是失常流量，蓝色的局部是压测的流量，咱们可能通过施压机的革新让蓝色的局部退出一些标识，通过 Agent 的技术，它能够标识出带有的流量，通过底层的 Agent 技术将这些落到相应的影子库或者影子表里去，或者是缓存的影子区里。做熔断的规定治理，所以须要有正当的控制台，这里可能会做一些装置探针治理，包含整个架构的治理、库表的保护、规定的保护、熔断机制的保护等。最初是真正的施压局部。这里可能会装置一些探针或者是 Agent，这些 Agent 的作用是可能让这些流量落到相应的影子表里去，还有是通过相应的监控指标，比如说咱们的谬误达到 1%，或者是查看工夫超过了肯定的阈值之后，Agent 会及时上报，通过规定配置起到限流的作用。通过这套架构，咱们当初能够做到目前比依照整体环境大概节省成本是 40%左右，基本上对整个生产业务没有任何切入。全链路压测危险防控能力 ...

往年618，你是尾款人还是加班人？ 肯定又偷偷剁手了很多好货色！ 买买买的高兴都集中在拆快递的时刻，所以网购最难熬的就是期待，等发货等物流等配送。每年的618、双11大促除了各大电商平台忙的不可开交，物流行业的繁忙值也是拉满的。 2019年618期间全行业共揽收快件31.9亿件，同比增长26.6%，最高日处理量超过2.43亿件，同比增长54.8%，比日常处理量高出27.9%；2020年618期间全国快递业务量就已达到46.78亿件，同比增长48.66%。在如此宏大的业务量背后，大促快递仍旧可能做到配送快准稳，除了要感激冲在一线的快递小哥，稳固的物流零碎功不可没。 一旦物流零碎瘫痪，大促就调演变成一场劫难，商品揽收发货、直达、派送、签收都会呈现问题，所以保障物流零碎的稳固高可用也是大促流动中十分重要的一环！简直所有的物流公司在618、双11、双12等大促流动前都会打起百分百的精力来应答这场硬仗，即便如此还是不能保障十拿九稳。 在跟客户的交换过程中，咱们理解到一些物流人背地的心酸故事，出于信息爱护，以下咱们简称该物流公司为B。 B公司业务产品线简约，领有订单、开单、直达、派送、签收、收件、揽收，综合查问八大外围零碎，服务网络覆盖全国34个省级行政区，领有近10000家网点，整个物流零碎盘根错节。 2018年该公司的零碎异样次数不可胜数，重大零碎事变更是频频产生，足有10次之多，事变影响总时长达1106min，最长一次影响了440min。 大促期间胆战心惊，3天2次重大零碎事变大促间所有人胆战心惊，只管24小时处于待命状态，3天还是呈现了2次重大零碎事变。过后一个定时工作呈现了问题，导致外围零碎订单核心挂了3小时，直达挂了8小时！大促首日中转场和分拨核心除了正式员工还组织了两倍的临时工人力，可零碎问题导致全员停摆，在争分夺秒的大促包裹派送大战中处于下风。客户各种投诉口碑载道，造成了不小的影响和损失。下面订单事变产生仅2天，直达零碎又呈现了问题，间接被菜鸟进行派单3小时。测试负责人才刚躺下就被叫回公司，一堆研发在一起查问题改bug。老板对于这块也是十分关怀，每过5分钟就询问一次停顿，直到次日凌晨4:00还没修复好。以原有订单量计算，假如一单一块钱，间接经济损失也远超百万元。 外部恩怨录：业务炸毛扬言要弄死开发同年某次订单零碎版本上线失败，导致测试环境造出来虚伪订单跑到正式库外面，但业务并不知情，还持续主动散发订单。上层营业部看到订单暴增10000多单，非常高兴，安顿了很多快递员去客户那边接货。可当快递员达到取货地址之后发现竟是个乌龙，基本就没货可接！快递员回去之后又被派单，去接货发现又没货，如此周而复始一天白跑十几次。这种状况换谁都怄气，于是业务端的投诉电话被打爆了。矛盾激化，最初业务间接炸毛，扬言要弄死开发。 菜鸟指数上涨2个点，影响无法估量菜鸟指数是菜鸟针对物流商各项服务相干指标进行综合评估的指标体系，该评估后果将间接影响快递公司的服务排名、商家端快递公司展现排序、商家端服务举荐等环节。某次开发写的一个数据脚本有问题，后续做了局部批改，等到参数化的时候有个不能反复发送的数据反复发了，呈现零碎异样被菜鸟监测到，菜鸟指数直线上涨2个点，好在没有跌破合格线，不然就得间接跟老板汇报情况了，但这个失误造成的损失也是无法估量的。 对于物流公司而言，这些零碎事变是致命的，用户体验得不到保障，客服部将直面微小的压力，并且会间接影响支出起源。换言之，保障系统稳固0性能故障就是在防止危险、预防损失，那该如何保障系统稳定性呢？ 通过调研B公司决定引入生产环境全链路压测技术，在新技术的加持下，从2018年重大零碎事变10次，影响总时长1106min到2019年159个业务场景0性能故障，实现物流零碎高可用的状况下，每年还能节俭361万的机器老本、近百万的人力投入。 测试负责人私底下还跟咱们走漏：“2018年出了太多故障，大促期间每天情绪都像在坐过山车，接入ForceCop全链路压测这套货色后心里有底多了，零碎安稳度过了2019年大促，老板很称心，底下的开发和测试也是成就感满满。” 目前物流行业排名前6 的企业已全副接入数列科技旗下的生产环境全链路压测产品，据不齐全统计，每10个快递包裹中就有8个是在数列产品的保驾护航中送到全国各地的用户手中的。 此外ForceCop已在50多家中大型企业落地，中国移动、国家电网、浙江大学、永辉超市等其余行业龙头企业也相继接入数列产品，2000+利用接入，100+大促测验， ForceCop凭借突出扎实的技术实力播种了客户统一的正向反馈。 ForceCop产品目前全面凋谢试用，欢送大家来体验，感兴趣的能够增加【小树】微信私聊申请试用哦～

本文介绍压测是什么，解释压测的专属名词，教大家如何压测。介绍市面上的常见压测工具(ab、locust、Jmeter、go实现的压测工具、云压测)，对比这些压测工具，教大家如何选择一款适合自己的压测工具，本文还有两个压测实战项目： 单台机器对HTTP短连接 QPS 1W+ 的压测实战单台机器100W长连接的压测实战目录1、项目说明 1.1 go-stress-testing1.2 项目体验2、压测 2.1 压测是什么2.2 为什么要压测2.3 压测名词解释 2.3.1 压测类型解释2.3.2 压测名词解释2.3.3 机器性能指标解释2.3.4 访问指标解释3.4 如何计算压测指标3、常见的压测工具 3.1 ab3.2 locust3.3 Jmeter3.4 云压测 3.4.1 云压测介绍3.4.2 阿里云 性能测试 PTS3.4.3 腾讯云 压测大师 LM4、go-stress-testing go语言实现的压测工具 4.1 介绍4.2 用法4.3 实现4.4 go-stress-testing 对 Golang web 压测5、压测工具的比较 5.1 比较5.2 如何选择压测工具6、单台机器100w连接压测实战 6.1 说明6.2 内核优化6.3 客户端配置6.4 准备6.5 压测数据7、总结8、参考文献1、项目说明1.1 go-stress-testinggo 实现的压测工具，每个用户用一个协程的方式模拟，最大限度的利用CPU资源 1.2 项目体验可以在 mac/linux/windows 不同平台下执行的命令参数说明: -c 表示并发数 -n 每个并发执行请求的次数，总请求的次数 = 并发数 * 每个并发执行请求的次数 -u 需要压测的地址 ...

pre-tips本文翻译自: Keeping Node.js Fast: Tools, Techniques, And Tips For Making High-Performance Node.js Servers 原文地址：https://www.smashingmagazine.... 中文标题：保持Node.js的速度-创建高性能Node.js Servers的工具、技术和提示 快速摘要Node 是一个非常多彩的平台，而创建network服务就是其非常重要的能力之一。在本文我们将关注最主流的: HTTP Web servers. 引子如果你已经使用Node.js足够长的时间，那么毫无疑问你会碰到比较痛苦的速度问题。JavaScript是一种事件驱动的、异步的语言。这很明显使得对性能的推理变得棘手。Node.js的迅速普及使得我们必须寻找适合这种server-side javacscript的工具、技术。 当我们碰到性能问题，在浏览器端的经验将无法适用于服务器端。所以我们如何确保一个Node.js代码是快速的且能达到我们的要求呢？让我们来动手看一些实例 工具我们需要一个工具来压测我们的server从而测量性能。比如，我们使用 autocannon npm install -g autocannon // 或使用淘宝源cnpm, 腾讯源tnpm其他的Http benchmarking tools 包括 Apache Bench(ab) 和 wrk2, 但AutoCannon是用Node写的，对前端来说会更加方便并易于安装，它可以非常方便的安装在 Windows、Linux 和Mac OS X. 当我们安装了基准性能测试工具，我们需要用一些方法去诊断我们的程序。一个很不错的诊断性能问题的工具便是 Node Clinic 。它也可以用npm安装: npm install -g clinic这实际上会安装一系列套件，我们将使用 Clinic Doctor和 Clinic Flame (一个 ox 的封装) 译者注: ox是一个自动剖析cpu并生成node进程火焰图的工具; 而clinic Flame就是基于ox的封装。另一方面， clinic工具本身其实是一系列套件的组合，它不同的子命令分别会调用到不同的子模块，例如:医生诊断功能。The doctor functionality is provided by Clinic.js Doctor.气泡诊断功能。The bubbleprof functionality is provided by Clinic.js Bubbleprof.火焰图功能。 The flame functionality is provided by Clinic.js Flame.)tips: 对于本文实例，需要 Node 8.11.2 或更高版本 ...

概述这是关于 Swoole 入门学习的第十篇文章：压测 swoole_websocket_server 性能。 第九篇：Swoole Redis 连接池的实现第八篇：Swoole MySQL 的实现第七篇：Swoole RPC 的实现第六篇：Swoole 整合成一个小框架第五篇：Swoole 多协议 多端口 的应用第四篇：Swoole HTTP 的应用第三篇：Swoole WebSocket 的应用第二篇：Swoole Task 的应用第一篇：Swoole Timer 的应用收到读者提问 “使用 Swoole 开发的群聊功能，想知道并发情况，也就是想压测下 QPS，一直未找到方法 ...” 对 swoole_http_server 压测，咱们可以使用 Apache 的 ab 命令。 对 swoole_websocket_server 压测，使用 ab 命令是不能压测的，我从网上一直也没找到合适的方法，看官方提供的代码 benchmark/async.php 中，使用的异步模块 swoole\http\client 方法进行压测的，但在 Swoole 4.3 版本就移除了异步模块，让使用 Coroutine 协程模块。 在本地我用 Coroutine 协程实现了一下， 测的差不多的时候，一直不确定是否正确，就在 segmentfault 发了个提问，没想到韩老师回答了，'如果的如果'老师也回答了，非常感谢两位老师的答案，然后整理出文章分享给大家。 测试机Mac 上安装的 Parallels Desktop 虚拟机 系统：Ubuntu 16.04.3 LTS 内存： ...

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/vie…WeTest 导读在小程序持续大量爆发的形势下，现在已经成为了各平台竞争的战略布局重点。至今年2月，月活超500万的微信小程序已经达到237个，其中个人开发占比高达2成。因小程序的开发门槛低、传播快、收益高，越来越多的开发者投入了小程序这一领域，由于整体开发水平层次不齐，会碰到越来越多的小程序质量问题。特别是面对电商、零售、旅游、直播等容易有高并发量的行业，会出现“服务器崩溃”、“访问响应缓慢”、“页面操作卡死”、“支付提交失败”等性能问题。那么，应该如何做小程序服务器压测呢？接下来，我们将以电商行业为例，为您介绍如何使用WeTest的压测大师来做微信小程序的压测。首先新建一个测试用例，添加客户端请求，然后根据自身业务需求设计测试模型，最后对微信小程序发起压测。一、场景的需求分析某电商类微信小程序需要压测商品详情和加入购物车页面，根据业务逻辑，首先进入商品详情页，再将商品加入购物车。1、进入商品详情页 1）通过商品id，可以打开不同商品详情页2、加入购物车 1）选择不同商品详情页，将不同商品加入购物车中测试模型如下：二、场景配置的操作步骤接下来为了实现前面的测试需求，我们来介绍下具体步骤：1、登录WeTest平台（wetest.qq.com），在导航栏选择产品>性能测试>服务器性能>进入项目>创建项目(注:创建团队项目可与团队成员共同管理和完成项目)2、在项目首页点击创建测试按钮，选择URL测试来创建用例，示例如下：3、 在客户端请求栏，填写URL地址、选择请求方法。示例如下：压测URL地址：https://top.domain.com/goods/…请求方法：POST说明：该示例中，使用的域名“top.domain.com”，为示例地址，您可以根据真实业务场景填写压测URL。4、在客户端请求栏，填写Header、Body请求参数。1）选择Header页签，填写商品详情接口请求header信息。 2）选择Body页签，填写商品详情接口请求body信息，Header中Content-Typ字段为application/json，故Body是 JSON格式，body上传方法选择raw。5、单击 添加客户端请求 ，填写第二个客户端请求信息。6、为判断“商品加入购物车”是否成功，可设置检查点,选择检查点页签，填写检点信息。1）变量名：填写自定义的变量名称；2）来源：根据变量的返回路径选择Response Header或Response Body，这里我们选择Response Body；3）提取方式：可根据需要自主选择变量的提取方式，这里我们选择 JSON；4）Header名称：当来源为Response Header时需要填写相应的header名称；5）检查规则：根据选择的提取方式填写对应的规则；6）预期值：填写预期服务器返回值；示例如下：商品加入购物车接口成功的返回信息为：{“code”:“100”,“message”:"",“result”:{#加入购物车的对应商品信息},“ver”:“1”}，来自Response Body，这里我们自定义变量名为code，提取方式选择 JSON，检查规则为[“code”]，预期值为100设置检查点。如图所示：三、场景调试操作步骤1、 定义场景名1）自定义一个场景的名称，平台默认场景名为：默认场景1/2/3……2、上下文/单场景模式选择1）单场景是单独执行这一条URL，设置多个单场景时，多条URL将会并行执行；2）上下文是构建链路性场景，从A到B顺序执行，B的某个值从A的返回内容中提取等。3、设置压力百分比1）设置该场景的压力百分比，当测试模型中有多个场景时,可根据自身业务比例进行分配压力百分比4、点击“调试”按钮进行调试。一般调试时间在5秒至20秒。1）调试结束后，可查看客户端请求的调试详情。四、压力设置步骤场景调试完成后，需要设置并发人数和场景配置等。1、填写并发设置，如图所示：1）起始人数：初始并发10；2）每阶段增加人数：每阶段增加并发为0；3）每阶段持续时间：代表压测时长为1分钟；4）最大人数：最大人数需要大于或等于初始并发；5）发包间隔时间：每次请求收到回包后等待0s，再次发送请求6）超出时间：事务响应时间超过10000ms，记为超时请求7）发包模式：客户端建链后不切换端口，始终在长链接上不断发包2、报告标准阈值设置可以根据项目需求设置阈值，如成功率、响应时间和TPS，最终压测数据与阈值进行比对，若满足条件即测试通过。五、启动压测单击立即执行，即可发起压测（腾讯云用户需在VUM消费确认栏点击确认）WeTest平台针对于服务器性能测试中常出现的技术门槛、配置冗杂、成本高昂等开发者亟待解决的问题，推出“压测大师”服务，包含了“服务器自助压测服务”与“深度性能测试服务”两大功能模块，通过专业级别测试与健全修正方案，协助开发者逐一击破切实难关。点击传送门获取更多压测信息：传送门：https://wetest.qq.com/product…

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/448.html2019年，中国移动软件市场仍呈现快速增长趋势，移动新生态孕育而生。而移动软件质量问题越发受到用户的关注，成为用户体验的关键因素。目前移动软件测试人才稀缺，而性能测试作为一项高门槛、高技术的测试能力，在行业中更为紧缺。腾讯官方的一站式品质开放平台「腾讯WeTest」携手知名测试社区「TesterHome」，将腾讯沉淀十余年的品质管理经验凝聚而成，通过WorkShop专项培训的方式输出，助力孵化更多行业人才，打造移动测试大环境。此次的专项培训我们将针对应用软件来分享性能测试的方法，通过基础篇、工具篇、案例篇、提升篇这四大模块全方面讲解压测的基础知识、工具使用和案例分析，零基础做压测！活动时间2019年4月14日 13点至17点活动地点上海市，浦东新区，南泉北路528号新大陆广场北楼2层中信书店(新大陆广场店)活动内容本次活动适合压测零基础或有其他测试经验但还想学习压测的同学，WorkShop属于技术性的实践活动，各位报名的同学可以提前了解下压测。报名链接请点击“传送门”转跳报名页面1、本次培训为免费形式，为保证教学质量，限制30人；2、为确保学习秩序，通过审核的同学会先收取30元，培训当天现场退还，所以报名前请务必确认是否有时间参与；3、为确保报名审核的顺利通过，请务必认真填写个人信息；传送门：https://www.bagevent.com/event/2504253学习目标既然是来学习，那就定一个小小的目标1、对压测有个初步的认识2、能使用工具3、可以跟着学习案例4、重点是享受到实践压测技术的乐趣事前准备请务必自带笔记本电脑，除需要携带设备外，考虑到现场的网络情况，所以需要大家提前下载课程资料并安装（安装有问题可以现场解决，软件提前下载），还是希望大家能够借助互联网完成准备工作1、Windows7+或者mac笔记本，配置建议cpu：i5及以上，内存：4G及以上；2、登录WeTest官网（wetest.qq.com）提前注册账号，需要通过平台使用工具；3、提前下载好压测课程资料，安装fiddler资源包；写在最后WorkShop不是沙龙，不是演讲，不会特别拘谨和严肃，希望是可以随和的通过互动带给学员们更多务实和技术性的东西。也请学员们互相尊重，适度玩笑。

作者：WeTest小编商业转载请联系腾讯WeTest获得授权，非商业转载请注明出处。原文链接：https://wetest.qq.com/lab/view/442.htmlWeTest压测大师 - 新春元宵特惠礼**点击：https://wetest.qq.com/appoint/gapspro获取价值5888元的压测大师专家代金券（新用户需先注册）**活动细则：提交信息后，即可获得代金券代金券有效期为90天代金券使用规则请咨询企业客服QQ：2852350013不与其他优惠活动同时使用_WeTest 导读国内的电子商务经历了整个产业多年发展，依然在快速的增长，交易额仍在不断的递增，电子商务行业已经初步形成了功能完善的业态体系。与此同时，电子商务的不断普及直接带动了物流、金融和IT等服务类的行业发展，与之配套的第三方支付、电子认证、网络信息安全、网络保险、质量服务等电商生态圈中各子业态也在飞速的发展。在有庞大的客户体量下，电商的激烈竞争引出了对于服务需要高质量。在每次的节日活动中，服务器承受的压力往往是个重大的考验，于是服务器压测成为了一个必不可少的试金石。电商核心诉求场景 — “商品浏览选购顺畅”“结账下单支付成功”及“节日活动顺利成功”作为电子商务的购物，我们往往关注频率最高的几个场景是：秒杀、闪购活动时选购——结账无法操作，收入损失惨重节庆活动参加人数过多——服务器宕机、网站小程序APP瘫痪用户量一旦增加——页面响应越来越缓慢，不能正常浏览商品无法登录、无法支付及应用宕机可以发现在网站服务器业务上的场景主要的需求是：稳定使用和高并发使用。WeTest的压测大师专家打造一体式电商全链路测试服务一、专家深度打造压测的方案WeTest专家根据每个商户不同业务流程逻辑，从底层服务器架构分析，根据压测需求打造独有的测试方案。方案涵盖每个核心的业务场景，并且包含从核心场景的用例编写、执行、测试到产出报告的一体式服务。WeTest专家服务能提供的价值：评估后台性能是否能满足业务预期，比如满足双十一期间上万人同时支付探索系统能支持的最高并发量，为业务部门做活动时的推量提供决策依据分析出全链路中可能的性能瓶颈点，供开发团队优化能够通过长时间施压测试整套服务器系统的稳定性二、测试用例设计WeTest根据客户使用行为来进行用例的编写，从提供的服务器架构和时序图来分析后台交互的协议，同时根据实际用户行为，评估出并发量，进行用例编写测试。**单模块性能测试（如支付、登录、购物车）全链路测试（例：首页→品类页→商品详情页→加购物车→选择配送→…→提交订单→选择支付类型 →支付完成）**部分场景测试过程展示：提交购物车订单的成功率和响应时间提交购物车订单的CPU和内存的使用情况：三、在高并发下定位功能bug在高并发的服务器压力下，往往会容易出现概率性的功能bug。偶发性的bug形成的原因会极其复杂，可是有些bug造成的后果会很严重，虽然一般很少会遇到，但对于收集验证这些问题的开发来说，会碰到定位重现缺陷是件很困难的情况。WeTest专家在进行服务器压测的同时，会关注整体业务逻辑的功能是否会正常。例如账户多次切换数据错乱、购物车购买数据丢失等等。四、报告展示通过WeTest服务器性能测试报告，可以迅速了解到每个测试场景对应的测试过程，同时定位问题，分析瓶颈点。以下是部分报告里的内容展示：资深专家服务，规范化流程，腾讯标准保障以腾讯WeTest在十余年的产品压测经验为依托，目前推出资深专家服务，已应用于腾讯旗下各个行业的应用， “智慧零售”“企业微信”，“微信读书”，“QQ会员”“摩拜单车”，“NOW直播”等均使用压测大师专家服务，覆盖了电商、社交、交通出行、直播视频、新闻阅读等各行业应用，承载千万级用户产品的压测考验。现正值新春元宵佳节，压测大师隆重推出优惠活动：领取5888代金券，来体验专家模式一体式全流程的服务，保障电商全链路的通畅和稳定。最后，WeTest全体员工祝愿所有技术开发者们元宵快乐，阖家幸福~

背景境内度假是一个低频、与节假日典型相关的业务，流量在节假日较平日会上涨五到十几倍，会给生产系统带来非常大的风险。因此，在2018年春节前，我们把整个境内度假业务接入了全链路压测，来系统性地评估容量和发现隐患，最终确保了春节期间系统的稳定。在整个过程中，我们意识到，全链路压测在整个系统稳定性建设中占有核心重要的位置，也是最有效的方案。结合实际业务节假日的频率（基本平均一个月一次），如果能够把它作为稳定性保障的常规手段，我们的系统质量也能够得到很好的保障。同时，为了解决周期常态化压测过程中人力成本高、多个团队重复工作、压测安全不可控，风险高等痛点，我们提出了全链路压测自动化的设想。通过对压测实施的具体动作做统一的梳理，在压测各个阶段推进标准化和自动化，尽力提升全流程的执行效率，最终达到常态化的目标，如图1所示：另外，在全链路压测的整个周期中，压测安全和压测有效性也是需要一直关注的质量属性。基于这些思考，如图2所示，我们把压测自动化需要解决的关键问题进行了归类和分解：基础流程如何自动化，提高人效；如何自动做好压测验证，保障压测安全；压测置信度量化如何计算，保证压测有效。最终，基于美团基础的压测平台（Quake在整个系统，主要提供流量录制、回放、施压的功能），设计并实现了全链路自动化压测系统，为不同业务实施全链路压测提效，并确保压测安全。该系统：提供链路梳理工具，能够自动构建压测入口链路完整的依赖信息，辅助链路梳理；支持链路标注和配置功能，对于无需压测触达的依赖接口，可以通过配置化手段，完成相关接口的Mock配置，不用在业务代码中嵌入压测判断逻辑；提供抽象的数据构造接口，通过平台，用户可以配置任意的数据构造逻辑和流程；在压测前/压测中，自动对压测服务和流量做多项校验，保障压测安全性；在平日，基于压测计划提供周期性小流量的压测校验，使得业务迭代变更带来的压测安全风险被尽早发现；提供压测计划管理功能，通过系统自动调度和控制施压过程，解放人力；同时强制前置预压测，也提高了安全性；一键压测，自动生成报告，收集链路入口和告警信息，提供问题记录和跟进功能。系统设计系统总体设计系统的总体逻辑架构，如图3所示，主要包括链路构建/比对、事件/指标收集、链路治理、压测配置管理、压测验证检查、数据构造、压测计划管理、报告输出等功能模块。通过这些模块，为全链路压测的整个流程提供支持，尽力降低业务部门使用全链路压测的门槛和成本。链路构建/比对：负责服务接口方法调用链路的构建、更新、存储。链路治理：基于构建的链路关系，提供链路中核心依赖、出口Mock接口等标注、上下游分析、展示，以及出口Mock的配置等功能。压测配置管理：自动发现注册服务的Mafka（美团基于Kafka开发的一个分布式消息中间件综合解决方案）/Cellar（基于Tair开发的分布式KV存储服务）/Squirrel（基于Redis-Cluster模式进行二次开发的分布式缓存系统）/Zebra（美团数据库访问层中间件）的压测配置，辅助压测方核查和配置相关配置项。压测验证检查：确保系统可压测，通过多种校验手段和机制设计，来保证压测的安全性。数据构造：为不同业务压测实施准备基础和流量数据。压测计划管理：设定压测执行计划，并依赖“压测控制”模块，自动调度整个压测执行过程。故障诊断：依据收集的关键业务/服务指标、报警等信息，判断分析服务是否异常，以及是否终止压测。置信度评估：从数据覆盖、链路覆盖、技术指标等维度评估压测结果的置信度，即与真实流量情况下各评估维度的相似性。非功能性需求说明：可扩展性能够兼容不同业务线数据构造逻辑的差异性。能够支持不同的流量录制方式。安全性集成SSO，按用户所属团队分组，展示所属的压测服务信息。对关键操作留存操作日志。压测验证检查，是确保压测安全的关键。支持周期性压测验证，能发现待压测服务可压测性随时间的退化。可重用性长远看，链路构建、事件/指标收集/故障诊断等模块，在稳定性领域是可重用的基础设施，按独立通用模块建设。约束说明：基于Quake搭建，流量的录制、回放、施压等依赖Quake。以下对部分关键模块设计做详细介绍。链路治理模块设计链路治理模块是基于链路构建模块实现的。链路构建模块，底层是以闭包表的方式存储两个维度（服务和接口）的链路关系的，会周期自动地构建或更新。链路治理模块主要提供链路入口选取、链路标注、服务出口分析、出口Mock配置等功能。如图4所示，注册压测的服务构成了压测服务的范围，也就确定了各个链路的边界。通过系统自动构建的树结构方式的链路关系，可以辅助压测方对整个链路的梳理，它解决了以往链路梳理靠翻代码等低效手段，缺少全链路视角无法做到完备梳理等问题。同时，针对整个压测范围，依赖接口可以做人工标注。哪些需要Mock，哪些不需要Mock，如此压测特有的链路信息能够得到持续的维护。对于需要Mock的外部接口（如图4中的接口C），待压测系统通过引入专有SDK的方式，获得出口配置化Mock的能力。如图5所示，这里使用了美团酒旅Mock平台的基础能力，采用JVM-Sandbox作为AOP工具，对配置的需要Mock的外部接口做动态能力增强。在接口调用时，判断是否是压测流量，是的话走Mock逻辑，做模拟时延处理，返回提前配置的响应数据。这样的话，第一，简化了出口Mock的操作，业务代码里Mock逻辑0侵入；第二，把之前本地Mock与借助Mockserver的两种解决方案用一种方案替代，便于统一管理；第三，在实际压测时，平台还可以通过SDK收集Mock逻辑执行的数据，自动与后台标注的Mock数据对比，来确保应该被Mock的出口确实被Mock掉。数据构造模块设计数据构造模块是为了解决不同业务对于基础数据和流量数据的差异化构造流程。提出了两个关键的概念：数据构造逻辑和数据构造流程。数据构造逻辑，是数据构造的细粒度可复用的基本单元，由一段Java代码表示。平台提供统一抽象的数据构造接口，基于Java动态编译技术，开发了一个Java版的脚本引擎，支持构造逻辑的在线编辑与更新。同时，基于美团RPC中间件泛化调用能力，构建了泛化调用工具，帮助用户把外部基础数据构造接口的调用集成到一个数据构造逻辑中。数据构造流程，定义了压测基础数据和流量数据生成的整个流程。通过与Quake的交互，获取原始真实的线上数据；构建了一个简版的流程引擎，在统一设定的流程中，如图6所示，通过在标准扩展槽中，配置不同类型的数据构造逻辑和执行顺序，来定义整个数据构造执行的流程；最后，把构造的流量数据与Quake压测场景绑定，作为后续Quake压测施压中，场景回放流量的来源。通过这样的设计，能够支持任意数据构造逻辑，通用灵活。同时集成了Quake已有的流量录制功能，一键执行数据构造流程，大大地提升了效率。压测验证模块设计对于压测安全性的保障，一直是自动化的难点。之前的经验多是在非生产环境压测或预压测过程中，依靠不同服务相关负责人的人工确认。这里针对压测验证，提供两条新的思考角度：一个是从待压测服务系统可压测性的角度看；一个是从压测流量特征的角度看。对于第一个角度，一个服务支持压测需要满足压测数据和流量的隔离。对于不同的系统生态，需要满足的点是不同的，对于美团生态下的服务，可压测的条件包括组件版本支持压测、影子存储配置符合预期等等。从这些条件出发，就可以得到下面这些静态的校验项：服务依赖中间件版本要求校验；Zebra压测配置校验；Cellar/Squirrel压测配置校验；Mafka压测开关同步及校验；服务Mock逻辑存在性校验。而从第二个角度来看，就是关注压测流量下会产生哪些特有的流量特征数据，通过这些特有的数据来确保压测的安全性。这里主要有三类数据：美团分布式追踪系统（MTrace）中调用链路的压测标记数据（正常的压测链路应该是一直带有压测标记，直到压测范围的边界节点，可参考图4）；标记Mock的外部接口被调用时，上报的运行数据；基于监控系统得到的压测流量特有的监控数据。利用这些数据，我们设计了三种动态的校验项，发现压测标记丢失、Mock出口被调用等异常情况：MTrace链路标记校验，从压测链路入口出发，收集压测链路信息，校验压测标记信息传递是否符合预期。服务Mock逻辑压测标记校验，通过增强的校验逻辑，把执行信息上报到平台，与Mock配置时的标注数据对比验证。压测与真实链路比对校验，利用链路治理模块构建链路的能力，采集压测监控数据重构链路，与真实链路对比验证。除了明确静态和动态两类压测校验规则，在具体流程安排上，在压测时和平日两个时期执行这些规则。既能把压测校验的压力分散到平时，也能尽快地发现服务因代码迭代引入的新风险。在压测时，通过强制前置预压测的流程设计以及静态/动态压测校验项的自动执行，保障安全这个事情。校验不通过，给出告警，甚至在允许的情况下直接终止设定的压测计划。在平日，通过执行周期性小流量压测校验，在施压过程中对QPS做个位数的精细控制，以尽量小的代价快速发现压测范围内压测安全性的退化。压测计划管理模块设计压测计划管理模块，提供压测计划的提前设定，然后模块能够自动调度和控制整个施压过程。如图11所示，这里的压测计划是多个压测场景的组合，包含QPS的增长计划等信息，主要分为预压测和正式压测两个阶段。压测计划的自动实施，能够解决尤其多场景组合压测，操作耗时多、多场景压测QPS无法同步变更、压测方无法兼顾操作和观测等问题，提升了效率。同时，在压测计划执行状态机里，预压测正常执行完成，状态才能迁移到正式压测的开始状态，提高了压测安全性。从图11可以看到，压测计划模块，是整个自动化压测的核心，协同起了各个模块。通过具体的计划任务执行产生的事件，触发了压测验证检查、压测进展播报、收集压测监控/告警等数据，来检测服务是否异常，并根据配置来终止压测，能够故障时及时止损。最后，报告生成模块收到压测终止事件，汇总各种信息，自动生成包括压测基本信息等多维度信息的压测报告，节省了一些压测后分析的时间。案例分享以下以实际压测的过程来做个案例分享。团队/服务注册设定实施压测的虚拟团队和压测覆盖范围的应用服务。链路治理选定压测链路入口，可以得到入口以下的接口链路关系树，便于梳理。明确需要Mock的外部接口，并做配置，参考“链路治理模块设计”一节。应用改造与压测配置对待接入压测应用改造，满足“服务的可压测条件”，参考图7。压测应用依赖中间件配置，系统依据构建的链路信息，能够自动发现。提供统一配置和核对的页面功能。Quake准备压测自动化系统是基于Quake构建的，流量录制、回放、施压等依赖于此。因此需要到Quake上配置流量录制的“流量任务”和压测执行的“压测场景”。数据构造配置数据构造逻辑，当然已有的逻辑都是可复用的单元，可以先查看已有逻辑是否能满足自己的需要。配置数据构造流程。压测实施设定压测计划，到启动时间，系统会自动启动压测。压测中，注意关注压测验证校验的告警信息，及时处理。压测后，可查看压测报告。记录和跟进发现的问题。总结与展望目前，压测自动化系统已经投入使用，美团酒店和境内度假的全部团队已经接入，有效地提升了压测效率。后续会在两个大方向上持续建设升级，一个是把全链路压测放到“容量评估与优化”领域来看，不仅关注整体系统的稳定性，同时也期望兼顾成本的平衡；另一个是与稳定性其他子领域的生态集成，比如故障演练、弹性伸缩等等，在更多场景发挥压测的作用。最后，通过这些努力，使得线上系统的稳定性成为一个确定性的事情。参考资料[1] 全链路压测平台（Quake）在美团中的实践[2] 阿里JVM-Sandbox[3] Dubbo的泛化调用[4] Java的动态编译作者简介欧龙，美团研发工程师，2013年加入美团，目前主要负责境内度假交易稳定性建设等工作。欢迎加入美团基础架构技术交流群，跟作者零距离交流。进群方式：请加美美同学微信（微信号：MTDPtech02），回复：压测，美美会自动拉你进群。