全链路性能压测解决方案（单链路压测）

本文目录一览：

• 1、测试开发技术(二)——压力测试

• 2、阿里云服务器ECS如何选择？性能测试PTS助你测试和选择阿里云服务器

• 3、错误汇集

• 4、基于形变分析模型的异常检测系统建设与实践

测试开发技术(二)——压力测试

        上一篇文章里说过，目前互联网公司的测试开发岗位分两类。多数的一类是既要负责业务测试、自动化测试，同时也要去开发测试框架、效率工具来辅助业务测试。这类测试开发的岗位（主要指后端的岗位）一般多少都要接触压力测试。

        压力测试、性能测试、负载测试、稳定性测试在网络上有很多文章介绍概念和区别，通常在项目过程中不会区分那么多，实际项目中都是以目标为导向，通常实际项目中都会说，压测一下看下性能，所以这里就不管详细的概念和区别了。为了好理解，我们这里统一叫压测，并以得到性能数据为性能测试，以观察稳定性为稳定性测试。

        性能测试和稳定性测试的相同之处在于都是使用压测工具来进行。但目标不同，性能测试是通过压力测试得到系统的极限性能或者和上一版本的性能对比数据。而稳定性测试则是通过压力测试提供稳定或者变化的持续流量，来观察系统持续运行的情况下是否存在异常。

        正常情况下，一般系统先做性能测试，拿到极限性能或者性能对比数据（对于非1.0项目，性能数据一般需要和上一个版本对比）之后，再通过安全的流量持续压测更长时间，来完成稳定性的验证。

        下面我们就具体介绍一下怎么做性能测试和稳定性测试。

        性能测试的第一步要确定目标，就是为什么要做性能测试，要达到什么样的目标或者效果。比如某个首次上线的系统，性能测试主要是为了得到系统的极限性能数据；再比如，系统优化，更换了RPC协议或者消息队列，性能测试就是为了量化此次系统优化在性能上优化的效果。另外，也不是所有的项目都需要性能测试，比如一个内部系统，用户数和流量本身就很少，而且在未来一段时间也不会有增量，这就基本不需要性能测试。

        如果是从无到有的1.0项目，因为项目还没有上线，所以只能评经验来预估线上的流量数据；但如果是非1.0项目，就可以收集当前的线上数据。具体收集的数据如下（仅供参考，要按照实际情况来调整）：1）被测系统或模块各类请求流量比例；2）系统或模块目前平均、峰值、最小 qps；3）线上部署方式和规模；4）被测系统或模块依赖能承受的QPS或者容量。

        确定目标和收集完线上现有数据之后，需要根据目标和现有数据确定压测方案，比如，每个阶段通过多大并发或者流量来压测、分几个阶段、每个阶段多长时间、以及压测过程中需要观察和记录哪些数据等。

        同时，也要准备压测环境，压测的环境要尽可能的和线上一致，如果达不到，就做等比缩放。比如，一个系统有A、B两个模块组成，线上A部署了20台机器，B部署了5台机器，那么压测就可以A部署4台，B部署1台。机器和实例的数量只是一个方面，同时也要考虑机器的性能（CPU盒数、内存、磁盘、网卡等），还要考虑依赖方（如DB、缓存、消息队列等）的部署。部署压测环境的核心思路就是要用这套环境反应出线上环境的真实情况。

        要进行压力测试就一定要有压测工具，一般来说压测http或者其他开源协议可以在网上找到现成的工具，比如jmater之类的。但如果场景比较特殊，或者使用的是公司或项目的私有协议，就只能使用公司内部的工具或者自己动手开发了。

        选择好压测工具就要构造压测数据了。构造压测数据主要分两点：

        第一点是要构造压测环境系统中的数据。因为线上系统内部一定是有一定数据的，我们要尽量模拟线上就要在系统中添加相应的数据。

        另一点就是要准备压测的请求数据。这点跟选择的压测工具有关，一般来说分2种：

        1）数据词典， 压测的请求提前准备好，存入文件、DB或缓存里，数据量较大的时候一般需要写程序生成。

        2）实时生成，这种是压测工具在压测的时候根据配置规则来实时随机生成请求。

        准备工作一切就绪，下一步就开始做压测的执行。这时候主要就是根据压测方案的从低到高去调整压测工具的并发数或请求数，来对目标系统或模块进行压测。

        压测时，要观察CPU、内存、网络IO、磁盘空间、被压目标日志、依赖系统或者模块的状态等数，也要记录不同并发下目标系统或者模块处理请求的QPS和响应时间。同时也要注意有没有内存泄漏、句柄泄漏、系统崩溃等问题。

        实际上部分数据在记录的过程中就可以初步整理出来。这里要针对上一步记录的数据，进行汇总，主要要产出在不同并发下，上面提到的数据都是什么情况。需要根据数据判断出极限性能，找到这种部署情况下瓶颈在哪，以及是什么原因造成的，为后续扩容提供依据。有些情况还需要跟以前的数据做对比，看性能提升或者下降的程度是不是符合预期。最后，把这些信息综合汇总、分析之后，产出性能测试的报告。

        通常性能测试之后拿到了性能数据之后，都会在安全的并发或者流量下持续压测更长的时间来确保服务的稳定性。比如，笔者通常测试性能的时候，每轮可能压测半小时到一小时（在刚开始并发或者流量较小的时候可能会更短），在得到期限性能之后，会控制极限性能时80%-%90的流量或者并发去压测更长的时间，这个时间一般会比较长，而且多数情况下会在晚上下班前启动，然后第二天到公司来看结果。

        除了长时间通过安全流量来验证外，有些时候在特殊场景下，也需要验证在安全流量范围内，流量急曾或者急降的情况下，稳定性是否有影响。或者，验证在一定流量下，模拟某个依赖或者系统内部的模块出现问题，执行相应预案时，对系统整体的影响是否符合预期。

        当然，稳定性很多情况是异常，但更多的异常会在异常测试里去做，这里的稳定性测试是指在一定流量压力下的稳定性测试，其他的就不做讨论了。

        上面介绍了压力测试里，性能测试和稳定性测试要做什么，那具体怎么做呢？下面我们就通过一个实例来简单介绍一下。

      一个消息推送的系统，推送的消息就是我们日常手机APP的通知消息。这个消息通知的系统有三个接口，分别是单播（指定推送给某个人）、组播（推送给一个组，组里可能有多个人）、广播（推送给APP所有用户）。现在这个系统做了一个重构，更新了内部交互的RPC协议，所以要压一下，跟之前的性能数据做个对比。另外，系统重构前，线上集群极限性能为30000 QPS。

        下面，我们就按照前面的步骤，来简单介绍一下具体怎么做。

      目标就是要得到重构后的系统性能数据，并和原有的做对比，原有的极限性能已知，大概在30000 QPS左右。

        收集线上数据，比如说我们收集到单播、组播、广播的请求比例为5：78：1；组内人数大概在300-1000；发送的消息字符数在30-100这个区间。

        压测方案要先确定部署方案，比如这个系统向上是20台机器（或者实例），压测采用2台机器（等比缩放）。压测机器是线上的1/10，所以我们的目标性能就是3000qps。那么我们压测的方案就可以如下设置：

        第一轮，2个并发，5-10分钟，主要目的是为了先验证环境和压测工具没有问题；

        第二轮，根据上一轮并发数和机器资源（CPU、内存、IO）的情况，调整并发到极限的一半多一些（比如，之前是2个并发，CPU占用10%左右，内存、IO占用都很小，那么就以CPU的占用作为参考来计算，1个并发大概占用5%，那我们就可以吧并发调到10-12，目标CPU占用是50-60%）。这其实才真正开始压测，如果没问题，就开始逐步加压；

        第三轮，开始逐步增加，按照实际情况一次增加2-5个并发，直到性能达到瓶颈。

        这里是假设压测工具通过调整并发数来操作压力，主要需要看下并发对系统CPU、内存、IO的影响，根据压测时机器的资源占用信息来判断增加多少并发。

        确定好方案，就需要部署压测环境了，这里要注意，尽量使用跟线上一致配置的机器。

        压测工具要根据实际业务做选择，必要的时候需要自己开发，工具开发后面如果有机会在其他的文章里介绍，这里就不多介绍了。我们这个例子因为是系统更换内部协议，对外接口不变，所以可以使用原有压测工具。

        下面就是要构造数据：

        首先，要构造系统内部的数据，比如用户信息、设备信息、组信息，这里既要根据线上的收集到的信息来构造，比如用户数、组的数量、组内用户数等。这类如果方便的话可以直接在DB里插入，或者掉相应的系统API来准备。

        然后就是压测的请求数据，比如说压测工具是用数据词典来压测，那么这里我们就通过脚本，来生成压测请求数据。这里要注意线上收集到的各个接口的占比，即5：78：1。压测的时候按照这个比例来提供流量。

        准备工作完成，开始做压测。

        这时候要先吧各类数据观察准备好，一般现在的互联网大厂都有图形化的工具来看，如果没有也可以通过linux的一些命令来看。常用的命令有top\ps\vmstat， 这里推荐使用top来查看实时的资源情况，使用vmstat的来定时输出当资源情况（vmstat -t 1 就是每秒输出一次）。

        准备好了观测，那就启动压测工具，按照方案压测。压测方案上面已经介绍，这里就不重复了。

        假如我们并发加到20个的时候，CPU占用达到85%左右，处理请求达到3600qps，其他资源占用都不足机器的一半；并发加到22个的时候，CPU占用达到95-100，处理请求是3700qps；并发加到24，CPU打满，处理请求3800QPS，并且出现错误日志。这时候就可以停止压测了。

      数据整理，我们首先要整理一个表格或者图标，我们这里用表格：

       这个表格就是压测产出的最核心的数据，由于CPU是明显的性能瓶颈，表格里就不体现其他资源了，如果其他资源使用率也比较高，也要放到这个表格里，又或者瓶颈在外部依赖，也要体现出来。通过这个数据可以看出，3700QPS就是系统处理的极限，安全的流量在3600QPS。这时候就可以用17-20的并发数，长时间压测压测一下，看看系统整体的稳定性。

      那么性能报告怎么写呢？下面就给出一个比较简单的性能报告样例。

        标题：消息推送RPC协议升级性能测试报告

        一、项目背景

                这里写项目背景和目标

        二、压测环境

                线上20台物理机，压测环境使用2台物理机，配置与线上一致，具体如下：

                XX核，XXG内存，万兆网卡，硬盘 400G * 6 SSD

                DB：XX主XX从XX备

        三、压测方案和数据

