① 测试开发技术(二)——压力测试
上一篇文章里说过，目前互联网公司的测试开发岗位分两类。多数的一类是既要负责业务测试、自动化测试，同时也要去开发测试框架、效率工具来辅助业务测试。这类测试开发的岗位（主要指后端的岗位）一般多少都要接触压力测试。
压力测试、性能测试、负载测试、稳定性测试在网络上有很多文章介绍概念和区别，通常在项目过程中不会区分那么多，实际项目中都是以目标为导向，通常实际项目中都会说，压测一下看下性能，所以这里就不管详细的概念和区别了。为了好理解，我们这里统一叫压测，并以得到性能数据为性能测试，以观察稳定性为稳定性测试。
性能测试和稳定性测试的相同之处在于都是使用压测工具来进行。但目标不同，性能测试是通过压力测试得到系统的极限亩或源性能或者和上一版本的性能对比数据。而稳定性测试则是通过压力测试提供稳定或者变化的持续流量，来观察系统持续运行的情况下是否存在异常。
正常情况下，一般系统先做性能测试，拿到极限性能或者性能对比数据（对于非1.0项目，性能数据一般需要和上一个版本对比）之后，再通过安全的流量持续压测更长时间，来完成稳定性的验证。
下面我们就具体介绍一下怎么做性能测试和稳定性测试。
性能测试的第一步要确定目标，就是为什么要做性能测试，要达到什么样的目标或者效果。比如某个首次上线的系统，性能测试主要是为了得到系统的极限性能数据；再比如，系统优化，更换了RPC协议或者消息队列，性能测试就是为了量化此次系统优化在性能上优化的效果。另外，也不是所有的项目都需要性能测试，比如一个内部系统，用户数和流量本身就很少，而且在未来一段时间也不会有增量，这就基本不需要性能测试。
如果是从无到有的1.0项目，因为项目还没有上线，所迅态以只能评经验来预估线上的流量数据；但如果是非1.0项目，就可以收集当前的线上数据。具体收集的数据如下（仅供参考，要按照实际情况来调整）：1）被测系统或模块各类请求流量比例；2）系统或模块目前平均、峰值、最小 qps；3）线上部署方式和规模；4）被测系统或模块依赖能承受的QPS或者容量。
确定目标和收集完线上现有数据之后，需要根据目标和现有数据确定压测方案，比如，每个阶段通过多大并发或者流量来压测、分几个阶段、每个阶段多长时间、以及压测过程中需要观察和记录哪些数据等。
同时，也要准备压测环境，压测的环境要尽可能的和线上一致，如果达不到，就做等比缩放。比如，一个系统有A、B两个模块组成，线上A部署了20台机器，B部署了5台机器，那么压测就可以A部署4台，B部署1台。机器和实例的数量只是一个方面，同时也要考虑机器的性能（CPU盒数、内存、磁盘、网卡等），还要考虑依赖方（如DB、缓存、消息队列等）的部署。部署压测环境的核心思路就是要用这套环境反应出线上环境的真实情况。
要进行压力测试就一定要有压测工具，一般来说压测http或者其他开源协议可以在网上找到现成的工具，比如jmater之类的。但如果场景比较特殊，或者使用的是公司或项目的私有协议，就只能使用公司内部的工具或者自己动手开发了。
选择好压测工具就要构造压测数据了。构造压测数据主要分两点：
第一点是要构造压测环境系统中的数据。因为线上系统内部一定是有一定数据的，我们要尽量模拟线上就要在系统中添加相应的数据。
另一点就是要准备压测的请求数据。这点跟选择的压测工具有关，一般来说分2种：
1）数据词典， 压测的请求提前准备好，存入文件、DB或缓存里，数据量较大的时候一般需要写程序生成。
2）实时生成，这种是压测工具在压测的时候根据配置规则来实时随机生成请求。
准备工作一切就绪，下一步就开始做压测的执行。这时候主要就是根据压测方案的从低到高去团历调整压测工具的并发数或请求数，来对目标系统或模块进行压测。
压测时，要观察CPU、内存、网络IO、磁盘空间、被压目标日志、依赖系统或者模块的状态等数，也要记录不同并发下目标系统或者模块处理请求的QPS和响应时间。同时也要注意有没有内存泄漏、句柄泄漏、系统崩溃等问题。
实际上部分数据在记录的过程中就可以初步整理出来。这里要针对上一步记录的数据，进行汇总，主要要产出在不同并发下，上面提到的数据都是什么情况。需要根据数据判断出极限性能，找到这种部署情况下瓶颈在哪，以及是什么原因造成的，为后续扩容提供依据。有些情况还需要跟以前的数据做对比，看性能提升或者下降的程度是不是符合预期。最后，把这些信息综合汇总、分析之后，产出性能测试的报告。
通常性能测试之后拿到了性能数据之后，都会在安全的并发或者流量下持续压测更长的时间来确保服务的稳定性。比如，笔者通常测试性能的时候，每轮可能压测半小时到一小时（在刚开始并发或者流量较小的时候可能会更短），在得到期限性能之后，会控制极限性能时80%-%90的流量或者并发去压测更长的时间，这个时间一般会比较长，而且多数情况下会在晚上下班前启动，然后第二天到公司来看结果。
除了长时间通过安全流量来验证外，有些时候在特殊场景下，也需要验证在安全流量范围内，流量急曾或者急降的情况下，稳定性是否有影响。或者，验证在一定流量下，模拟某个依赖或者系统内部的模块出现问题，执行相应预案时，对系统整体的影响是否符合预期。
当然，稳定性很多情况是异常，但更多的异常会在异常测试里去做，这里的稳定性测试是指在一定流量压力下的稳定性测试，其他的就不做讨论了。
上面介绍了压力测试里，性能测试和稳定性测试要做什么，那具体怎么做呢？下面我们就通过一个实例来简单介绍一下。
一个消息推送的系统，推送的消息就是我们日常手机APP的通知消息。这个消息通知的系统有三个接口，分别是单播（指定推送给某个人）、组播（推送给一个组，组里可能有多个人）、广播（推送给APP所有用户）。现在这个系统做了一个重构，更新了内部交互的RPC协议，所以要压一下，跟之前的性能数据做个对比。另外，系统重构前，线上集群极限性能为30000 QPS。
下面，我们就按照前面的步骤，来简单介绍一下具体怎么做。
目标就是要得到重构后的系统性能数据，并和原有的做对比，原有的极限性能已知，大概在30000 QPS左右。
收集线上数据，比如说我们收集到单播、组播、广播的请求比例为5：78：1；组内人数大概在300-1000；发送的消息字符数在30-100这个区间。
压测方案要先确定部署方案，比如这个系统向上是20台机器（或者实例），压测采用2台机器（等比缩放）。压测机器是线上的1/10，所以我们的目标性能就是3000qps。那么我们压测的方案就可以如下设置：
第一轮，2个并发，5-10分钟，主要目的是为了先验证环境和压测工具没有问题；
第二轮，根据上一轮并发数和机器资源（CPU、内存、IO）的情况，调整并发到极限的一半多一些（比如，之前是2个并发，CPU占用10%左右，内存、IO占用都很小，那么就以CPU的占用作为参考来计算，1个并发大概占用5%，那我们就可以吧并发调到10-12，目标CPU占用是50-60%）。这其实才真正开始压测，如果没问题，就开始逐步加压；
第三轮，开始逐步增加，按照实际情况一次增加2-5个并发，直到性能达到瓶颈。
这里是假设压测工具通过调整并发数来操作压力，主要需要看下并发对系统CPU、内存、IO的影响，根据压测时机器的资源占用信息来判断增加多少并发。
确定好方案，就需要部署压测环境了，这里要注意，尽量使用跟线上一致配置的机器。
压测工具要根据实际业务做选择，必要的时候需要自己开发，工具开发后面如果有机会在其他的文章里介绍，这里就不多介绍了。我们这个例子因为是系统更换内部协议，对外接口不变，所以可以使用原有压测工具。
下面就是要构造数据：
首先，要构造系统内部的数据，比如用户信息、设备信息、组信息，这里既要根据线上的收集到的信息来构造，比如用户数、组的数量、组内用户数等。这类如果方便的话可以直接在DB里插入，或者掉相应的系统API来准备。
然后就是压测的请求数据，比如说压测工具是用数据词典来压测，那么这里我们就通过脚本，来生成压测请求数据。这里要注意线上收集到的各个接口的占比，即5：78：1。压测的时候按照这个比例来提供流量。
准备工作完成，开始做压测。
这时候要先吧各类数据观察准备好，一般现在的互联网大厂都有图形化的工具来看，如果没有也可以通过linux的一些命令来看。常用的命令有top\ps\vmstat， 这里推荐使用top来查看实时的资源情况，使用vmstat的来定时输出当资源情况（vmstat -t 1 就是每秒输出一次）。
准备好了观测，那就启动压测工具，按照方案压测。压测方案上面已经介绍，这里就不重复了。
假如我们并发加到20个的时候，CPU占用达到85%左右，处理请求达到3600qps，其他资源占用都不足机器的一半；并发加到22个的时候，CPU占用达到95-100，处理请求是3700qps；并发加到24，CPU打满，处理请求3800QPS，并且出现错误日志。这时候就可以停止压测了。
数据整理，我们首先要整理一个表格或者图标，我们这里用表格：
这个表格就是压测产出的最核心的数据，由于CPU是明显的性能瓶颈，表格里就不体现其他资源了，如果其他资源使用率也比较高，也要放到这个表格里，又或者瓶颈在外部依赖，也要体现出来。通过这个数据可以看出，3700QPS就是系统处理的极限，安全的流量在3600QPS。这时候就可以用17-20的并发数，长时间压测压测一下，看看系统整体的稳定性。
那么性能报告怎么写呢？下面就给出一个比较简单的性能报告样例。
标题：消息推送RPC协议升级性能测试报告
一、项目背景
这里写项目背景和目标
二、压测环境
线上20台物理机，压测环境使用2台物理机，配置与线上一致，具体如下：
XX核，XXG内存，万兆网卡，硬盘 400G * 6 SSD
DB：XX主XX从XX备
三、压测方案和数据
1. 请求比例
单播：组播：广播 = 5：78：1
2. 压测过程数据
3. 资源占用图
可以把QPS和CPU占用使用工具（比如excel）生成一个折线图，另外，可以把其他资源数占用的数据图片贴一下。
四、结论
压测过程中，压力达到3700qp时，内存与IO正常，CPU占用达到98%，无错误日志。压力达到3800qps时CPU打满，且5分钟后开始出现错误日志。因此系统在2台物理机部署极限性能为3700qps，性能瓶颈在CPU，预计线上20台机器极限性能为37000qps.
系统RPC协议升级前20台机器30000qps，升级后预计能达到37000qps，性能整体提升23%，符合预期。
上面就是一个比较简单的报告，真实项目中瓶颈不一定是CPU，可能是其他资源，也可能是依赖的系统或者模块，这些都需要观察和分析压测中的数据来得出。
压力测试是后端测试和测试开发人员的必备技能，这篇文章只是根据笔者的经验针对压力测试进行的总结，不能覆盖所有压测场景，仅给大家做个参考。更多的是需要我们根据系统的实际情况去探索和实践。
② 如何使用MySQL自带的性能压力测试工具mysqlslap
使用--auto-generate-sql参数表示用mysqlslap工具自己生成的SQL脚本来测试并发弊返压力
mysqlslap --auto-generate-sql -uroot -p123456
并发测试，使用–concurrency来模拟并发连接，连接数可以多个，用逗号隔开
mysqlslap --auto-generate-sql --concurrency=100 -uroot -p123456
mysqlslap --auto-generate-sql --concurrency=50,100 -uroot -p123456
使用--iterations模拟迭代测试，用于需要多次执行测试得到平均值。
mysqlslap --auto-generate-sql --iterations=5 -uroot -p123456
使用--engine测试不同的存储引擎的性能进行对比
mysqlslap --auto-generate-sql --concurrency=50,100 --iterations=5 --engine=myisam,innodb -uroot -p123456
--query=name,-q 指定自定义脚本执行测试，例如可以调用自定义的一个存储过程或者租猛饥sql语句来执行测试。--create-schema 指定自定义的测试数据库名知吵称，
mysqlslap --auto-generate-sql --concurrency=50,100 --create-schema="landclash" --query="call landclash.sp_player_getname(34);" --number-of-queries=5000 -uroot -p123456
③ 性能测试到底该怎么做
作为一名开发者，我们最长听到的就是编程界的三高：
高性能、高并发、高可用。
听起来非常高大上，但是性能到底如何呢？又该如何评定呢？
这次我们谈一谈性能测试，看一看到底什么样才叫做高性能。
本文主要从以下几个方面进行讨论。
（1）性能测试是什么？
（2）为什么需要性能测试？
（3）性能测试如何做？
（4）有哪些性能测试的工具
老马曾经说过，你想理解一件事物，首先必须先定义它。
这里直接引用一下网络中的定义：
性能测试的定义也不难理解，往往定义本身阐述了性能测试的作用。
如果你是一名开发、测试，平时接手过不少需求，可能性能测试接触的也不多。
每一个需求，都有对应的功能性需求和肺功能性需求。
功能性需求是产品需求文档中最直接的，需要实现的功能目标。简称，能用就行。
非功能性需求则要宽泛的多，架构设计是否合理？是否便于后期拓展？是否便于监控？代码实现是否优雅？文档注释是否完整？
就像你写了弊谈一只鸟，鸟头做螺旋桨非能飞起来，但是在架构设计上可能是不合理的。
飞起来
一个查询功能，用户点击查询，10S 种才返回数据，功能上是满足的，但是性能上是不能接受的。
线上的交易功能平时各方面都很棒，节假日高峰期直接系统就瘫痪了。
那如何避免这些问题出现在生产上呢？
这就需要上线之前，首先做好对应的性能测试，避免再生产上出现问题，带来严重的生产事故。
性能要高，性能要硬，性能测试，又高又硬！
又高又硬
做一件事情之前，我们首先要确定好自己的目标。
性能测试，到底要测试什么？
有些类似于开发过程中的需求分析，常见的测试指标如下。
响应时间是指某个请求或操作从发出到接收到反馈所消耗的时间，包括应用服务器（客户端）处理时间、网络传输时间以及数据库服务器处理时间。
作为用户而言，在页面点击查询，等待了多久才能获取结果，这个就是响应时间。
用户不关心你后端经过了多少个服务，慢就是原罪。
对于微服务系统，链路监控就显得比较重要。可以帮助我们快速定位到底慢在哪里。
TPS（Transaction Per Second）是指单位时间（每秒）系统处理的事务量。
我看网上还有很多类似的概念：点击量/点击率、吞吐量/吞吐率、PV/UV，这里不做赘述。
个人看来本质上 TPS/QPS 就是去压测你应用的极限，当访问量较大的时候，程序能否活下来？
这里主要涉及到两个概念：高性能和高可用。
我们后面会简单讨论下这两点。
明确了测试指标之后，就需要进行测试的准备。
环境准备：比如你想压测数据库，那就需要准备对应配置的数据库资源。
脚本的准备：数据初始化脚本，调用脚本等。
这个可以类比开发过程中的代码开发。
ps: 性能压测一般不是很常用，所以环境准备流程会比较长，这一点需要注意。
当进行测试之后，测试的结果一定要给出一份报告出来。
是否通过压测要求？
最高的 QPS 是多少？
这样开发可以根据这份报告进行相应的优化。
提升性能的内容写一本书也不为过，这里简单罗列一些最常用的几点：
（1）慢 SQL
一般程序如果响应时间较长，可以首先看一下慢 SQL。
看下是否需要增加索引，或者进行 SQL 优化。
（2）缓存
针对查询，性能提升最显着的就是引入缓存。
当然，引入缓存会使架构变得复杂，这一点要结合自己的实际业务。
（3）硬件升级
如果程行磨序优化的空间比较小，可以考虑升级一下硬件资源。租带碰
比如服务器配置翻倍，数据库配置翻倍。
什么？你说公司没钱升级？
没钱升级做什么压测？
这个时候测试报告的作用就显露了，直接用数据说话。
直接说 QPS 达不到生产要求，程序优化的空间很小，推荐硬件升级配置，升级到多少。
做人，要以德服人。
做测试，要用数据说话。
以德服人
测试最常用的工具当属 jmeter。
除此之外，还有一些其他的工具：
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面对几个工具做下简单介绍
Apache JMeter 可以用于测试静态和动态资源(Web动态应用程序)的性能。
它可以用于模拟服务器、服务器组、网络或对象上的负载，以测试其强度或分析不同负载类型下的总体性能。
将负载测试集成到开发工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
从12.55版本开始，您可以运行您的JMeter脚本，并在任何性能测试中集成JMeter和附加的脚本类型。
ps: 这个设计理念就非常好，可以和成熟的工具进行整合。站在巨人的肩膀上。
QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。
QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试，并针对所发现问题对系统性能进行优化，确保应用的成功部署。
ps: 这个工具本人没有接触过。
SilkPerformerV可以让你在使用前，就能够预测企业电子商务环境的行为—不受电子商务应用规模和复杂性影响。
可视化的用户化、负载条件下可视化的内容校验、实时的性能监视和强大的管理报告可以帮助您迅速将问题隔离，这样，通过最小化测试周期、优化性能以及确保可伸缩性，加快了投入市场的时间，并保证了系统的可靠性。
作为 DevOps 方法的一部分，IBM Rational Performance Tester 帮助软件测试团队更早、更频繁地进行测试。
它验证 Web 和服务器应用程序的可扩展性，确定系统性能瓶颈的存在和原因，并减少负载测试。
您的软件测试团队可以快速执行性能测试，分析负载对应用程序的影响。
ps: 这一款工具有 IBM 提供，质量值得信赖。
这么多工具可供使用，相信读到这里的小伙伴已经找到了自己心仪的测试工具。
别急，下面专门为做 java 开发的小伙伴们推荐一款性能测试工具。
男人有男人的浪漫，开发者当然也要有开发者的浪漫。
【男人的浪.jpg】
作为一名开发者，老马平时单元测试使用 junit 最多。
所以一直希望找到一款基于 junit 的性能压测工具，后来也确实找到了。
@JunitPerfConfig 指定测试时的属性配置。(必填项)
使用如下：
@JunitPerfRequire 指定测试时需要达到的要求。(选填项)
使用如下：
对应的测试报告生成方式也是多样的，也允许用户自定义。
基于控台日志：
或者基于 HTML:
junitperf
本文对性能测试做了最基本的介绍，让小伙伴们对性能压测有一个最基本的理解。
测试和开发一样，都是一件费时费力，而且需要认真做才能做好的事情，其中的学问不是一篇就能说清的。
性能测试工具也比较多，本文重点介绍了专门为 java 开发者打造的 junitperf 工具。
下一节我们将从源码角度，讲解一下 junitperf 的实现原理。
我是老马，期待与你的下次重逢。
开源地址：https://github.com/houbb/junitperf
④ 如何用Jmeter做压力测试
在“服务器名称或ip”设置127.0.0.1，端口号设置:8080，“方法”设置post，路径设置网站登录的地址，如“/exam/operatorAction”。
登录需传入用户、密码。在“同请求一起发送参数”列表中添加参数。参数值根据web应用设置。如login_user=0001;login_password=1;actFlag=login。
一般网站登录后，在tomcat中生成了session，之后访问其他页面将无需再次登录悉腊，前提是浏览器需支持cookie。在jmap中也同样，如要继续访问其他页面，还需做下面关键的设置。
Apache JMeter
是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。 它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI 脚本、Java 对象、数睁余滑据库、FTP服务器， 等等。JMeter 可以用于对服务器、网络或对毁芹象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。
⑤ 压测工具JMeter的使用
性能压测工具，在我们项目开发过程中肯定免不了要经常使用，来检测我们完成的接口或者整举哪体服务的抗压水平。Apache提供了个 ab 命令，可以进行压测功能，只不过功能相对简单，有时候很难满足我们的测试需求。
所以，这里介绍下Apache的另一款压测工具 JMeter，它是Apache组织开发的开源项目，设计之初是用于做性能测试的，同时它在实现对各种接口的调用方 面做的比较成熟，因此，常被用做接口功能测试和性能测试。
本次压测模拟的流程是：请求先访问登录接口，成功后通过返回信息拿到用户ID，再将用户ID作为参数访问商品下单的接口。压力测试规则是每秒1000的并发请求，执行1次，也就是执行1s。
PS：下方涉及到的三个变量 NAME、PASSWORD、USER_ID 它们是需要用 {} 来包裹的，我下边写错了，写成了 () 包裹郑简的了。哈哈，我实在是懒得挨个截图改了，在这里说明下，明白原喊答裤理就好
⑥ 性能测试工具 wrk 使用教程
被面试官经常问到之前开发的系统接口 QPS 能达到多少，经常给不出一个数值，支支吾吾，导致整体面试效果降低？
原因基本是一些公司中，做完功能测试就完了，压根不会有性能测试这一步，或者说并发量较少，没有必要进行性能测液指试，亦或者，交给测试人员后，只要整体问题不大，测试报告一般也是不会再给后端人员看的，这就导致我们在面试的时候，场面一度尴尬 ！！！
其实，不单单是针对面试，作为一名后端开发者，我们在完成一个接口开发后，在交给测试工程师之前，经常也会想知道，自己写的这个接口的性能如何呢？吞吐量能达到多少？QPS（Query per second 每秒处理完的请求数） 能达到多少呢？
这个时候，我们就需要借助一些常用的性能测试工具，如 Apache ab, Apache JMeter (互联网公司用的较多)，LoadRunner 等消燃。
我们今天主要说一说轻量级性能测试工具 wrk 。
一、什么是 wrk
二、 wrk 的优势&劣势
三、wrk 安装
四、如何使用
五、总结
六、参考文档
七、赠送面试&学习福利资源
摘自官方 GitHub 上的英文介绍：
翻译一下：
wrk 是一款针对 Http 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。
在说 wrk 的优势之前，瞅一下 wrk 的 GitHub Star 数，也能侧面反映下它的可靠性：
Wow ! 截止笔者截图为止, Star 数已经达到了 19742 !!!
再来说说 wrk 的优势：
wrk 目前仅支持单机压测，后续也不太可能支持多机器对目标机压测，因为它本身的定位，并不是用来取代 JMeter, LoadRunner 等专业的测试工具，wrk 提供的功能，对我们后端开发人员来说，应付日常接口性能验证还是比较友好的。
wrk 只能被安装在类 Unix 系统上，所以我们需要一个 Linux 或者 MacOS 环境。Windows 10 安装需要开启自带的 Ubuntu 子系统。
依次执行如下命令：
依次执行如下命令：
Mac 系统也可以通过先编译的方式来安装，但是更推荐使用 brew 的方式来安装, 步骤如下：
Windown 10 需要在 Windows 功能 里勾选 适用于 Linux 的 Windows 子系统 , 然后通过 bash 命令切换到 Ubuntu 子系统。接下来，参考 3.1.1 Ubuntu 的操作系通中，安装 wrk 的步骤。
命令行中输入命令：
输出如上信息，说明安装成功了！
安装成功了，要如何使用呢？
这条命令表示，利用 wrk 对 www..com 发起压力测试，线程数为 12，模拟 400 个并发请求，持续 30 秒。
除了上面简单示例中使用到的子命令参数，拿埋虚 wrk 还有其他更丰富的功能，命令行中输入 wrk --help , 可以看到支持以下子命令：
翻译一下：
执行压测命令:
执行上面的压测命令，30 秒压测过后，生成如下压测报告：
我们来具体说一说，报告中各项指标都代表什么意思：
可以看到，压测报告还是非常直观的！
您可能有疑问了，你这种进行 GET 请求还凑合，我想进行 POST 请求咋办？而且我想每次的请求参数都不一样，用来模拟用户使用的实际场景，又要怎么弄呢？
对于这种需求，我们可以通过编写 Lua 脚本的方式，在运行压测命令时，通过参数 --script 来指定 Lua 脚本，来满足个性化需求。
wrk 支持在三个阶段对压测进行个性化，分别是启动阶段、运行阶段和结束阶段。每个测试线程，都拥有独立的Lua 运行环境。
启动阶段:
在脚本文件中实现 setup 方法，wrk 就会在测试线程已经初始化，但还没有启动的时候调用该方法。wrk会为每一个测试线程调用一次 setup 方法，并传入代表测试线程的对象 thread 作为参数。setup 方法中可操作该 thread 对象，获取信息、存储信息、甚至关闭该线程。
运行阶段：
结束阶段：
done() 方法在整个测试过程中只会被调用一次，我们可以从给定的参数中，获取压测结果，生成定制化的测试报告。
自定义 Lua 脚本中可访问的变量以及方法：
变量：wrk
以上定义了一个 table 类型的全局变量，修改该 wrk 变量，会影响所有请求。
方法：
上面三个方法解释如下：
调用 POST 接口：
注意: wrk 是个全局变量，这里对其做了修改，使得所有请求都使用 POST 的方式，并指定了 body 和 Content-Type头。
自定义每次请求的参数：
在 request 方法中，随机生成 1~10000000 之间的 uid，并动态生成请求 URL.
每次请求前，延迟 10ms:
请求的接口需要先进行认证，获取 token 后，才能发起请求，咋办？
上面的脚本表示，在 token 为空的情况下，先请求 /auth 接口来认证，获取 token, 拿到 token 以后，将 token 放置到请求头中，再请求真正需要压测的 /test 接口。
压测支持 HTTP pipeline 的服务：
通过在 init 方法中将三个 HTTP请求拼接在一起，实现每次发送三个请求，以使用 HTTP pipeline。
本文中，我们学习了轻量级性能测试工具 wrk, 如何安装，以及具体的使用方法，包括通过 Lua 脚本来个性化定制请求等。希望读完本文，能对您有所帮助哦！