2021-03-30
JMeter功能
一、BS架构应用性能
二、HTTP协议接口功能与性能
三、FTP协议接口功能与性能
四、Mysql数据库性能
五、MongDB数据库性能
六、支持自定义java组件开发
JMeter结构图
目录结构
- backups目录：备份jmx脚本
- bin目录：可执行文件,jmeter.bat启动
- docs目录：API文档目录，二次开发用
- extras目录：扩展插件目录，目录下的文件提供了ant支持
- lib目录：所用到的插件目录，里面全是jar包，用户扩展所依赖的包直接放到lib下即可
- lib/ext子目录：jmeter核心jar包
- printable_docs/usermanual子目录：jmeter 用户手册，其中component_reference.html是最常用的核心元件帮助手册；
jmeter的一般做哪些性能测试？
-
==并发测试：主要是使用同步计时器（设置并发数），同步计时器主要有两个参数
模拟用户的数量：并发数
超时时间(ms)：设置等待时间，如果0则永久等待，直到满足模拟的用户数。非0，则等待指定时间，如果在时间内，则满足条件就释放，否则超时释放。
在线程组中设置对应的线程数
添加HTTP请求元件，配置需要测试的接口
添加聚合报告元件：查看压测结果 -
==稳定性测试：主要测试持续一段时间访问接口，测试接口的稳定性。
主要涉及的配置为，线程组设置循环次数永久，持续时间设置为15分钟（根据自己的项目要求而定）
必要的时候，添加统一随机定时器元件：主要有两个参数
随机的最大时间（ms）：在这个范围内进行随机
常量延时时间（ms）：固定的延时时间
最后的延时时间=随机的时间+常量延时时间
业务场景测试：主要测试多个接口联动，模拟真实接口的调用，增加统一随机定时器模拟用户真实操作
比如添加购物的流程涉及到：登录接口–搜索商品接口–浏览商品接口–添加到购物车接口
其中主要最难的是：登录接口提交的验证码处理，我之前的项目是开发给定了一个固定的万能验证，进行提交登录，添加HTTP Cookie管理器（用于自动保存登录之后的信息，下面的请求就可以使用同一个登录状态进行访问：https://blog.csdn.net/baidu_39372836/article/details/91442231）。
使用事务控制器元件（https://blog.csdn.net/baidu_39372836/article/details/99445618）进行管理这些接口，这些接口就属于一个事务流程，只要一个测试失败，则事务通过失败。 -
==负载测试：主要测试一个接口或者一个业务场景的支持量，主要用到了一个扩展组件：bzm - Concurrency Thread Group（https://blog.csdn.net/baidu_39372836/article/details/99622449），通过逐步加压的方式，查看每个阶段的响应数据，简单的确认出负载数。该组件也可以用于测试并发量，和同步计时器使用，好处是，能够逐步增大并发数，避免因为客户机硬件的原因（比如：一下子生成1000线程数，可能会导致客户机CPU过高，影响并发数）导致并发数的不准确。
JMeter主要元件
整体流程:
我们测试的时候，通常是创建一个线程组，指定并发的线程数量，然后指定要测试的接口，创建相应的监听器，比如表格结果，结果树和聚合报告信息，通过监听器来监听测试是否通过或者接口是否存在什么问题
其中在结果树中可以监测到整体的请求信息，就拿 Http 请求这种来讲，其实就是整个 http 协议的所有信息，包括请求头，请求参数，请求路径，还有响应头，响应结果等信息。 对于表格查看结果，可以看到每个请求的简单信息，本次请求的时间，以及平均的时间。
在聚合报告中，我们就可以看到整体的信息了。比如可以看到平均响应时间，90%Line 也就是 90%的用户请求低于的时间。还有吞吐量 TPS，还有错误率，还有用流量来计算的吞吐量。这些都可以看到。通常，聚合报告就是反应整体的数据。
Jmeter 参数化:
做压力测试时，我们经常需要替换参数，在 Jmeter 中，有多种参数化的形式。可以在测试计划中设置全局参数，可以设置用户参数，还可以在前置处理器中设置用户参数。
在进行多线程并发的时候，如果需要多个参数，可以使用 csv 配置元件。比如做登陆操作，后台有可能会限制一个用户不能重复登陆多次，如果演示登陆的并发操作，可以使用 Jmeter 中 csv 配置元件，将用户信息导出来，放到文件中，就可以让线程共享这些数据。另外，对于一些随机变化的参数，可以使用 Jmeter 中的函数助手，生成随机函数，进行参数化测试。比如注册这样的操作，用户名要求唯一的，那就可以使用随机函数来模拟出来。
线程组
性能测试需要模拟大量用户负载的情况，线程组就是用来完成这个工作的，在此元件中我们可以设置运行的线程数（就是模拟多少用户，一线程一用户)。线程组的设置十分简单，除了设置线程数以外，还可以设置运行时长，定时运行等。
另外第三方插件（JMeter Plugin)的扩展也让JMeter 的场景设计更加丰富。
steup线程组:
第一个运行的(不管怎么放位置)
线程组:
teardown线程组:
环境清除
非测试原件(原来的工作台)
1、配置元件
性能测试中为了模拟大量用户操作我们往往需要做参数化，Jmeter 的参数化可以通过配置元件来完成，比如 CSV Data Set Config，它可以帮助我们从文件中读取测试数据。
另外JMeter也提供了众多的函数（通过函数助手可以查看到，后续会讲到）来帮我们生成动态数据。当然配置元件的作用不仅于此，它还可以用来记录服务器的返回数据，
2、定时器
（具有LR的Think_time功能）
用于操作之间设置等待时间，等待时间是性能测试中常用的控制客户端QPS的手段。
1、固定定时器
(Constant Timer)
如果你需要让每个线程在请求之前按相同的指定时间停顿，那么可以使用这个定时器；需要注意的是，固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间。
对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing(两次迭代之间的间隔时间)；
对于“事务控制器”来说，定时器相当于loadrunner中的think time(思考时间：实际操作中，模拟真实用户在操作过程中的等待时间)。
这里附上一个传送门，对loadrunner中的pacing和think time有比较全面的解释：https://zhidao.baidu.com/question/1431215934913423459.html
我们通常说的响应时间，应该大部分情况下是针对某一个具体的sampler(http请求)，而不是针对一组sampler组合的事务
2、高斯随机定时器
(Gaussian Random Timer)
如需要每个线程在请求前按随机时间停顿，那么使用这个定时器，上图表示暂停时间会分布在100到400之间，计算公式参考：Math.abs((this.random.nextGaussian() * 300) + 100)
传送门(什么是高斯随机分布)：https://zhidao.baidu.com/question/89318504.html
3、均匀随机定时器
(Uniform Random Timer)
和高斯随机定时器的作用差异不大，区别在于延时时间在指定范围内且每个时间的取值概率相同，每个时间间隔都有相同的概率发生，总的延迟时间就是随机值和偏移值之和。
下面表示的是随机延迟时间的最大值是100毫秒：
(1)Random Delay Maximum(in milliseconds):随机延迟时间的最大毫秒数
(2)Constant Delay Offset(in milliseconds):暂停的毫秒数减去随机延迟的毫秒数
4、固定吞吐量定时器
(Constant Throughput Timer)
可以让JMeter以指定数字的吞吐量(即指定TPS，只是这里要求指定每分钟的执行数，而不是每秒)执行。
吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组等范围，并且计算吞吐量的依据可以是最近一次线程的执行时延。这种定时器在特定的场景下，还是很有用的。
5、同步定时器
(Synchronizing Timer)
这个定时器和loadrunner当中的集合点(rendezvous point)作用相似，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力(人多力量大- -哈哈！)
(1)Number of Simulated Users to Group by:模拟用户的数量，即指定同时释放的线程数数量
(2)Timeout in milliseconds:超时时间，即超时多少毫秒后同时释放指定的线程数
6、BeanShell定时器
(BeanShell Timer)
这个定时器，一般情况下用不到，但它可以说是最强大的，因为可以自己变成实现想要做的任何事情，例如：希望在每个线程执行完等待一下，或者希望在某个变量达到指定值的时候等待一下。
这里给大家介绍下BeanShell：
BeanShell是一种松散类型的脚本语言(这点和JS类似)，一种完全符合java语法的java脚本语言，并且又拥有自己的一些语法和方法。
传送门(另外一位博客园作者的博客)：http://www.cnblogs.com/jssy/archive/2006/10/23/537101.html
7、泊松随机定时器
(Poisson Random Timer)
这个定时器在每个线程请求之前按随机的时间停顿，大部分的时间间隔出现在一个特定的值，总的延迟就是泊松分布值和偏移值之和。
上面表示暂停时间会分布在100到400毫秒之间：
(1)Lambda(in milliseconds):兰布达值
(2)Constant Delay Offset(in milliseconds):暂停的毫秒数减去随机延迟的毫秒数
传送门(什么是泊松随机数)：http://baike.baidu.com/link?url=CJ0_Qtuilzp3a4Xos9N7V_hFQjaf_zb_aM1wggqxIYGDGWjtKsp6JSjRIQ110lE38sQOKYcgNUMjRuMAPGb3xK
8、JSR223定时器
(JSR223 Timer)
在jemter最新的版本中，新增了这个定时器，可以这么理解，这个定时器相当于BeanShell定时器的“父集”，它可以使用java、JavaScript、beanshell等多种语言去实现你希望完成的事情；
我们都知道jemter是一种开源的纯java工具，可以自己构件各个组件，jar包去完成各种事情。
传送门(关于JSR223)：http://wenku.baidu.com/link?url=GUFnww9nb_1D6MlFd1YksYrNVk1NXF74ov8kJL06MmqVdmH_Q9v4YnWK-_gZ-04zL4QEqD9VN48OrXi4JyXpxosNZd8LBfIWhyhhxgUbrAC
9、BSF定时器
(BSF Timer)
BSF Timer，也是jmeter新的版本中新增的定时器，其使用方法和JSR223 Timer很相似，只需要在jmeter的lib文件夹导入其jar包，就可以支持脚本语言直接访问Java对象和方法的一定时器。
有了它 , 你就能在java application中使用javascript, Python, XSLT, Perl, tcl, ……等一大堆scripting language. 反过来也可以；
就是在这些scripting language中调用任何已经注册过了的JavaBean,java object。它提供了完整的API实现通过Java访问脚本语言的引擎。
由于本人对java了解不深，只能通过查阅相关资料，简单描述下其作用，不足之处，希望指正。
传送门(BSF)：http://baike.baidu.com/link?url=0RRkO1WqT1SdaXIzohqnEU8lcilpc_Sqwy7HtfpzCdCX1kyyLC5qttpF8jayTWFZi_tCbFbzMEw8FxHFYnIGYK
3、前置处理器
在测试脚本开发过程中，我们在请求发送前可能会做一些环境或者参数的准备工作，那么我们可以在前置处理器中来完成这些工作。比如，我们在对数据库进行操作前需要先建立一个数据库连接，那么前置处理器就可以完成这个功能。
HTTP URL重写修饰符
HTTP用户参数修饰符
HTML链接解析器
BeanShell PreProcessor
4、后置处理器
后置处理器一般放在取样器之后，用来处理服务器的返回结果，比如一个 Web应用程序，我们登录后会返回一个SessionID，这个 SessionID在登录之后的业务操作过程中会作为验证条件，验证用户是否合法登录了。
我们利用取样器模拟这个请求时就需要带上这个属性，那么如何获取呢?首先我们要知道这个SessionID 从哪里来?它是由服务器返回的。接着我们要获取它，用什么工具获取呢?JMeter帮我们提供了元件，比如正则表达式提取器，它支持正则表达式的方式来提取数据。
后置处理器就是专门用来对响应数据做处理的元件，大家可能听说过关联这个名词，JMeter的关联就是通过后置处理器来完成的。
5、断言
（具有类似于LR中的检查点功能）
用于检查测试中得到的响应数据是否符合预期。断言一般用来设置检查点，验证测试过程中的数据交互是否与预期一致。
6、监听器
（具有类似于LR中的日志功能）
用来对测试结果数据进行处理和可视化显示的一系列原件。图形结果、查看结果树、聚合报告等都是比较常用的原件。
聚合报告:
- Label：每个请求的名称，比如HTTP请求等
- #Samples：发给服务器的请求数量（如图是200个请求，若模拟100个用户，循环10次，请求数是1000）
- Average：单个请求的平均响应时间。默认是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间
- Median：中位数，也就是50%用户的响应时间
- 90%Line：90%用户的响应时间
- 95%Line：95%用户的响应时间
- 99%Line：99%用户的响应时间
- Min：最小的响应时间
- Max：最大的响应时间
- Error%：错误率，本次测试中出现错误的请求的数量/请求的总数
- Throughput：吞吐量。默认情况下表示每秒完成的请求数，吞吐量=请求数/总时间
- Received KB/sec：每秒从服务器端接收到的数据量，即：收到的千字节每秒的吞吐量测试
- Sent KB/sec：每秒从客户端发送的请求的数量，即：发送的千字节每秒的吞吐量测试
用表格察看结果
- Sample#：编号类似id
- Start Time：开始时间
- Thread Name：线程名称
- Label：请求名称
- Sample Time：取样时间ms
- Status：状态
- Bytes：接受字节数
- Sent Bytes：发送字节数
- Latency：等待时间
- Connect Time：链接时间
7、取样器–Sampler
取样器（又译采样器，个人习惯用取样器这个名字）用来模拟用户操作，向服务器（被测试系统）发出Http请求、WebService (SOAP/XML-RPC Request）请求或者Java请求等。
我们可以把 Http请求元件看成是一个没有界面的浏览器，它可以发送 Http 请求，接收服务器的响应数据。
8、逻辑控制器
逻辑控制器的作用域只对其子节点的sampler有效，作用是控制采样器的执行顺序。
分为两类元件：一类用于控制Test Plan中Sampler节点发送请求的逻辑顺序控制器，常用的有 如果(If)控制器、Swirch Controller、Runtime Controller、循环控制器等。
另一类用来对Test Plan中的脚本进行分组，方便Jmeter统计执行结果以及脚本运行时的控制。如事务控制器、吞吐量控制器等。
元件的执行顺序
1、配置元件（Config Elements）
2、前置处理器（Pro-processors）
3、定时器（Timers）
4、取样器（Sampler）
5、后置处理器（Post-processors）
6、断言（Assertions）
7、监听器（Listeners）
需注意事项：
a)前置处理器、后置处理器和断言等元件功能对取样器作用。因此，如果在它们的作用域内没有任何取样器，则不会被执行；
b)如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序依次执行。
tips：同一层级的元件，按顺序执行；
压测常识
1、性能测试的工作流程
2、性能测试的类别
·负载测试：
通过逐步加压的方法，达到既定的性能阈值的目标，阈值的设定应是小于某个值，如cpu使用率小于等于80%。
·压力测试：
通过逐步加压的方法，使得系统的某些资源达到饱和，甚至失效的状态，简单粗暴的解释就是什么条件能把系统压崩溃。
·并发测试：
在同一时间內，多个虚拟用户在同时访问同一个模块，同一个功能，通常的测试方法就是设置集合点。
·容量测试：
通常是指数据库层面的，目标是获取数据库的最佳容量能力。又称为容量预估。具体测试方法为在一定的并发用户，不同的技术数据量下，观察数据库的处理能力，即获取数据库的各项性能指标。
·可靠性测试：
又称为稳定性测试或疲劳测试。是指系统在高压情况下，长时间的运行是否稳定。
如cpu使用率在80%以上，7*24小时的运行，系统是否稳定。
·异常测试：
又称为失败测试。是指系统架构方面的测试，如在负载均衡中，要测试宕机，节点挂掉等情况的系统反映。
3、性能指标的定义
·事物
从客户端发起的一个请求或多个请求(这些请求组成一个完成的操作)，到客户端收到服务器返回的响应。
·请求响应时间
客户端发起的一个请求开始，到客户端接收从服务器返回的响应，整个过程所耗费的时间。
·事物响应时间
事务可能是一个或者多个请求组成的，事物响应时间主要针对于用户的角度而言，如转账。
·并发
没有严格意义上的并发。并发总有先后，无论差距是1毫秒还是1微秒，总有一个时间差。所以并发讲的是一个时间范围内，比如1S内。
举例：
1、多用户在系统上进行同一操作，比如双11，大家针对同一种商品进行秒杀。
2、多用户在系统上进行不同操作，比如双11，大家针对不同商品进行秒杀，或者大家有进行其他操作，比如商品浏览。
并发用户数：同一单位时间内，对系统发起请求的用户数量。
吞吐量：一次性能测试过程中网络上传输数据量的总和。
2
服务器性能测试范围
1、CPU
2、内存
3、磁盘
4、网络
5、版本
6、性能损耗的计算方式
怎么计算性能损耗？(相同的指标，相同的场景，相同的用户并发数进行多次同样的压测)
3
脚本编写
可以直接用Jmeter的接口案列进行压测—需设置好线程数、循环次数、持续时间和吞吐量控制器(准备好这4大件，就可以开启性能压测之旅了)。
性能指标分析
没有经过初始化的性能环境= 没有
名词
QPS/每秒查询率
每秒查询率
TPS/事务数/秒
事务数/秒
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
RT/响应时间
响应时间
指应用执行一个操作所需的时间，包括从发出请求开始到最后收到响应所需要的时间。拿我们平常浏览网站点击链接为例，响应时间大致包括如下几步：
- 用户通过鼠标或键盘发出请求操作
- 浏览器构造请求（请求头，请求体）
- 用户计算机向网站服务器发送HTTP请求
- 服务器处理请求
- 业务逻辑
- 数据库访问
- 服务器构造响应（响应头，响应体）
- 服务器向用户计算机发送HTTP响应
- 浏览器解析响应中的信息，渲染页面
- 用户通过屏幕看到响应信息
并发数
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
吞吐量
QPS/TPS
查询量/每秒事务数
系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。
- QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
- 并发数： 系统同时处理的request/事务数
- 响应时间： 一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
- QPS（TPS）= 并发数/平均响应时间
- 并发数 = QPS*平均响应时间
性能指标
主要看三个指标，三个指标独立
（1）吞吐量，QPS/TPS，每秒服务器能处理的请求数。这个指标衡量服务器的性能。
（2）并发用户数U，合适的U=QPS×T，并发数太多会影响吞吐量。线程之间的切换耗时等
（3）响应时间T，用户的感觉
举例1：一个餐厅10张单人桌子，那么就是最多能够接待10个客人。每个客人愿意等待无限长的时间，只有一个厨师，10分钟做完一个客人的菜。那这个里面的指标：吞吐量就是10人，并发1个客人，响应时间最长是10*10=100分钟
规划服务器常常使用:(1)(3)指标去计划多少台机器。不可使用并发用户数去衡量，并发用户数只能看看服务器能够同一时刻多少人在处理。一个服务器最多支持多少并发用户数呢
需求1：60s，1万人抢红包，要求每个请求必须在10s内响应。测试知道单个请求代码单核执行时间是200ms。请问需要部署几台单核服务器？
规划：QPS=1万人/60s=166人/s，响应时间T=10s，并发用户数=166人/s×10s=1660. 服务器台数=QPS×200ms=166/sx0.2s=33台。
带宽：1万人×1KB/60s=1.2兆。
二、硬件分析指标
基础硬件指标：
CPU和内存：top命令 http://man.linuxde.net/top
磁盘：iotop https://www.cnblogs.com/xiangsikai/p/8305030.html
网络流量：nethogs http://blog.csdn.net/monkeynote/article/details/45867803
网络连接：netstat http://blog.csdn.net/he_jian1/article/details/40787269
内存中jvm的内存区域分析。方法区是JVM规范，永久代和元空间是hotspot它的实现。
内存查看见：jstat https://www.cnblogs.com/lizhonghua34/p/7307139.html
聚合报告
Label：
每个请求的名称，比如HTTP请求等
#Samples：
发给服务器的请求数量（如图是200个请求，若模拟100个用户，循环10次，请求数是1000）
Average：
单个请求的平均响应时间。默认是单个Request的平均响应时间，当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间
Median：
中位数，也就是50%用户的响应时间
90%Line：
90%用户的响应时间
95%Line：
95%用户的响应时间
99%Line：
99%用户的响应时间
Min：
最小的响应时间
Max：
最大的响应时间
Error%：
错误率，本次测试中出现错误的请求的数量/请求的总数
Throughput：
吞吐量。默认情况下表示每秒完成的请求数，吞吐量=请求数/总时间
Received KB/sec：
每秒从服务器端接收到的数据量，即：收到的千字节每秒的吞吐量测试
Sent KB/sec：
每秒从客户端发送的请求的数量，即：发送的千字节每秒的吞吐量测试
JTL结果分析
time
timeStamp 请求发出的绝对时间
elapsed 相应时间
label 请求的标签
responseCode 返回码
responseMessage 返回消息
threadName 请求所属的线程
dataType 数据类型
success 是否成功
failureMessage 失败信息
bytes 字节
Latency 相应时间
HTML报告指数
APDEX(Application Performance Index)指数
计算每笔交易APDEX的容忍和满足阈值基于可配置的值，范围在 0-1 之间，1表示达到所有用户均满意。
statistics（数据分析）聚合报告
类似于UI上的Aggregate Report
Label： # Sample采样器名称
Samples：# 总共发送请求数(线程数 * 循环次数)
KO： # 失败次数
Error%： # 请求失败率
Average：# 平均响应时间
Min： # 最小响应时间
Max： # 最大响应时间
90%Line：# 90%线，90%用户响应不超过该时间
95%Line：# 95%线，95%用户响应不超过该时间
99%Line：# 99%线，99%用户响应不超过该时间
Throughput： # 吞吐量，一般情况下可看做每秒完成请求数(和QPS类似)
Received： # 每秒从服务器端接收到的数据量
Sent： # 每秒从客户端发送的请求的数量
Errors报告
展示不同错误类型的数量以及百分比
响应时间变化曲线
展示平均响应时间随时间变化情况
类似于JMeter Plugins在UI上的jp@gc - Response Times Over Time
数据吞吐量时间曲线
展示每秒数据吞吐量随时间变化的情况
类似于JMeter Plugins在UI上的jp@gc - Bytes Throughput Over Time
Latency time变化曲线
展示Latency time随时间变化的情况
类似于JMeter Plugins在UI上的jp@gc - Response Latencies Over Time
每秒点击数曲线
类似于JMeter Plugins在UI上的jp@gc - Hits per Second
HTTP状态码时间分布曲线
展示响应状态码随时间的分布情况
类似于JMeter Plugins在UI上的jp@gc - Response Codes per Second
事务吞吐量时间曲线(TPS)
展示每秒处理的事务数随时间变化情况
类似于JMeter Plugins在UI上的jp@gc - Transactions per Second
平均响应时间与每秒请求数的关系图
展示平均响应时间与每秒请求数(可以理解为QPS)的关系
Latency time与每秒请求数的关系图
展示Latency time与每秒请求数的关系
响应时间百分位图
响应时间的百分位分布图
活动线程数变化曲线
展示测试过程中活动线程数随时间变化情况
平均响应时间与线程数的关系图
展示平均响应时间与线程数的关系
类似于JMeter Plugins在UI上的jp@gc - Response Times vs Threads
柱状响应时间分布图
展示落在各个平均响应时间区间的请求数情况
接口文档内容
内容
接口规范内容
- 接口名称
- 场景说明
- 接口说明
- 请求参数
- 响应参数
- 错误码
参数内容
字段名
变量名
是否必填
类型
示例值
描述
错误码内容
名称
描述
原因
解决方案
指标分析
响应时间：
对请求做出相应所需要的的时间,
对于一个Web系统，普遍接受的响应时间标准为2/5/8秒。
2秒钟之内响应客户是非常好的
5秒钟之内响应客户是可以接受的8秒钟是客户能接受的响应的上限。
假设我们把响应时间分为如下几段：
用户通过客户端向服务端发出请求的时间为： T1
服务端接收到请求，处理该请求的时间为：T2
服务端返回数据给客户端时间为： T3
客户端接收到响应数据，处理数据呈现给用户时间为：T4
从系统视角来看：
系统的响应时间Ts= T1+T2+T3。该时间没有包括客户端对数据处理并呈现的时间T4
从用户视角来看：
用户眼中的的响应时间：Tu = T1+T2+T3+T4。用户通过客户端发出业务请求，到客户端展现相应的请求结果，这个过程的时间越短越好
从服务器视角来看：
服务器接收到客户端发送的请求，并给出响应，这个过程所消耗的时间为响应时间，即服务器仅关注T2
从不同的视角下，衡量响应时间的指标也各不相同。在实际测试过程中，要明确以什么视角验证被测对象的性能。
大多数情况下，我们用jmeter做性能测试的响应时间都以用户视角去看待。
吞吐量：
我们用单位时间内系统处理请求的数量来定义它。
吞吐量直接体现了软件系统的业务处理能力
衡量方式如下几种：
请求数 / 单位时间
点击数 / 单位时间
字节数 / 单位时间
jmeter在聚合报告中把吞吐量命名为Throughput
这里要说两个概念，TPS和QPS
TPS：Transactions Per Second（每秒处理的事物数）。一个事务是指向服务器发送请求然后服务器做出反应的过程
QPS：每秒查询率。它是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
那么我们对于一个页面做一次访问，就会形成一个TPS；但一次页面访问，可能产生多次对服务器的请求，服务器对这些请求，计为“QPS“。
如果访问一个页面会请求服务器3次，那么一次访问产生一个“T”，产生3个“Q”
我们可以用jmeter做一个实验，用一个线程组模拟一个用户去访问一下腾讯新闻首页。那么这一个事物就是一个TPS
观察聚合报告里面的Throughput=7.6/s
它表示这一个线程在一秒内向服务器发送了7.6次请求，此时的Throughput可以理解为QPS。也就是一个TPS产生了7.6个QPS
但是如果我们在这一个请求上挂一个事物控制器，如下所示
此时在聚合报告中，Throughput就不可以和QPS划等号了，而是等同于TPS，它表示我们的系统每秒钟能处理3.4个事物
再比如下图。从登录到退出中间的一系列流程如果都挂在事物控制器下，那么它们整体就可以算做一个事物。TPS就表示每秒钟这一整个流程的处理数量
例：1分钟内系统可以处理1000次考勤打卡事物，则吞吐量TPS=1000/60=16.7 (次/秒)
如下图，则表示系统每秒钟能处理7次请求
并发数（线程数）：
广义
单位时间内同时发送给服务器的请求数，不限定具体业务类型，强调的是同时发送
狭义
是单位时间内同时发送给服务器的相同的业务请求数，需限定具体的业务类型，强调业务请求相同
服务端视角
并发数为单位时间内服务端接收到的请求数
客户端视角
客户端的某个具体业务行为包括多个请求，并发数可被理解为客户端单位时间内同时发送给服务器端的请求数
用户视角
客户端的业务请求一般为用户操作行为，并发数也可理解为并发用户数，又可称为虚拟用户数
平均并发用户的计算:
CLI 模式(非GUI命令)
什么是 CLI 模式
- CLI = Common Line，命令行模式，我们常说的 NON GUI 模式，无界面模式
- 真正做负载测试时，应该使用 CLI 模式运行，而不是 GUI
官方也说了
负载测试不要用 GUI 模式，GUI模式仅用于创建测试计划和调试脚本
增加 Java 堆空间来满足你的测试环境（后面再讲解）
CLI 模式可选参数
-n 指定 JMeter 将在 cli 模式下运行
-t 包含测试计划的 jmx 文件名称
-l 记录测试结果的 jtl 文件名称
-j 记录 Jmeter 运行日志的文件名称
-g 输出报告文件（ .csv 文件）
-e 生成 html 格式的测试报表
-o 生成测试报表的文件夹 文件夹不存在或为空
CLI 模式服务器相关参数
-H 代理服务器的 host 或 ip
-P 代理服务器的 port
-r 指定所有远程服务器中运行测试
-R 在指定的远程服务器中运行测试
-X 服务器运行完脚本后自动停止 jmeter-server
属性参数
Java 系统属性和 JMeter 属性可以直接通过以下命令进行覆盖，而不用手动修改 jmeter.properties
-D[prop_name]=[value] 定义一个 Java 系统属性值
-J[prop_name]=[value] 定义本地 JMeter 属性
-G[prop_name]=[value] 定义要发送到所有远程服务器的 JMeter 属性
-G[propertyfile] 定义一个包含 JMeter 属性的文件，该文件将发送到所有远程服务器
-L[category]=[priority] 覆盖日志记录设置，将特定类别设置为给定的优先级,设置根日志记录级别
例子
# 执行 FlaskDemo.jmx 脚本
# 在 result 目录下生成 report.jtl 报告
# 最后在 report 目录下生成测试报表文件夹
# 切记： report.jtl 必须不存在， report 目录必须不存在或者为空
jmeter -n -t FlaskDemo.jmx -l result/report.jtl -e -o report
# 将 .jtl 文件转换为 .html 文件，并保存到 report 文件夹中
# 类似栗子二，只不过跳过了执行 .jmx 文件的步骤，直接将 .jtl 文件转换为 .html 文件
jmeter -g report.jtl -o report
# 启动所有远程 slave 机执行 FlaskDemo.jmx ，并在 result 目录下生成 report.jtl
jmeter -n -t FlaskDemo.jmx -r -l result/report.jtl
# 启动指定的远程 slave 机执行 FlaskDemo.jmx ，并在 result 目录下生成 report.jtl
# 和 -r 不一样， -R 是指定slave机的，并不是所有 slave 机
jmeter -n -t FlaskDemo.jmx -l result/report.jtl -R 172.20.72:38:1234,127.0.0.1:1234
导出测试报告(非GUI模式)
# 基本命令格式：
jmeter -n -t （test JMX file） -l （test log file） -e -o （Path to output folder）
# test JMX file 表示测试脚本jmx文件的路径
# test log file 为测试日志（结果）文件路径
# path to output folder 输出的测试报告保存路径
#样例：
jmeter -n -t G:\apache-jmeter-5.1.1\bin\察看结果树.jmx -l testLogFile -e -o ./output
-n: 非GUI模式执行JMeter
-t: 执行测试文件所在的位置
-l: 指定生成测试结果的保存文件，jtl文件格式
-e: 测试结束后，生成测试报告
-o: 指定测试报告的存放位置
# 例子:CMD中输入(需要配置环境变量)
jmeter -n -t C:\Users\askbd\Desktop\JMeterTest\Test1111.jmx -l .\report.jtl -e -o C:\Users\askbd\Desktop\JMeterTest\report
压力测试报告模板
模板
JMeter测试计划要素
- 脚本中测试计划职能有一个
- 测试计划中至少要有一个线程组 4
- 至少要有一个取样器
- 至少要有一个监听器
JMeter实现分布式并发
Master在jmeter.properties中添加remote_hosts
Slave在jmeter.properties中添加server_port
Slave启动jmeter-server
JMeter配置解析
Database URL:
jdbc:mysql://localhost:3306/jmeter_class?serverTimezone=GMT%2B8
jdbc:mysql://localhost:3306/jmeter_class?serverTimezone=GMT%2B8&useSSL=false
jdbc:mysql://localhost:3306/jmeter_classserverTimezone=UTC&autoReconnect=true&failOverReadOnly=false
JMeter开发性能测试脚本及执行
- 步骤:
- JDBC Connection Configuration配置mysql配置
- JDBC Request写sql脚本
- 重点:
1.监控部署好
2.速度很慢的慢查询
3.sql语句是否合理
4.数据库架构是否合理
多协议接口性能测试
HTTP协议接口性能测试
JMeter扩展组件开发
扩展开发实现的两种方式
-
继承AbstractJavaSamplerClient抽象类(extends AbstractJavaSamplerClient)
-
实现JavaSamplerClient接口：执行顺序(implements JavaSamplerClient)
扩展组件开发-自定义函数
- 继承 extends AbstractFunction
大数据实时数据处理架构
Flume
高可用的，可靠的，分布式海量日志采集、聚合和传输的系统
kafka
是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据
卡夫卡术语
Broker :
Kafka集群包含一个或多个服务器，这种服务器被称为broker
Topic:
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
Partition :
物理上的概念，每个Topic包含一个或多个Partitiopn.
Producer :
负责发布消息到Kafka broker
Consumer :
消息消费者，向Kafka broker读取消息的客户端。
Consumer Group :
每个Consumer属于一个特定的ConsumerGroup
命令
# 启动zookeeper
bin/zookeeper-server-start.sh start
# 启动kafka
bin/kafka-server-start.sh config/server.properties&
# 查看topic :
./kafka-topics.sh --list --zookeeper localhost:2181
# 创建topic :
bin/kafka-topics.sh --create --zookeeperlocalhost:2181 --replication-factor 2 --partitions 4 --topitopic1
# partitions 指定topic分区数
# replication-factor 指定topic每个分区的副本数
# 生产者:
./kafka-console-producer.sh --broker-listlocalhost:9092 --topic topic1
# 消费者:
./kafka-console-consumer.sh --zookeeperlocalhost:2181 --from-beginning --topic topici
Storm
是一种分布式，实时的数据处理框架，延时时长为毫秒级，而Spark Streaming为秒级，是目前最适用于流式数据处理，最好的框架之一。
HTTP协议中GET与POST的区别
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark，而POST不可以。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求只能进行url编码，而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST么有。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- GET参数通过URL传递，POST放在Request body中。
GET和POST是什么？HTTP协议中的两种发送请求的方法。
HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
HTTP协议状态码
2开头（请求成功）
表示成功处理了请求的状态代码
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。
3开头 （请求被重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
。
4开头 （请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
· 401.1 - 登录失败。
· 401.2 - 服务器配置导致登录失败。
· 401.3 - 由于 ACL 对资源的限制而未获得授权。
· 401.4 - 筛选器授权失败。
· 401.5 - ISAPI/CGI 应用程序授权失败。
· 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
403 （禁止） 服务器拒绝请求。
· 403.1 - 执行访问被禁止。
· 403.2 - 读访问被禁止。
· 403.3 - 写访问被禁止。
· 403.4 - 要求 SSL。
· 403.5 - 要求 SSL 128。
· 403.6 - IP 地址被拒绝。
· 403.7 - 要求客户端证书。
· 403.8 - 站点访问被拒绝。
· 403.9 - 用户数过多。
· 403.10 - 配置无效。
· 403.11 - 密码更改。
· 403.12 - 拒绝访问映射表。
· 403.13 - 客户端证书被吊销。
· 403.14 - 拒绝目录列表。
· 403.15 - 超出客户端访问许可。
· 403.16 - 客户端证书不受信任或无效。
· 403.17 - 客户端证书已过期或尚未生效。
· 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
· 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
· 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
404 （未找到） 服务器找不到请求的网页。
· 404.0 -（无） – 没有找到文件或目录。
· 404.1 - 无法在所请求的端口上访问 Web 站点。
· 404.2 - Web 服务扩展锁定策略阻止本请求。
· 404.3 - MIME 映射策略阻止本请求。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。
5开头（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
· 500 - Internal Server Error 服务器遇到了意料不到的情况，不能完成客户的请求。
· 500.12 - 应用程序正忙于在 Web 服务器上重新启动。
· 500.13 - Web 服务器太忙。
· 500.15 - 不允许直接请求 Global.asa。
· 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
· 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
· 500.100 - 内部 ASP 错误。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
常见的数据库驱动
JDBC Request之Query Type
1、Select statement
这是一个查询语句类型；如果JDBC Request中的Query内容为一条查询语句，则选择这种类型。
2、Update statement
这是一个更新语句类型（包含insert和update）；如果JDBC Request中的Query内容为一条更新语句，则选择这种类型。
3、Callable statement
这是一个可调用语句类型，CallableStatement 为所有的 DBMS 提供了一种以标准形式调用已储存过程的方法。
Datbases中末尾添加 &allowMultiQueries=true
4、Prepared select statement
statement用于为一条SQL语句生成执行计划（这也是为什么select statement只会执行第一条select语句的原因），如果只执行一次SQL语句，statement是最好的类型；
Datbases中末尾添加 &allowMultiQueries=true
5、Rrepared update statement
Prepared update statement和Prepared select statement的用法是极为相似的，具体可以参照第四种类型。
Datbases中末尾添加 &allowMultiQueries=true
6、Commit
commit的意思是：将未存储的SQL语句结果写入数据库表；而在jmeter的JDBC请求中，同样可以根据具体使用情况，选择这种Query类型。
7、Rollback
rollback指的是：撤销指定SQL语句的过程；在jmeter的JDBC请求中，同样可以根据需要使用这种类型。
8、AutoCommit(false)
MySQL默认操作模式就是autocommit自动提交模式。表示除非显式地开始一个事务，否则每条SQL语句都被当做一个单独的事务自动执行；
9、AutoCommit(true)
这个选项的作用和上面一项作用相反，即：无论何种情况，都自动提交将结果写入，结束当前事务开始下一个事务。
10、编辑（${}）
jmeter中的JDBC请求中的SQL语句是无法使用参数的，比如： SELECT * FROM ${table_name} 是无效的。
如果需实现同时多个不同用户使用不同的SQL，可以通过把整条SQL语句参数化来实现；（把SQL语句放在csv文件中，然后在JDBC Request的Query 中使用参数代替 ${SQL_Statement}）。
问答:
GET和POST区别
==============================================
GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包。
长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
\1. GET与POST都有自己的语义，不能随便混用。
\2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
\3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。