性能测试之线上引流测试--让性能测试更真实更丰富

为何要作引流测试

目前为止大部分的测试是在测试环境下，经过模拟用户的行为来对系统进行验证，包括功能以及性能。在这个过程当中，你可能会遇到如下问题: 

• 用户访问行为比较复杂，模拟很难和用户行为一致，模拟不够真实;

• 线下模拟场景有限，会出现业务覆盖不全的状况。
  引流测试就是为了解决以上问题，经过把线上的真实流量复制到线下环境，解决测试环境模拟不够真实，或覆盖不够全面的问题。

引流的作法

目前很多公司对引流测试进行了实践，主要有如下4种引流方式：

以上几种办法各有利弊，有的是须要本身开发相应的工具来支持。在作URS产品性能测试过程当中，考虑到都是HTTP类型的请求，且大部分的请求为读请求，使用tcpcopy工具能够知足要求，且成本比较低。在介绍基于tcpcopy的引流测试在项目中怎么应用以前，咱们先来介绍下tcpcopy这个工具。

tcpcopy介绍

tcpcopy是一种请求复制(基于tcp的packets)工具，其应用领域较广。tcpcopy主要有以下功能： 

• 分布式压力测试工具，利用在线数据，能够测试系统可以承受的压力大小,同时提早发现一些bug;

• 对于后端的短链接，请求丢失率很是低(1/10万)，能够应用于热备份;

• 普通上线测试，能够发现新系统是否稳定，提早发现上线过程当中会出现的诸多问题，让开发者有信心上线;

• 对比试验，一样请求，针对不一样或不一样版本程序，能够作性能对比等试验;

• 利用级联tcpcopy，构造无限在线压力，知足中小网站压力测试要求。

图1 tcpcopy工具流量复制过程

1. 在线服务器启动tcpcopy进程，在IP层捕获数据包，经过数据链路层发包;

2. 复制的包到了被测试服务器，通过协议栈的处理，到达应用进程，进程处理完，响应的包经过路由转发给辅助服务器;

3. 辅助服务器捕获到路由过来的响应包，去掉包的body，返回给在线服务器。

整个过程是一个闭环，引流的过程不会干扰用户的请求，复制的请求的响应，也不会返回给用户。

URS引流测试实践

接下来说述下tcpcopy是怎么在URS这个产品中运用起来的，经过下面的案例来分享下整个引流测试的过程。

案例：本人经历过一个项目主库的性能验证，优化及替换

背景介绍：

该产品的线上数据库服务器年限比较长，配置比较老，另外数据库服务器在瞬时访问量比较大的时候，会出现性能降低的问题。为了提升数据库服务器的稳定性，以及对数据库的参数进行一些优化，产品方计划采用新的数据库服务器来代替线上服务器，且在上线先进行一轮优化，保证新的数据库知足目前的性能需求的状况下，再替换掉线上的数据库。

测试的难点

1. 新数据库的数据量基本要和线上是一致的，不然测试的意义不大；

2. 仅仅依靠线下的请求模拟是不够的，须要线上真实的流量来验证；

3. 须要提供突发流量，高于线上的流量等场景来验证新的数据库服务器是否可以处理突发状况。、

测试方法

利用tcpcopy工具，搭建引流测试环境，利用线上真实流量，倍数流量，突发流量，验证新的163主库的性能，并与DBA协做，进行参数优化和验证。

测试成果

经过复制真实流量，有效验证了现有数据库的性能，而且经过调整流量，对数据库形成多样的负载，进而对数据库进行参数优化，保证了数据库的性能和稳定性

引流测试方案

为确保引流测试顺利实施，先制定一个详细的方案，方案主要包括业务选取，环境搭建，结果分析和验证等，接下来逐一介绍这些部分。

测试环境搭建

须要先根据线上环境部署架构来肯定咱们的引流测试环境应该搭建成什么样子。下面为引流环境架构示意图。先简单介绍下：