1. 请求比例

      单播：组播：广播 =  5：78：1

2. 压测过程数据

      3.  资源占用图

    可以把QPS和CPU占用使用工具（比如excel）生成一个折线图，另外，可以把其他资源数占用的数据图片贴一下。

        四、结论

        压测过程中，压力达到3700qp时，内存与IO正常，CPU占用达到98%，无错误日志。压力达到3800qps时CPU打满，且5分钟后开始出现错误日志。因此系统在2台物理机部署极限性能为3700qps，性能瓶颈在CPU，预计线上20台机器极限性能为37000qps.

        系统RPC协议升级前20台机器30000qps，升级后预计能达到37000qps，性能整体提升23%，符合预期。

        上面就是一个比较简单的报告，真实项目中瓶颈不一定是CPU，可能是其他资源，也可能是依赖的系统或者模块，这些都需要观察和分析压测中的数据来得出。

        压力测试是后端测试和测试开发人员的必备技能，这篇文章只是根据笔者的经验针对压力测试进行的总结，不能覆盖所有压测场景，仅给大家做个参考。更多的是需要我们根据系统的实际情况去探索和实践。

阿里云服务器ECS如何选择？性能测试PTS助你测试和选择阿里云服务器

阿里云服务器ECS如何选择？很多新手用户并不知道PTS是什么，如果你不知道如何选择阿里云服务器ECS产品，性能测试PTS可以很好的帮助你快速对云服务器进行压力测试，从而助你选择适合自己的阿里云服务器ECS，下面是性能测试PTS详解！

