Gatling是一款基于Scala 开发的高性能服务器性能测试工具，它主要用于对服务器进行负载等测试，并分析和测量服务器的各种性能指标。Gatling主要用于测量基于HTTP的服务器，比如Web应用程序，RESTful服务等，除此之外它拥有以下特点：
Gatling适用的场景包括：测试需求经常改变，测试脚本需要经常维护；测试环境的客户机性能不强，但又希望发挥硬件的极限性能；能对测试脚本进行很好的版本管理，并通过CI进行持续的性能测试；希望测试结果轻量易读等。
JMeter是目前使用最为广泛的服务器性能测试工具之一，它最大的特点就是拥有一套简单易用的GUI，但它最大的缺点也是由于简单易用导致它某些方面的不足，比如测试脚本（XML）不容易维护等。Gatling正是针对JMeter的劣势做了大量改进，因此相较于 JMeter，Gatling拥有以下优势：
在并发性能方面，Gatling使用了Akka Actors和Async IO, 而JMeter则采用了一个用户使用一个线程的方式 ，一旦并发线程过多，性能就急速下降，很难充分发挥硬件的能力。虽然两个工具都是基于JVM的，但是Actors模型的性能在高并发的情况下性能大大优于Threads，从而使得Gatling在更少的内存和CPU的情况下可以提供同样的测试能力，降低了测试成本。图1和图2分别展现了二者在并发性能方面的表现。
其中图1和图2分别是JMeter和Gatling在300个用户并发下的测试结果。可以很明显的看出，JMeter的并发量在300上下波动，最高达到400，最低达到200，而Gatling几乎稳定在300。由此可见Gatling性能的稳定性。
在测试脚本方面，Gatling是Scala代码，而JMeter主要是XML代码。Gatling基于一套开源的Gatling DSL API，所以它的功能很容易扩展，也不需要使用者精通Scala语言。DSL的使用也更容易编写出简明，易读性和维护性高的代码，而且还可以使用版本工具进行更有效的管理。因为性能测试应该属于系统发布流程中必不可少的一个步骤，所以测试脚本应该和系统代码一样使用版本工具进行统一管理。
在报表系统上，Gatling提供了一套轻量并且十分友好的Html报表系统，使得用户可以更为快速而方便地查看和分析数据，相反，JMeter的报表系统却十分笨重，且使用也不方便。
三，如何在项目中使用Gatling
对于Gatling这样一个全新的服务器性能测试工具，是否能将它很好的运用到项目中并发挥其优势，这个是一个困扰测试决策者的问题。下面我将结合在一个真实项目中使用和部署Gatling的经验来解答这个问题。
搭建测试环境
在一个大型的Web项目中，测试环境的搭建是项目测试工作开始的第一步，也是最为关键的一步，因为测试环境直接影响到测试成本和测试结果。由于这个项目对于性能的要求并不是很高，我们经过讨论和分析，决定选取虚拟机作为测试平台。这就意味着被测系统以及测试客户端可以使用的硬件资源比如CPU和内存十分有限，因此需要测试工具能充分使用有限的资源发挥最大的性能。
进行负载测试
为了快速实现测试脚本，我首先选择了使用Gatling录制功能进行脚本录制，成功录制以后会在指定的“Output folder”目录下面生成你指定“Class Name”为名字的脚本，见图3。
图3，Gatling Recorder
根据图3的配置，录制好的脚本存放在/Users/twer/work/gatling/user-files/simulations/Common/MyRecordedSimulation.scala。生成的部分脚本代码如下：
class MyRecordedSimulation extends Simulation { val httpProtocol = http .baseURL("http:// :10.17.7.3") .acceptHeader("image/png,image/*;q=0.8,*/*;q=0.5") .acceptEncodingHeader("gzip, deflate") .acceptLanguageHeader("en-US,en;q=0.5") .connection("keep-alive") .userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Firefox/22.0") val headers_1 = Map( """Accept""" -> """text/html,application/xhtml+xml,application/xml;q=0.9, */*;q=0.8""", """If-None-Match""" -> """"a3ef335152d5532e2297bd8ad288f3f9"""") |
录制代码段1
.exec(http("request_21") .get("""/customer/images/new?app_dialog=true&dialog=true""") .headers(headers_18)) .pause(6) .exec(http("request_22") .get("""/customer/images?_=1374400463122""") .headers(headers_19)) .pause(165 milliseconds) .exec(http("request_23") .get("""/Users/twer/work/gatling/user-files/simulations/testdata/test1. png""") .headers(headers_20) .check(status.is(500))) .pause(2) .exec(http("request_24") .get("""/customer/images?view=list""")) .pause(86 milliseconds) …… setUp(scn.inject(atOnce(1 user))).protocols(httpProtocol) |
录制代码段2
录制出来的脚本拥有很多局限性：
只支持1个用户
没有检测点
没有逻辑分层
因此，它并不能用于真正的性能测试。对于这样的原始代码，我们需要进行大量的重构，使代码拥有很好的可读性和可维护性。
首先我们要进行分层处理：
对于录制代码段1，需要建立一个Header类来管理所有HTTP Header，这里使用“Headers.scala”，在录制代码段1中只给出了“headers_1”，实际的脚本包含了大量的Header。
对于录制代码段2，需要将测试场景和测试控制分开，每一个测试场景使用一个文件来保存，代码段2所示的场景使用“UploadImageScenario.scala”来保存。主控脚本也需要分离出来存入“MainSimulation.scala”，通过调用不同的测试场景的脚本，从而可以复用HTTP的配置选项，比如：
val httpProtocol = http
.baseURL("http:// :10.17.7.3")
其次，我们还需要增加多用户的支持：
多用户数据的读入，其中“user_credentials.csv”存储的就是用户名和密码
.feed(csv("user_credentials.csv")) .exec(http("request_login") .post("""/customer/login""") .param("""username""", """${username}""") .param("""password", "${password}""") |
设置多用户的值。由于我们使用的是虚拟机，所以经过测试，确定为400用户并发。
setUp(LoginScenario.loginScn.inject(ramp(400 users) over(60 seconds))).
protocols(httpProtocol)
最后，我们还要增加检测点，使用check，find，status等函数进行检测，下面的代码检测了用户登出的时候HTTP Response Status是否为302：
exec(http("request_logout")
.get(("""/customer/logout""")
.headers(headers_logout)
.check(status.is(302)))
当然，如果测试人员熟悉Gatling DSL API，我们也可以不用录制代码再进行重构，而是直接设计测试系统并进行测试案例的开发。
项目采取了敏捷方法进行开发，所以系统的一些功能在开发过程中会出现频繁改动，导致测试场景和测试脚本也会随之发生改变，因此，测试脚本的可读性和可维护性对于我们来说就非常重要。当某个功能改变之后，使用Gatling脚本就能十分方便的进行阅读和重构。比如对于添加user的功能，第一版只需要能添加user即可（见添加user代码1），而在下一版中，则要求在添加user时可以选择该user具有那些权限（见添加user代码2），代码如下：
.exec(http("request_add_user") .post("""/customer/users""") .headers(headers_user) .param("""utf8""", """?""") .param("""user[username]""", """user2""") .param("""user[email]""", """user@gmail.com""") .param("""user[password]""", """user2""") .param("""user[password_confirmation]""", """user2""") |
添加user代码1
.exec(http("request_add_user") .post("""/customer/users""") .headers(headers_user) .param("""utf8""", """?""") .param("""user[username]""", """user2""") .param("""user[email]""", """user@gmail.com""") .param("""user[password]""", """user2""") .param("""user[password_confirmation]""", """user2""") .param("""user[plugins][]""", """customer_dashboard""") .param("""user[plugins][]""", """customer_files""") .param("""user[plugins][]""", """customer_images""") .param("""user[plugins][]""", """customer_pages""")) |
添加user代码2
项目发布后，若项目功能发生改变，我们也可以使用Gatling进行持续的性能回归测试，保证系统性能不会因为某次修改导致非预期的降低。如果降低了，就要进行及时的调查，修复或者是调整，保证性能一直在预期的可控范围内。
测试报表
Gatling测试报表基于HTML，并且在测试过程中业已生成，所以打开速度很快。而且，当把鼠标移动到不同数据轴上时，都会有弹出框显示这个点上详细的测试数据信息。这种动态显示数据的方式非常方便查看和分析数据。考虑到项目真实数据的不便，我将通过Gatling官方网站给出的示例报表进行说明。
Gatling的报表分为两类：GLOBAL和DETAILS，其中GLOBAL主要是请求相关的统计数据，比如每秒请求数，请求成功与失败数等；其中DETAILS主要是请求时间相关的统计数据，比如请求响应时间，请求响应延迟时间等。
图4 每秒请求数
当鼠标放到图中任何一个点的时候，对应时间点上请求的详细数据就会以图中白色的弹出框的方式进行显示。在下面的请求响应延迟时间图里面也有同样的功能。
图5 请求响应延迟时间
3，与CI的集成
项目的CI系统选用的是Jenkins，因为Jenkins有Gatling的插件，所以通过这个插件可以在Jenkins上直接查看Gatling的测试结果，如图6所示。
图6 Jenkins Gatling插件
我们还把生成的报表存档到每个Build里面，这样就可以在每个Build中获得那次测试的所有报表。
更多类型的测试
其他类型的HTTP服务器性能测试，比如瞬间压力测试，耐久性测试等，都十分适合使用Gatling。
四，未来的Gatling
Gatling发布的时间虽然不长，但凭借其优良的性能，DSL模式的脚本，轻量友好的报表系统在众多服务器性能测试工具中脱颖而出。在2013年5月发布的ThoughtWorks技术雷达中，Gatling被列入了ADOPT，并在一些ThoughtWorks项目中得到了实际的运用。不过，Gatling还是存在一些问题，比如不支持分布式模型；默认只支持HTTP，对于其他协议需要自己动手进行扩展；报表种类也不是很丰富 。倘若Gatling 能在这几方面有所突破，那么它必将成为新一代服务器性能测试工具中的杀手锏。