环境部署以下：

图2 测试环境部署

1. 线上Nginx服务器上安装部署tcpcopy，负责把指定的流量复制到测试环境；

2. 引流环境的数据库经过导入线上的数据库的备份初始化数据，同时经过作成线上的备库，保持和线上数据库的同步。每次要开展引流测试的时候，先剥离出来，作完测试以后再和线上数据库进行同步；

3. 为了不引流操做更新部分缓存，致使弄脏了线上的缓存数据，同时为了控制穿透到数据库的量，搭建了单独的缓存服务器集群；

4. 搭建mock服务器，把短信，邮件，将军令等服务都mock掉，避免触发到这些操做，影响用户，另外也能够经过在前端Nginx进行请求过滤，来屏蔽可能触发这些操做的请求。

引流业务选取及过滤

环境搭建好之后，须要肯定复制哪些请求到测试环境，如下三类请求是不建议引流的， 须要屏蔽掉。

1. 没法处理的请求
   测试环境由于缺乏数据或者缺乏外围系统等，致使这类请求在测试环境执行会报错，所以须要过滤掉。

2. 连续相关的请求，或者有状态的请求
   连续相关的请求由于存在状态，请求之间的数据有传递，致使复制过去的话，业务处理会报错，也须要过滤掉。举个简单的例子，好比登陆操做，服务端可能会须要填写验证码，复制过来的请求的验证码和原始的请求是不同的。若是登陆操做也复制过去了，验证码是无效的。

3. 写请求
   写请求会新增数据，且通常写请求的量比较小，请求大都有状态，不是很适合引流。若是写请求的影响很小，也须要进行写请求的测试，也能够进行复制，可是要特别注意，不要弄脏线上环境的数据，或者对线上的业务有影响。

请求过滤能够经过如下方式实现：

1. Nginx配置Location进行过滤

   location ~* ^/services/(otplogin|onlyotplogin|qrcodeotpauth|onlyotplogin|ticketotpauth) { expires -1; return 200 'request mocked\n'; }

   把须要屏蔽的请求，直接返回200。这里要通过仔细筛选。上面的配置只是一个示例，实际项目能够按照规则来过滤。 

2. 搭建mock服务器进行过滤 请求的处理过程当中，若是会调用第三方系统，这个时候能够搭建mock服务进行屏蔽。

引流测试执行

环境准备好以后，就能够执行引流测试了，引流测试过程会包含如下步骤：

配置检查

1. Nginx的Location配置，避免复制了不合适的请求到测试环境； 

2. 应用配置是否正确，一切会影响线上用户的配置都须要调整； 

3. 缓存服务器的配置是否正确，确认使用的是测试环境的实例，且能正常访问； 

4. 数据库的配置是否正确，确认使用的是测试数据库，且能正常访问； 

5. Mock服务器是否正常，服务的返回是否正常等； 

6. 以上检查完成后，在测试的Nginx上利用curl工具手动发送请求验证环境。

启动辅助服务器intercept

1. 启动命令

   sudo ./bin/intercept  -i 网卡  -F 'tcp and src host ${测试Nginx IP地址}  and src port  ${测试Nginx端口} ' -p  ${intercept的监听端口}  -d

   能够不指定监听端口使用默认的36524，若是要启动多个实例，端口是必须指定。启动后经过netstat –an | grep 监听端口，检查端口是否正常。

2. 检查error_intercept.log日志文件 检查文件有没error和fatal级别的错误信息。