阿里云开发者社区最近推出了一个“ ECS 选款利器！PTS助您快速上云 ”活动，PTS性能压测包仅需0.99/月起，真实模拟，免去繁琐的搭建和维护成本！现在您可以只支付10块钱不到的试用成本，即可体验使用 PTS 来帮助 ECS 进行容量规划选择合适规格的整个流程！

完成动手实验的同学，即可参与抽奖活动，小米手环 6、蓝牙键盘、掌上游戏机、笔记本支架、 数据线、优惠券等丰富奖品等您来拿！限量 1500 份，抽奖即得，百分百中奖哦！

性能测试PTS（Performance Testing Service）是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。

PTS旨在简化性能压测本身的工作。

PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

业务场景

PTS广泛应用于各种压力测试和性能测试场景，包括但不限于以下场景：

PTS孵化于服务阿里巴巴全生态五年以上的单链路、全链路压测平台，是阿里巴巴内部最佳实践的输出。该平台对内除了支持日常的外部流量压测之外，同时支持了大大小小的促销活动，如天猫双11、双12和年货节等。

压测流程

PTS提供全面高效的压测流程：

压测流程说明：

1.在PTS控制台上，准备压测API数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。

2.压测启动后，PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。

3.通过随机调度全国上百个城市和运营商的内容分发网络CDN （Content Delivery Network）节点，发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。

