性能测试需求:

公司内部有一个类似于钉钉的 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/

脚本:
/**

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 ,则此次可不做优化;


↙↙↙阅读原文可查看相关链接,并与作者交流