性能测试需求：

公司内部有一个类似于钉钉的 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 ，则此次可不做优化；