应用性能诊断方法与行业最佳实践分析
我的图书馆
应用性能诊断方法与行业最佳实践分析
随着Internet的普及与迅速发展，企业业务量的迅速加大，&IT系统承载的负荷越来越重，系统性能的好坏严重影响了企业对外提供的服务质量。应用性能诊断分析是性能测试实施过程的重要环节。目录通用的性能测试实施过程应用性能诊断分析方法-分层法应用性能诊断分析方法-分段法总结一.&通用的性能测试实施过程1、需求分析性能测试需求是应用需求的衍生。需要借助于相关的理论知识和相关领域的经验积累，对性能测试需求进行分析整理。需要明确下面相关内容：测试目标测试范围测试策略测试模型构建&&测试环境进度计划准入、准出和暂停准则职责分工度量指标测试用例2、环境准备在实施过程中需要监控主机、中间件等资源，我们需要提前准备相关监控工作：监控工具部署相关参数配置监控脚本部署和测试性能测试工具部署3、实施压测脚本录制、编写测试场景制定场景压测过程监控监控数据收集4、结果分析及优化利用监控到的数据结果分析系统性能情况，并定位系统的性能瓶颈所在并进行性能优化。评价系统的性能情况可以借助相关指标：TPS响应时间主机资源情况：CPU、内存、IO、磁盘事务通过率性能优化通过可以从以下几方面进行优化：代码层数据库sql配置参数调整网络硬件资源这4个环节，每个都有很多细节的内容，在这里就不一一去细讨论了，我们重点看后边两部分关于性能监控、诊断分析方面的内容。二. 应用性能诊断分析方法-分层法应用性能诊断分析涉及到多层面的分析，包括操作系统、中间件、数据库、系统日志监控数据等等。我们主要从应用程序、中间件、网络、操作系统、数据库这5个维度来分析。这5个部分贯穿了整个应用从前端到后端的性能测试的整个过程，通过这5个层面的分析能诊断出系统性能问题是什么原因产生的。对于不同层面用不同的指标去度量，通过度量指标来分析定位性能问题，下面是5个层面典型度量指标：每个层面关注的度量指标下面我们来看一个简单的案例：该案例主要从应用、主机资源和中间件三个维度来分析，它是Apache/Tomcat+Linux+Oracle的架构。Web服务器：Apache应用服务器：Tomcat操作系统：Redhat6数&据&库：Oracle&11采用主流的性能测试工具Loadrunner进行压测。监控是诊断分析的基础，收集监控数据就像福尔摩斯探案时查找各种蛛丝马迹！我们采用分层监控的方法。例如，Linux监控使用开源的Nmon进行Linux系统性能数据采集。主要关注：CPU占用率内存使用情况磁盘I/O速度、传输和读写比率文件系统的使用率网络I/O速度、传输和读写比率、错误统计率与传输包的大小消耗资源最多的进程计算机详细信息和资源页面空间和页面I/O速度用户自定义的磁盘组网络文件系统启动该程序，使用如下命令：./&nmon_x86_fedora5&–fT&–s&5&–c&100或在后台运行Nmon，使用如下命令：nohup&./&nmon_x86_fedora5&–fT&–s&5&–c&100通过sort命令可以将Nmon结果文件转换为CSV文件。#&sort&-A&test1_3.nmon&>&test1_3.csv执行sort命令后，即可在当前目录下生成test1_3.csv文件。Web服务器Apache监控：修改/conf/httpd.conf配置文件，把server-status打开。Apache监控信息：Total&Accessess：总的访问量。Total&kBytes：总的字节数。CPULoad：当前Apache服务器所消耗的CPU。ReqPerSec：每秒请求数。BytesPerSec：每秒传输的字节数。IdleWorkers：空闲的线程数。BytesPerReq：每秒请求的字节数。BusyWorkers：目前服务的线程数。这些信息可以通过Shell脚本实时写入文件中，通过Nmon工具进行分析；也可以通过LoadRunner获取并生成监控图表。应用服务器Tomcat监控方法1：通过Tomcat自带的Manager模块获取包括JVM、连接线程相关的信息。方法2：通过编写Shell脚本监控。方法3：用JAVA附带的工具Jconsole，重点监控JVM。在Excel中编写一个小工具，把监控收集的数据生成图表还有其它层面的性能监控配置，这里就不再详细描述了。总结起来，各个层面的监控方法，工具各异，需要关注的性能指标也不同。有了监控的基础数据，后边我们再看诊断分析的方法。通常我们是采用从上而下的方法。业务指标+前端页面性能分析压测100个用户浏览器无缓存的情况：图中绿色代表的是vuser的数目，橙色代表的是选择办证日期事务响应时间，蓝色代表的是进入预约申请事务响应时间，灰色代表的是选择办证地点事务响应时间，从此图可以看出，选择办证日期响应时间一直维持在80秒以上，平均的响应时间达到了140秒。进入预约申请页面，当用户数达到100时，平均响应时间直线上升，从开始的16秒上升到67秒，运行了3分10秒后，响应时间达到最高的126秒。选择办证地点是随着100个用户持续运行，响应时间不断增加。从图1中事务平均响应时间中观察发现共有三个事务的响应很长，分别是：选择办证日期140S、进入预约申请界面57S、选择办证地点28S。通过对进入预约申请界面事务的页面进行分析，发现有JS\JSON消耗资源比较严重，如下图，处理满意度调查的json的响应时间超过了10S,处理基本信息业务逻辑的JS的响应时间超过了15S，这两个业务逻辑的响应时间在单个用户请求时，已经远超过预期。处理满意度调查的json处理基本信息业务逻辑的JS而在进入预约申请的这个事务，页面上加载图片，所消耗的资源也是很多，如图4中首页图片资源消耗情况，其中一张index开头的图片大小差不多1M，首页加载的页面的总和差不多4M左右，这大大降低了客户访问次页面的速度。建议把图片进行压缩传输。选择办证地点的这个事务的平均响应时间是在27S，而监控该事务的前台页面发现，在此页面上出现了js\json的响应时间过长，最长有达到30多秒，一般情况下，客户端发送服务器请求，响应时间超过30S,就设置为超时，这种响应时间超慢的逻辑，要求修改以满足用户需求，如图5所示。加载办证地点的json资源消耗情况接下来分析后端Web服务器层分析由于Apache和Tomcat装在一台机器上，通过查看的这台机器的日志输出，Apache和Tomcat都没有发现错误日志，tomcat也未出现404错误，监控这台机器的系统资源情况看出，CPU、I/O、内存都在合理的区间内，具体可以参照测试方案资源使用度量指标，具体见以下3张图。系统资源整体情况CPU资源总体使用情况磁盘读写/IO资源使用情况而在并发200时，Apache的连接数(BusyWorkers)达到226个，总共256个，如果加大并发用户数，Apache的连接数需要增加，如下图所示。应用服务器层分析下图中的Tomcat&的线程使用情况可以看出，当前使用的线程（currentThreadCount）和当前忙碌的线程（currentThreadBusy）都在100的范围内，空闲率很高，而此时主机的cpu\内存运行正常，监控后台日志，未发现有明显问题，由此得出Tomcat在压测过程中运行稳定，具体情况请看下面的图片。虚拟用户数Tomcat的线程使用情况主机空闲内存资源情况这里没有关注JVM的监控，可能会忽略掉Java内存泄漏的问题！数据库服务器层分析下面的四个图中是在压测时数据库主机的各项资源使用情况，从四副图的变化趋势可以看出，内数据库主机在压测时，各项资源使用情况都在合理范围内，因此，数据库表现正常。具体见下面数据分析图。这里没有对数据库本身的性能监控数据进行分析，例如等待时间、慢查询等。整体结果分析系统在运行100个用户无浏览器缓存的情况下，应用服务器、数据库服务器的CPU和内存资源空闲。在LR的报告中，进入预约申请界面事务，平均响应时间约是57S，与要求的响应时间相差甚远。从以上的结果中，逐一分析:对图片对象、js\json监控的数据进行分析。需要对消耗资源大页面文件采用压缩传输方式。对加载时间过长的业务逻辑进行精简或者用其它方式实现。对Apache分析，随着并发数的增加，而Apache的连接数一直处于峰值，建议增加apache的最大连接数。由于Apache和Tomcat共用一台主机，系统上线后随着用户数的增多，性能可能会相互影响，建议分开部署。以上是对应用、中间件和主机进行性能诊断分析，没有深入到应用的代码层和数据库层。应用性能诊断分析应该围绕应用程序、中间件、网络、操作系统、数据库5个维度，分析应用程序在Web层、中间件层、数据库层的调用情况，组合成完整的调用链，从而形成清晰的业务视图，同时在应用程序方面需要深入定位到代码层，才能准确、高效定位性能问题。方法总结：逐层分析监控数据，找出性能隐患。前面介绍的分层法诊断分析需要对操作系统、中间件、数据库、Web服务器各层分别进行监控，收集数据后进行诊断分析。优点：可以在各个层面分析得很透彻，如果团队规模大，力量强的话，可以结合各种角色，例如中间件工程师、DBA来综合分析。通过关联分析可以在某个层面找到一些尚未发生的性能隐患。缺点：每个层面的监控分析所需工具、指标分析能力要求比较深入。难以形成业务流调用链层面的性能分析，很难直观地看到性能瓶颈所在。难以深入到代码层进行性能诊断。三. 应用性能诊断分析方法-分段法借助APM工具查找性能瓶颈，定位性能问题，及时优化。APM这类工具通过分段收集业务流性能指标，可以弥补前面的分层法诊断分析的缺点，例如通过对中间件JVM的性能数据收集，可以深入分析代码调用、SQL调用等业务层性能问题；并且从URL到中间件Java代码，再到数据库SQL，各段的性能数据是通过业务流调用链串接起来的，所以可以从业务层面很直观地看到哪些业务流程有性能问题，性能瓶颈在哪段。由于时间关系，APM在性能测试的应用这次就不作详细介绍了，下次有机会再详细分享。四. 总结1、性能测试过程中性能监控和诊断分析是比较关键的环节，它决定了性能测试的最终效果，能否得到很好的优化就看诊断分析的深入程度了。2、性能诊断分析的方法可以采用分层法和分段法，各有一些优缺点，我们可以考虑综合应用。这次分享主要介绍了分层法在性能诊断分析中的应用，这种方法要求对各个层面（前端页面、网络、Web服务器、中间件、数据库）的监控和指标分析都要能涵盖和深入分析，并且要再把各层的数据关联起来分析，比较依赖人在软件系统性能方面的知识结构和经验。3、本文大部分内容都来源于新炬网络近期出版的书籍&《深入浅出性能测试与LoadRunner实战》。& & & Q & AQ1:我们的测试环境在大多数情况下是不能与真实生产环境在硬件上达到1比1的配比。在此种差异下的分层压力测试，如何能客观的分析出系统的实际瓶颈在哪里，如何进行不同硬件环境下业务处理能力的换算？A1:我们通常的做法是把测试环境的资源分不同的级别，分别压测，做容量预估，再推测生产环境的业务处理能力。Q2:我们面临的尴尬局面是，对不同的硬件环境，性能测试组被要求做与生产一致的数据量进行压力测试，以此来评估生产环境的新业务处理能力。这是难以实现的，请问有什么办法解决吗？A2:现在很多企业倾向于在运维环境引入APM这类工具，在线上实施监控，出性能问题了，能直接定位到代码、SQL，给开发及时的反馈。这也就是DevOps的理念了。Q3:请问每个业务不能直接定义并发数,对吗？A3:可以直接定义，但是缺乏依据，不好拍，例如从注册用户数的不同角色，使用的频繁度，等方面去拍。loadrunner可以针对每个业务场景定并发用户数的。Q4:请问关于并发用户，脚本中的thinktime 到底要不要忽略呢？A4:看是做的什么类型的测试，如果要做负载测试，就加上思考时间，如果是做压力测试就考虑去掉，并且在某些并发点加上集合。Q5:测试用例的选择，以及脚本中是否有参数化对于测试结果的影响比较大，怎样去做这一部分的设计呢？A5:测试用例的筛选会有些套路。比如通过评价业务的关键程度，使用频繁度等方面去筛选。是否参数化就要结合系统设计情况了，要评估不同数据类型对性能是否有影响。讲师介绍：陈能技【DBA+社群】专家，新炬网络首席APM架构师。14年开发测试与质量架构经验，擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。&小编精心为大家挑选了近日最受欢迎的几篇热文↓↓↓
TA的最新馆藏
喜欢该文的人也喜欢关注51Testing
性能测试中AIX服务器资源监控与瓶颈分析
发表于： 11:14 &作者：唐磊 & 来源：51Testing软件测试网采编
推荐标签：
　　运行在的P系列服务器上的AIX操作系统以其良好的性能、可扩展性和可用性征服了许多挑剔的用户，在现代主流信息系统中占有重要的地位。本文参考了一些成熟的理论，结合作者的实践经验，旨在对性能测试中AIX服务器的资源监控进行分析和总结。　　1、负载压力条件下的性能监控　　通过在监控负载压力条件下AIX服务器的表现，针对暴露的性能瓶颈进行调整，可以对信息系统进行优化。而对性能的监控主要可以通过商业软件和命令行两种方式实现，而前者主要通过调用系统自身命令行执行实现。　　1.1 服务器资源监控指标：　　AIX服务器的主要监控指标见下表：　　1.2 服务器资源监控指标获取的方式：　　服务器资源监控指标可以通过商业测试软件、监视工具、AIX命令行三种方式获取。　　1.2.1 基于商业软件（如loadrunner）　　开启RPC服务及其守护进程后，可以连接AIX服务器对其资源情况进行监控。　　1.2.2& 基于文本的监视工具（以Nmon为例）　　在服务器上安装Nmon后，可以通过命令行实时获取服务器资源，既能获取原始数据资料（如下图1），也可通过后期处理得到可展示的图表，（如下图2）。图1 测试中获取的Disk total 原始数据片段
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道【618】升级全链路压测方案，打造军演机器人 ForceBot
准备电商大促就要准备好应对高流量，全链路压测无疑是必不可少的一个环节，但是同时也涉及到很繁重繁琐的工作。京东研发设计了军演机器人，这为今年备战 618 减负不少。最初，军演机器人 ForceBot 正式立项并组建了一个虚拟的研发团队，彼时计划是基于开源的 nGrinder 项目进行二次开发，随后实现部署即可；随后在深入研发之后，又根据京东的业务场景对 nGrinder 进行了优化，以满足功能需求。
传统的压测方案
传统的系统压测基本都是部署在内网环境，和被压测的系统部署在一个局域网内，比较常用的工具有：loadrunner、jmeter、nGrinder、gatling、iperf 等等，通过这些工具，模拟生产环境中的真实业务操作，对系统进行压力负载测试，同时监控被压测的系统负载、性能指标等不同压力情况下的表现，并找出潜在的性能优化点和瓶颈，目前流行的压测工具，工作原理基本都是一致的，在压力机端通过多线程或者多进程模拟虚拟用户数并发请求，对服务端进行施压。以往在京东，备战 618 大促要提前 3 个月准备，需要建立独立系统进行线上的压力评测，这为各个性能压测团队带来了很大的工作量。
除了工作量大的问题之外，传统的压测数据与线上对比，并不准确。以前对某个系统性能的压测需要在内网线下进行多次，压测出的结果各项指标与线上相比差异太大；这是因为线下服务器配置和上下游服务质量不可能与线上一模一样，只能作为一个参考，不能视作线上系统的真实表现。压测后需要思考如何进行各系统容量规划，每次大促前备战会进行基础服务资源的分配，如果不能精确预估容量需求，会发生扩容行为的浪费。
为了更贴近线上真实结果，有些系统也会通过直接内网压测线上系统，这样做需要上下游同步协调，费事费力，这样下来至少一周时间才能搞定。使用了 ForceBot 全链路军演压测系统后，目前只需要 2 天左右就可以完成所有黄金链路系统的性能评测。
变革，制造一个军演机器人
最开始的时候京东并没有直接投入研发力量，京东 618 年中全民购物节技术执行总指挥刘海锋首先提出了 ForceBot 这个想法，京东内部则面向各研发和性能团队进行大量的调研，了解他们现在的痛点和使用的工具情况，同时谈及了 ForceBot 的想法，这个想法获得了大家的赞同并且收集了很多宝贵意见和建议。于是 ForceBot 正式立项并组建了一个虚拟的研发团队，最开始计划是基于开源的 nGrinder 项目进行二次开发，随后实现部署即可。
nGrinder 基于开源的 Java 负载测试框架 grinder 实现，并对其测试引擎做了功能提升，支持 python 脚本和 groovy 脚本；同时提供了易用的控制台功能，包括脚本管理、测试计划和压测结果的历史记录、定时执行、递增加压等功能。
根据京东的业务场景对 nGrinder 进行了优化，以满足我们的功能需求。比如：提升 Agent 压力，优化 Controller 集群模式，持久化层的改造，管理页面交互提升等。
nGrinder 能胜任单业务压测，但很难胜任全链路军演压测。分析其原因是 Controller 功能耦合过重，能管理的 Agent 数目有限。原因如下：
Controller 与 Agent 通讯是 BIO 模式, 数据传输速度不会很快；
Controller 是单点，任务下发和压测结果上报都经过 Controller，当 Agent 数量很大时，Controller 就成为瓶颈了。
也就是说问题出现在：Controller 干的活又多又慢，整体压力提升不上去。
尽管我们优化了 Controller 集群模式，可以同时完成多种测试场景。但是，集群之间没有协作，每个 Controller 只能单独完成一个测试场景。即 nGrinder 整体构架无法满足设想的军演规模和场景，也算是走了一些小弯路，最终在其基础上开始新的架构设计和规划，规避已知瓶颈点，着手研发全链路军演压测系统（ForceBot）, 为未来做好长远打算。
ForceBot 平台在原有功能的基础上，进行了功能模块的解耦，铲除系统瓶颈，便于支持横向扩展。
对 Controller 功能进行了拆解，职责变为单一的任务分配；
由 Task Service 负责任务下发，支持横向扩展；
由 Agent 注册心跳、拉取任务、执行任务；
由 Monitor Service 接受并转发压测数据给 Kafka；
由 Dataflow 对压测数据做流式计算，将计算结果持久化至 DB 中；
由 Git 来保存压测脚本和类库。GIT 支持分布式，增量更新和压缩
这样极大的减轻了 Controller 的负载压力，并且提升了压测数据的计算能力，还可以获取更多维度的性能指标。
在此基础上，还融合进来了集合点测试场景、参数下发、TPS 性能指标等新特性。
ForceBot 平台在上线提供服务后，在受到好评的同时也发现了一些问题。所以我们对架构和功能实现进行了调整。对问题进行了合理化解决，重新设计了架构中的部分功能实现，并对依托 nGrinder 和 Grinder 的功能，针对京东的使用习惯和场景，进行了自研，至此，ForceBot 平台由基于 nGrinder 基础上的深度改造升级为完全自研的性能测试平台。
Git 作为先进的版本控制系统，用来构建测试脚本工程的资源库再合适不过，但是直接使用它作为资源分发服务就不太合适了。Git 的每次操作如 Clone、Pull 等都是一组交互，传输效率不高。同时一代平台使用 GitLab 构建的 Git 服务集群依赖于一个集中的 NFS 网络共享存储，这就带来性能瓶颈和单点故障的可能。
架构调整中针对 ForceBot 平台的资源分发方式进行了重新设计，借助京东基础平台自研的京东分布式文件系统（JFS）的云存储服务（JSS）进行资源的分发。
新的架构调整中，增加了 Package Service 为性能测试脚本提供统一的构建打包支持，并通过对 Maven 的支持，与公司内网 Maven 私有服务交互，为脚本提供更灵活可靠的依赖管理。 Package Service 将脚本及其依赖类库、配置、数据进行打包，处理成一个统一的 Gzip 压缩文件，并上传至 JSS 以向 Agent 进行分发和归档。
平台在使用过程中，由于调试环境和实际运行环境有所差别，用户有查看 Agent 执行日志的需求。考虑到日志落地带来的磁盘 IO 对性能性能的影响，以及日志内容给平台管理带来的开销，新的架构中提升了日志的收集和处理功能。Agent 的日志不再落地本地磁盘，改为写入到内存一块固定大小的区域，最后经处理切割成一条一条的日志实体并结构化的存入 Elasticsearch 中供用户查询。
1.核心功能
平台核心功能在于需要向性能测试人员提供一个高效的可操作环境用于准确的描述其测试逻辑，并兼容大部门公司业务服务调用方式和场景。京东内部业务系统大部分使用 Java 语言开发，使用基础平台中间件技术部开发的 JSF、JMQ 等中间件进行服务调用，为此提供一个与 Java 语言高度兼容的脚本语言执行环境作为性能测试逻辑编写基础尤为关键。
系统选用了兼容 JSR223 规范的 Groovy 作为主要脚本语言，并效仿 Java 下著名的单元测试框架 Junit 的设计哲学设计了一套高效并友好的测试逻辑开发和执行环境。
平台核心脚本引擎为性能测试脚本设计了多种生命周期控制，以适用不同的场景，并使性能最优化。在脚本编写过程中，用户仅需要在 Groovy 脚本中使用内置的几种注解便可对脚本的执行和数据采集进行精确灵活的控制，如测试类生命周期、事物、执行权重等，大大提升脚本开发效率。
2.容器部署
为了快速的创建测试集群，Agent 采用 Docker 容器通过镜像方式进行自动化部署。这样做好处如下：
利用镜像方式，弹性伸缩快捷；
利用 Docker 资源隔离，不影响 CDN 服务；
运行环境集成，不需要额外配置运行所需类库；
每个 Agent 的资源标准化，能启动的虚拟用户数固定，应用不需要再做资源调度；
3.服务通信
Task Service 采用了 gRPC 与 Agent 进行通信，通过接口描述语言生成接口服务。gRPC 是基于 http2 协议，序列化使用的是 protobuf3，并在除标准单向 RPC 请求调用方式外，提供了双向流式调用，允许在其基础上进一步构建带状态的长链接调用，并允许被调用服务在会话周期内主动向调用者推送数据， 其 java 语言版采用 netty4 作为网络 IO 通讯。使用 gRPC 作为服务框架，主要原因有两点。
服务调用有可能会跨网络，可以提供 http2 协议；
服务端可以认证加密，在外网环境下，可以保证数据安全。
4.Agent实现
Agent 采用多进行多线程的结构设计。主进程负责任务的接收、预处理和 Worker 进程的调度。将任务的控制和执行进行进程级别的分离，这样可以为测试的执行提供相对独立且高度灵活的类库环境，使不通的任务之间的类库不会产生冲突，并有益于提升程序运行效率。
Agent 与 Task Service 保持通信，向系统注册自身并获取指令。根据任务需要启动 Worker 进程执行任务，主进程负责管理 Worker 进程的生命周期。Worker 进程启动后会通过 gRPC 与主进程保持通信，获取新的变更指令，如线程数变化通知，及时进行调整。
5.数据收集和计算
实现秒级监控。数据的收集工作由 Monitor Service 完成，也是采用 GRPC 作为服务框架。Agent 每秒上报一次数据，包括性能，JVM 等值。
Monitor Service 将数据经 Kafka 发送给 Compute Service，进行数据的流式计算后，产生 TPS，包括 TP999，TP99，TP90，TP50，MAX，MIN 等指标存储到 ES 中进行查询展示。
为了计算整体的 TPS，需要每个 Agent 把每次调用的性能数据上报，会产生大量的数据，Agent 对每秒的性能数据进行了必要的合并，组提交到监控服务以进行更有效有的传输。
新式全链路压测的打开方式
ForceBot 的工作基本原理就是站在真实用户角度出发，从公网发起流量请求，模拟数百万级用户 0 点并发抢购和浏览，由于压力机分布在全国各地，不同的运营商，所以最接近真实用户的网络环境，对于读服务通过回放线上日志形式模拟用户请求，数据更分散、更真实，避免热点数据存在，对于写服务则模拟用户加入购物车、结算、更改收货地址、使用优惠券、结算、支付等核心链路环节，每次军演都会发现新的问题和瓶颈，对后期的资源扩容、性能调优都会有针对性的备战方向，最终让研发兄弟对自己系统放心，让消费者购物无忧。
全链路压测方案最重要的部分是被压系统 如何去适应这种压测，如何精准的识别测试流量，如何协调整个研发系统统一打标透传压测流量，并做相应的处理，尤其对脏数据的隔离和清理尤其关键，被压测的系统要和线上环境保持一致，又要隔离这些数据，需要确保万无一失，尤其订单部分环节，出现差错是不可恢复的。
压测数据读的服务都是来自于线上服务器的日志真实数据，数据最终会由各个系统通过标记进入回收站，最终被清理。军演平台本身不会侵入到系统去清理垃圾数据，每次军演压测首先会有一个目标值，比如按照历史峰值的一个倍数去动态加压，如到了这个目标值，各系统性能表现都非常好，那么继续加压，直至有系统出现瓶颈为止。
军演机器人的过去与未来
全链路压测可以理解为网络链路 + 系统链路，网络链路是用户到机房的各个网络路由延迟环境，系统链路是各个系统之间的内部调用关系和强依赖性。其实去年双 11，京东就采用了 ForcBot，只不过仅仅针对重要链路；因为如果没有核心系统首先参与进来，小系统是搞不起来的，因为小系统强依赖核心系统。
今年备战 618，ForceBot 技术架构没有太大调整。我们工作一部分是平台用户体验的一个优化和性能的优化，让有限的压力机产生更大的压力请求；另外一个是整合被压测的系统监控，实时展示。
京东未来希望 ForceBot 可以实现“人工智能预言”。现在还在逐步的做，我们希望未来的全链路压测引入 AI 技术，通过人工智能预言各个系统的流量值和资源分配建议，根据线上的系统军演数据预言未来的大促各系统场景，举个简单的例子，在 ForceBot 平台上录入每秒一千万并发订单场景，以现在的系统去承载，各系统是一个什么样的性能指标和瓶颈点在哪？ 这就是我们思考要做的。
张克房，京东商城资深架构师，2010 年 3 月份加入京东商城，2010 年 -2016 年负责京东核心数据中心 IDC 网络、负载均衡、DNS、自建 CDN、DevOps 等多项运维架构和运维管理负责人，是京东早期运维体系架构变革和发展的直接参与者，奠定了京东运维现行的多项技术架构和运维模式，伴随京东从小到大，从无到有、从有到优的飞速变化。
本文转载自高效开发运维公众号
本文头图来自于网络
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点