4.通过压测引擎向您指定的业务站点发起压测。

5.压测过程中，通过集成云监控、ARMS（应用实时监控服务）产品，结合PTS自有的监控指标，实时采集压测数据。

6.在PTS控制台，实时展现压测数据，进行过程监控；压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

压测创建方式

PTS支持以下4种方式创建压测场景（或称压测用例），如下图所示：

说明：

方式一：PTS自研零编码可视化编排，使用自研强大引擎压测。

方式二： 使用PTS自研云端录制器，零侵入录制业务请求并导入1中的自研交互中进行进一步设置。

方式三： 将导入脚本压测 1中的PTS自研交互中，使用PTS自研引擎。

方式四：JMeter压测并使用原生JMeter引擎进行压测，PTS提供自定义的压力构造和监控数据汇聚等产品服务。

其中，方式一、二、三由于使用了PTS的自研引擎，具备RPS（Requests per Second）吞吐量压测模式、秒级启动、实时控制、定时压测和流量遍布全国运营商网络的差异化能力。

方式一是PTS最核心的一种压测场景创建方式，所有资源包均可使用。其他几种创建方式面向不同规格资源包开放。

适用于多业务场景

不论您处于哪个行业，在以下业务场景（但不限于），PTS都是您值得信赖的性能测试工具。

适用行业广泛

PTS应用行业广泛，涉及电商、多媒体、金融保险、物流快递、广告营销、社交等等。

PTS服务阿里巴巴全生态多年，支持了天猫双11、双12、年货节等大促活动。植根于电商行业的PTS，对电商的典型业务模型支持得更友好，压测来源更广泛，脉冲能力和流量掌控能力更强。

PTS自商业版发布以来，吸引了来自多媒体、金融保险、政务等众多行业的用户，以其强大的压测场景编排能力和报表能力，帮助用户快速发现问题，进行针对性地调优，提升了系统承压能力。

适用于多种网络环境

不论您的业务位于公有云、专有云、混合云或者自建IDC中，只要能够通过公网访问，PTS都能够通过遍布全国上百个城市和各运营商的CDN节点发起压测流量，最大程度地模拟真实业务场景。

适用于使用HTTP/HTTPS/WebSocket等协议的客户端

