Gatling实用技术

----高性能轻量级压力测试工具

项目背景

开发部门需要压力测试，但依赖QA的压力测试组不够便捷，因为其行动周期较长（业务讲解，计划制定，脚本匹配，文档撰写....），另外QA组使用的工具也比较专业，如果让开发部门自己用也不那么轻便。否能找到一种方法，让开发人员跑一跑压力测试呢（在专业的QA压力测试组介入以前）？

本文档适用对象

n 有一定编程基础的开发人员

n 对应用性能有很高要求的开发团队

本文不适合的对象

n 希望所有功能均由图形界面完成的使用者

本文阅读时间

1~2小时,建议分部阅读，中间安排充足的时间实验。

1 Gatling简介

Gatling的Scala基础封装是基于Akka编程的，它是非阻塞异步编程模型，可以高效执行并有极高的容错率。

n 专用web测试。

n 像LR那样录制脚本，不用从零开始。

n 脚本使用scala语言，易懂，易修改，控制灵活。

n 基于JVM，随拷随用。（对比LoadRunner的客户端安装以及JMeter需要XWindow组件，这个方便很多），操作接近apache的ab。

n 原生支持NIO，并发性能很好，即使性能较差的电脑也能发起很大的负载压力。

n 基于HTML的报表，简单易读。

2 Gatling入门

2.1准备工作

2.1.1下载

        下载地址：https://github.com/excilys/gatling/wiki/Downloads

jdk6对应1.5版本，jdk7以上对应2.0版本。

本文档使用1.5.2版本进行演示。

2.1.2配置环境变量

           需要配置好JAVA_HOME和 GATLING_HOME环境变量，后者指向Gatling的根目录。

2.1.3 Gatling目录结构

2.1.4Recorder.bat和gatling.bat

 Recorder.bat和gatling.bat一个用来录脚本，一个用来执行脚本。它们也提供了linux版本.sh。

Recorder是个桥接在浏览器和web服务器之间的代理，如果浏览器通过它访问网络时，它能记下浏览器的访问轨迹。 Reocrder提供了UI界面，让配置和执行变得简单。 同时，Recoder也是一个scala代码的生成器，它能把访问轨迹记录成scala代码。

Gatling.bat是一个包含了编译，执行scala代码的脚本，它提供了一些参数供使用者指定执行的细节（比如JVM_OPTS）,运行它可以选择需要执行的scala代码，创建非阻塞的线程模型执行压力测试。 

2.2录制一个脚本

2.2.1启动Recorder

        执行{Gatling目录}/bin/recorder.bat|.sh，会启动一个图形控制界面，同时在后台启动了一个代理服务器。

配置浏览器，令浏览器通过这个代理服务器访问互联网，则一切操作都会被其记录。

2.2.2浏览器指向Recorder代理

启动Recorder之后，已经在本机的8000和8001上启动了代理，接下来我们配置一下浏览器，让它通过Recorder的代理访问网络。

配置好以后，当Recorder关闭时，浏览器无法访问任何网站，证明配置成功。当脚本记录工作结束之后，别忘了改回无代理的状态，否则只要recorder一关，浏览器就不能访问互联网了。

笔者建议，如果经常录压力测试脚本，可以单独安装一个不常用的浏览器专用，比如chrom。

2.2.3录制脚本

录制以前，启动待测试的应用服务器，本文用grails搭了一个简单的web应用程序，跑在localhost：8080/teset/，然后打开浏览器，切换到Recorder点击start，回到浏览器访问地址，切回Recorder点击stop&save，这样就完成了一次录制。

2.2.4脚本保存位置

录制完成的脚本放在了这里，路径根据Recorder的Output folder指定，重名情况下会覆盖旧文件。如果录制的文件多了，可以考虑将这个文件夹弄到svn上去，以防万一。

2.3编辑脚本

2.3.1脚本内容分解

我们打开刚才录好的RecordedSimulation.scala，

看到内容定义，我们只关注httpConf，scn这两个对象就够了。

观察相同颜色的箭头，其功能脚本内容一目了然“用httpConf当做访问协议，用scn描述访若干问地址和暂停时间，用scn.users描述并发个数，执行访问。” 

当然，所举的例子很简单。而一个完整的操作流程至少包含“登陆验证，操作，退出”。 在实际的录制过程中，读者可能会发现录制完的脚本中有很多杂乱的请求，这是因为网页中的css，js等资源也是通过请求获取，凡是请求都会被记录到脚本，形成了像“杂音”一样的内容。

我们可以在编辑脚本时，适当删除它们。因为很多这类请求消耗的是缓存服务器的性能，而大说数情况我们更关注应用服务器。

2.3.2编程思路

ü 将用户的操作，分解成多个“get”和“post”请求。

ü 定义每个请求对应的参数变量。

ü 缓存请求返回的值，如需要作为下次请求的参数。

ü 使用“scn.users”属性，模拟多用户多线程。

可以阅读Gatling提供的演示脚本BasicExampleSimulation.scala，看看怎样给每个请求指定不同的header，每个请求指定不同参数，感受编程带来的灵活性。读者可能会感受到，Galting其实是个编程类库，提供了各种发送网络请求的基础类。

2.4运行压力测试

2.4.1编程思路

执行{Gatling路径}\bin\gatling.bat|.sh -sf <脚本路径>。这时屏幕开始输出日志，观察负载应用服务器的日志，会发现正在处理批量的请求。

执行完毕之后，在此录下会产生报告文档，直接访问index.html即可阅读。

 压力测试的结果，分为GLOBAL和DETAILS两栏，分别对平均分数和每组请求的分数做了统计。我们重点参考Request/sec（每秒处理请求个数）和Transactions/sec（每秒处理事务个数，事务即每个模拟用户的一组请求）      

更详细的测试报告说明，请参考官网https://github.com/excilys/gatling/wiki/Reports

2.4.1注意事项

l 发送端与负载端的网络环境与带宽

Galting作为发送端发起大量的请求，是很消耗网络带宽的。如果开发机与应用服务器之间有带宽限制，则不应将发起端放在开发机，而应该放在负载端同机架的服务器，确保发起端有足够的带宽输出请求。

考虑Galting本身会占用内存和CPU去发起请求和接收请求，所以Galting不应该与负载端同使用一台服务器，或者共享硬件资源的两个虚拟机。

l 负载压力

根据脚本所定制的并发数，Galting需要占用内存去生成对象。请根据情况，调整Galting的配置文件，将更多内存分配给Galting的JVM，让其有足够的内存去发起请求。

3Gatling提高

3.1测试计划

请在着手录制脚本以前，仔细制定一个计划，磨刀不误砍柴工。

比如制定多级压力，逐级测试，找到应用的极限。

3.2活用scala，实现功能型测试

          scala代码可以实现任何控制逻辑。比如http类提供了一个check()