3. 绑定在不一样的CPU上
   若是intercept进程的CPU使用率比较高，须要启动多个intercept而且绑定在不一样CPU上，能够经过执行 taskset -cp ${cpu $pid来设定，其中

   cpu为CPU的编号， 

   pid为intercept的进程号。

    

配置路由并验证

在测试环境的Nginx上增长默认网关，设置为intercept的地址： 命令：route add default gw ${intercept的IP} 设置好路由信息后，能够找一台测试机器，telnet测试环境Nginx的服务端口80，若是可以创建链接，说明路由信息没生效，测试环境Nginx服务器的包没有转发给辅助服务器，能够找SA的同事帮忙协助，肯定路由要怎么配置。

启动tcpcopy

在线上Nginx服务器，启动tcpcopy命令：

sudo bin/tcpcopy -F 'dst port ${线上nginx端口} and dst host ${线上nginx IP} '  -i  网卡 –x  ${线上nginx端口} -${测试环境nginx的IP}:{测试环境nginx端口} -s ${intercept的IP} -n 1 -d

启动后，检查error_tcpcopy.log日志文件有无error和fatal级别的错误。

请求验证

对线上nginx和测试nginx的日志进行对比，检查请求是否是已经复制到测试环境，请求返回的大小和状态码等是否正常，同时，检查应用服务器是否有错误日志。若是有错误，影响到了线上环境，或者错误不少，先中止引流，解决报错。 

系统监控

引流过程当中，能够利用哨兵系统对线上Nginx服务器，测试服务器的系统资源，应用服务器、数据库进行性能监控。

调整流量

引流过程当中，会根据测试环境的负载，调整复制的流量，经过修改tcpcopy的启动参数来调整。-n 设置复制的倍数，-r 能够设置复制的比例(1<r<100)。 

引流测试结果分析

前面的章节介绍了引流的方案和执行过程。引流开始后，咱们怎么去分析系统当前的性能呢？在数据库的性能验证的案例中，咱们一方面要知道当前的业务负载状况，同时也须要知道应用和数据库的各项资源的使用状况。

如何监控业务指标

业务性能指标，主要是经过对nginx的日志进行分析来完成，分析可以监控到全部请求，以及单个请求的TPS，错误，平均响应时间，最大响应时间4个重要的指标。 

图3 业务指标监控

例如在图3中，能够实时监控到***login这个接口的TPS，ERRORS，AVG_RT，MAX_RT四个指标。

如何监控数据库

数据库能够经过在相似于zabbix系统进行配置性能监控。引流过程当中，能够实时监控数据库的各项性能指标，观察是否有异常，进而调整复制的流量。 系统资源指标：CPU，内存，网络，磁盘等常规资源监控指标。 数据库性能指标：数据库各内存池使用率和命中率，Average active session，Database Time Ratio， 会话链接数，IO读写吞吐量，IO读写请求次数，执行次数，资源使用率等。
经过监控这些指标，定位数据库的性能瓶颈，让DBA进行优化和调整，再复测。找出最佳的配置。这些性能指标，咱们能够经过哨兵系统来实时监控。 

例如，咱们在引流过程当中监控到的链接数，活跃的会话，内存池的使用状况如图4所示：

图4 内存池大小的实时监控

图4是对内存池大小的实时监控，能够监控到PGA，buffer_cache内存，共享池内存，large_pool内存，java_pool内存的实时使用量。

图5 数据库的会话链接数的实时监控

案例结果分析

引流过程当中，经过调整流量，而且实时监控业务性能指标和数据库的各项指标是否正常。在业务性能指标，特别是响应时间在合理的范围内，数据库的各项性能指标也在合理的范围内，获得业务的TPS和数据库的负载状况，做为数据库性能评估的结果。

例如，在数据库的引流测试中，经过线上多台Nginx复制5倍的流量到引流环境，同时disable掉部分缓存，请求直接穿透到数据库，在这样的负载下，获得的数据库的性能数据以下:

 

链接数	QPS	sqlnet MB	largepool	sharepool	load	CPU	CS	Net IO
9600	3.5W	5MB	25G	15G 30%	4	sys 25% user15%	30K/s	10MB/S

 

 

本文章为做者原创

🈲禁止🈲

其余公众帐号转载，如有转载，请标明出处