PTS本身的GUI模式支持HTTP/HTTPS协议的压测，无论您的客户端是自研的App、移动端网页、PC端网页、微信小程序还是C/S结构的软件，都可以使用PTS进行压测。PTS同时集成了开源JMeter，支持更多的协议和场景，例如您可以通过“JMeter + WebSocket插件”的方式，对使用WebSocket协议的客户端进行压测（在PTS上传相应的插件JAR文件即可），其他协议以此类推。

下面以电商典型业务场景为例，为您介绍如何在PTS中编排压测场景。

什么是压测场景

要发起一次性能压测，首先需要创建一个压测场景。压测场景中包含一个或多个并行的业务，每个业务包含一个或多个串行的请求。

示例

淘宝网需要对产品A和B相关的页面（即存在多个API）进行压测，假设其主要业务场景为：

业务A：浏览产品A。

业务B：购买产品B（登录 → 浏览产品B → 加入购物车 → 提交订单）。

那么在压测场景中的设置如下。

串联链路1：浏览产品A 和串联链路2：购买产品B是并行关系。

根据业务逻辑，一部分用户在浏览产品A，另一部分用户在进行购买产品B的一系列操作，即两个业务是同时发生的，所以将它们设置为两个串联链路，压测中会并行发起请求。

串联链路中的多个API是串行关系。

根据业务逻辑，串联链路2：购买产品B中的一系列用户行为是存在先后顺序的，所以将这些存在先后关系的API添加到一个串联链路中，PTS压测中会按照顺序发起压测。

综合来看，在压测中，示例中的浏览产品A的API和登录的API，会同时发起压测流量。更多性能测试PTS场景示例，可参考阿里云帮助资料： 性能测试 PTS最佳实践

错误汇集

jmeter常见错误：

错误一：

Response code: Non HTTP response code: java.net.SocketTimeoutException

Response message: Non HTTP response message: connect timed out

查看Load time的时间要大于request设置的connect time out时间，所以抛出该异常。可能是由于服务端有较多请求正在处理（且处理时间较长），导致JMeter不能连接上服务器而产生的。

错误二：

Java.NET.BindException: Address already in use: connect

原因：短时间内new socket操作很多,而socket.close()操作并不能立即释放绑定的端口,而是把端口设置为TIMEWAIT 状态,过段时间(默认240s)才释放,(用netstat -na可以看到),最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ,这段区间在1024-5000之间)

解决方法：在运行JMeter agent的机器上，添加注册表条目HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

MaxUserPort 65334

TcpTimedWaitDelay 30

错误三：

java.lang.OutOfMemoryError: Java heap space

原因：观察运行jmeter机器的内存，占用较高，超过了jmeter设置的内存上限。

解决方案：修改jmeter配置文件，调整内存可用的范围

修改/bin/jmeter.bat文件：找到这2行

set HEAP=-Xms256m -Xmx256m

set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m

改为：

set HEAP=-Xms1024m –Xmx2048m（最大值不能超过系统内存的1/2）

set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m

错误四：

Response code: Non HTTP response code: java.net.SocketTimeoutException

Response message: Non HTTP response message: Read timed out

发生该错误时，jmeter已经连接上服务器，查看load time没有超过设定的request timeout时间，错误可能的原因是，服务器那边未处理该线程的请求，或者为保证服务能力，断掉了连接。

为了验证该猜想，持续大于半小时向服务器发送该并发数量的请求，一段时间后，request收到503的response，证明猜想。

错误五：

Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host:

原因：分布式测试时，server和agent之间的连接有问题。单个机器排查后，发现是某个agent机器安装了多个网卡，rmi远程的时候找的是虚拟机的网卡，导致连接失败。

解决方案：禁掉不使用的虚拟机网卡，测试之后再恢复。

jmeter 脚本运行的过程中，服务器性能参数没有明显变化（ CPU ，内存， I/O ），但 request 的响应时间很长。

原因：观察jmeter agent机器网络使用情况，网络使用持续达到带宽的限制峰值。request 发送的过程中pending在网络中，实际并发的request并没有同一时间到达服务器，所以服务器没有明显变化。

