性能测试工具 性能测试工具之 Gatling

王华 · April 11, 2018 · Last by 王华 replied at April 12, 2018 · 4674 hits

性能测试需求:

公司内部有一个类似于钉钉的App,每周五使用这个App写周报,我们公司一共4000人,要求周五下午5.30之前写完,写一扁日志大概需要半小时,在写日志时有自动保存的功能,每隔30s去服务器保存一次,考虑到大家可能会集中在一个时间段内发日志,对服务器可能会产生比较大的压力,因此需要做一下性能压测;

4000人写日报,暂且估算1个人写半小时,那么一个人会向服务器端请求60次,所以这4000人向服务器一共请求的次数是: 60*4000=240000 ,大家集中写日报的时间在下午4点半到5点半,折算成秒 60*60=3600s , 则在这一小时内平均每秒的压力是240000/3600=66.6 , 当然这个算法是很不准确的,肯定会有峰值和波谷,所以我们需要测出服务器的最大承受压力是多少 ,再拿最大承受压力和这个值作比较,如果远远大于这个数值,就不需要去做优化,如果小于或者接近这个值需要去找开发做优化;

下面开始讲解如何编写性能测试脚本:

参考文档: https://gatling.io/docs/current/

具体案例参考: https://gatling.io/docs/current/quickstart/

脚本:
/**

  • Copyright 2011-2017 GatlingCorp (http://gatling.io) *
  • Licensed under the Apache License, Version 2.0 (the "License");
  • you may not use this file except in compliance with the License.
  • You may obtain a copy of the License at *
  • http://www.apache.org/licenses/LICENSE-2.0 *
  • Unless required by applicable law or agreed to in writing, software
  • distributed under the License is distributed on an "AS IS" BASIS,
  • WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  • See the License for the specific language governing permissions and
  • limitations under the License. */ package computerdatabase

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
import io.gatling.core.scenario.Simulation

class JubanSimulation extends Simulation {

val httpConf = http.baseURL("http://xxx.com") // 这里填写被压测接口所请求的域名
.acceptHeader("application/json") // Here are the common headers

.userAgentHeader("WorkPlusForAlog/415 CFNetwork/894 Darwin/17.4.0")
val scn = scenario("JubanSimulation").during(15){// A scenario is a chain of requests and pauses

exec(http("request_1111")
.post("/api/v1/daily/saveDaily?access_token=38f8c6552ae44f268b9fe2ea05fe2a65")
.body(RawFileBody("request_token.json")) // request_token.json 是这个接口请求的参数,这个文件放在/Users/XXX/gatling-charts-highcharts-bundle-2.2.4/user-files/bodies 路径下,参照下面截图

.asJSON
)
// .pause(5)
}

setUp(
scn.inject(rampUsers(100) over(100 seconds) // 这里加压方式为在100秒内,持续加压直至并发数为100个虚拟用户数
).protocols(httpConf))
}

我的加压方式为:
第一次: 第一次在100秒内,并发数为100 scn.inject(rampUsers(100) over(100 seconds)
第二次: 第二次在100秒内,并发数为200 scn.inject(rampUsers(200) over(100 seconds)

第一次的测试结果如下:


先看后面2张图,我们选择一个响应数最高点进行分析,比如选在17:43:05 这个点进行分析 ,再看图一在这个点的表现,95%的请求都在89ms以内

第二次的测试结果如下:


先看后面2张图,我们同样选择一个响应数最高点进行分析,比如在17:58:57 ,再看图一这个点的表现,95%的请求都在118ms以内
由此可以得出结论,加压100 和 加压200,系统返回的响应数最多是230左右,可得出结论系统的最大并发在230左右,而随着压力增大,请求响应时间增长,app端的表现为越加压,速度越慢; 由于我们压测的最大并发是230远远大于预测数67 ,则此次可不做优化;

共收到 4 条回复 时间 点赞

感觉楼主有点太乐观了,对于这种场景,根据20/80定律,大部分人会选择在最后的几分钟内提交,峰值请求可能会达到均值的6,7倍。
而且测试的并发量和时间都不够,可以用500并发跑一个小时,再分析结果。

在可接受的响应时长内,才有峰值可言。先定好条件

王华 #3 · April 12, 2018 作者
arrow 回复

谢谢楼主的建议,确实需要跑更长的时间,这个确实存在性能压力,已经和开发PK,每隔30s保存到服务器改成保存到本地,所以就没有去压那么长时间,更注重的是对报表结果分析,gatling报表分析找了很多资料,没有详细讲解,还希望大家多多交流!

王华 #4 · April 12, 2018 作者
vball 回复

理论上一个接口的响应时间不超过200ms,是可以满足条件的

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up