解决方案：提高jmeter agent机器网络带宽。

错误六：

Connection timed out: connect

 java.net.ConnectException: Connection timed out: connect

 at java.net.DualStackPlainSocketImpl.connect0(Native Method)

  at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)

  at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)

  at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)

  at java.net.AbstractPlainSocketImpl.connect(Unknown Source)

  at java.net.PlainSocketImpl.connect(Unknown Source)

  at java.net.SocksSocketImpl.connect(Unknown Source)

  at java.net.Socket.connect(Unknown Source)

  at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:121)

  at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)

  at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:318)

  at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:114)

 at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610)

 at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445)

 at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835)

 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:654)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:413)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.followRedirects(HTTPSamplerBase.java:1542)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1636)

 at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:519)

 at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:493)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)

 at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)

 at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491)

 at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425)

 at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254)

 at java.lang.Thread.run(Unknown Source)

原因分析 ：

可能是因为端口号耗尽，一般一台服务器的端口号最多是65535个，建议使用该命令分别查看下压测机与服务器的端口使用情况，netstat -nat|grep -i 8080|wc -l，如果这个个数在6w左右，那可能就是端口号用尽,同时查看下大多数的端口状态，应该都是time_wait状态

解决方案：

如果是压测机，端口号用尽，那就增加压测机，使用jmeter分布式压测（jmeter默认开启keep_alive的）

如果数服务器，端口号用尽，最大的可能是服务器端开了短链接，把短链接配置变成长连接即可

因为如果服务器端是短链接，当jmeter每发起一个请求就会建立一次tcp三次握手，传输完数据后，连接其实没有关，连接状态是time_wait,下个请求来了，会重新开启一个新的端口，建立tcp三次握手，传输数据....，这样随着请求的越来越多，端口就会变得越来越少，所以端口很快耗尽，而且大多数端口都处于time_wait状态,如果服务器端也支持长连接，那么下次请求来了，就会在上次请求的通道上继续传输，端口使用率大大的降低，就有效的避免了端口耗尽问题。

原因：Jmeter默认禁掉了运行过程中每个request的具体response信息收集，只保留了status。

解决方法：修改jmeter.properties文件中Results file configuration。把所有和response相关False的项改为True。运行后将输出保存.jtl文件中。添加tree监听器，过滤只显示error request，可以查看到request和response的具体信息，从而判断出错原因。

tree report 中显示 socket time out 相关的错误，如何判断是 jmeter 工具的原因，还是服务器的原因。

基于形变分析模型的异常检测系统建设与实践

外卖业务持续高速成长，业务迭代快，逻辑复杂，关联服务多。如何快速准确识别系统各项指标的异常，发现问题根因，并快速解决显得尤为重要。在常规业务指标监控工作中需要手动维护上万业务指标报警阈值，不仅成本高，效果也不佳。我们尝试使用“形变分析模型”对业务指标自动进行异常检测，无需人工设置阈值。在实践过程中与外卖全链路压测，服务保护等稳定性保障系统进行内联，目前已覆盖绝大部分美团外卖C端核心业务指标，效果不错。

美团外卖从2013~2018，历时五年，现在已经是全球最大外卖交易平台。外卖业务相关的指标主要会分为两大类：

美团外卖在业务稳定性监控建设中会与一线开发人员频繁沟通，针对监控告警需求主要存在如下几个痛点，如下图3所示：

在外卖业务场景下，与业务开发人员日常沟通过程中发现大家判断业务指标是否异常，大多数是通过人眼观察形状是否符合预期。我们希望找到一种方式可以通过对时间序列的 形状预测 来判断是否异常，并希望可以对异常严重程度设定不同的告警等级。通过简单的模型来覆盖常见故障场景，并具备较好的普适性。形变分析模型从上述痛点出发不断向前演进。

任何一种异常检测模型都有它的适用范围，形变分析模型也不例外，这里需要强调一下形变分析模型主要针对有规律的时间序列进行分析检测，主要会依赖两个简单的计算公式：

基于形变分析模型的异常检测主要关注点概括为如下几点，具体如下图4所示：

下面会对形变分析模型详细展开介绍。

下面给大家重点介绍一下形变分析模型的分析过程，这里主要会有四个步骤，具体如图5所示：

上面通过流程图介绍了一下形变分析模型的整体流程，下面针对形变分析模型中最核心的两次处理操作通过具体案例展开介绍一下。第一次是针对形状或时间的处理，具体如图6所示，形变分析模型预测出基准线，通过真实数值与基线数值进行归一化互相关计算，计算出一个新的时间序列，因为余弦相关通常用于正空间，所以每一个点都归一到了[0 , 1]区间上，从而去除了形状或时间的影响。归一化之后新的时间序列除了在午高峰附近两个明显的异常点有较大波动，在凌晨低峰期因为量级较小，也会出现比较明显的波动（因为量级小，形状差异会被放大）。上述现象表明不同时段的业务量级对余弦相关性影响较大，需要找到一种方式将量级的影响去除。

第一次处理去除了形状或时间对时间序列的影响，接下来我们发现通过 如图7所示 的形变量计算公式可以将量级进行还原，或者可以理解为针对不同的量级赋予不同的权重，形成新的时间序列可以去除量级的影响，这就是第二次针对量级的处理，最终将时间序列归一到形变量集合上，通过聚类计算基准形变量达到设定不同告警等级阈值的目的。统一的标准为我们后续结合用户反馈对不同等级告警阈值进行微调带来了便利。

针对重大事故时如何避免出现告警洪潮，针对典型故障场景如何快速给开发人员提供简单直观的建议，这些也是在异常检测系统中需要重点关注的问题。其中告警收敛模型会优先关注两大类问题：

上面向大家介绍了形变分析模型的分析过程，接下来会通过几个典型案例详细说明形变分析模型解决了美团外卖哪些现实问题。

业务异常检测系统在整个稳定性保障体系中处在核心位置，承载着在业务出现重大事故时进行快速异常识别、定位根因、给出降级建议的责任。会分几大模块进行建设，具体如图15所示：

美团外卖偏向业务的技术保障能力对用户主要分为两大核心场景，具体如图16所示：

基于形变分析的异常检测系统现在美团外卖应覆盖核心业务指标2400多个（其中包括订单、流量、营销、SET等），因为使用的算法较简单，单次异常检测流程时间可以控制在200ms。

在发送给用户的告警信息中不断收集用户反馈信息，在已有的反馈标记中，异常检测的精确率、召回率可以达到80%，当然异常检测的准确性还有一部分依赖时间序列数据采集聚合通道的稳定性。关于告警阈值配置功能，有74%的核心业务指标可以进行自动配置并调整。

本文主要给大家介绍了形变分析过程，突出对时间序列形状的预测。针对有规律的时间序列形变分析模型具有较好的适应性。然后给大家介绍了异常检测系统在美团外卖整个稳定性保障体系中的作用，以及形变分析模型在美团外卖的落地情况。

在进行业务指标异常检测时，尝试找到通用的异常检测方法非常具有诱惑力，但可能并不是最佳选择。尝试最适合你问题的最简单方法。用简单方法处理复杂问题，用简单模型收敛问题，用小成本撬动大效能。

作者简介

刘宏伟，2016年加入美团点评，美团外卖技术保障组负责人，现正在围绕业务进行稳定性评估、实时监控、异常检测与故障诊断等方向的建设。

美团外卖技术保障组：围绕业务稳定性建设事前通过全链路压测系统建设提前发现服务性能瓶颈、进行服务保护预案演练、容量规划；事中通过异常检测与故障诊断模块，在重大事故时可以快速识别关键问题链路，定位根因；事后通过服务保护系统进行快速保护预案的触发，帮助开发人员快速解决线上问题，提升人效。

在此感谢对美团外卖业务异常检测做出重要贡献的同学：永强、庆文、召新