这里是修真院后端小课堂,每篇分享文从html
【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】java
八个方面深度解析后端知识/技能,本篇分享的是:node
【什么是session?什么是cookie?session和cookie有什么区别?什么场景适用于session?什么场景适用于cookie? 】正则表达式
1.背景介绍
数据库
什么是压测?后端
压力测试是经过不断向被测系统施加“压力”,测试系统在压力状况下的性能表现, 考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在, 也就是咱们能够模拟巨大的工做负荷以查看应用程序在峰值使用状况下如何执行操做。服务器
为何要进行压力测试?cookie
压力测试其实有两个目的,一是测试应用在高并发状况下是否会报错,进程是否会挂掉; 二是测试应用的抗压能力,预估应用的承载能力,为运维同窗提供扩容的依据。 第一点很好理解,作好这一点就能够保证上线以后不出问题了。解释下第二点,咱们都知道就是架构设计的再优秀,代码写的再好, 应对高并发单实例始终是有限的。因此一般是在知足第一点的前提下, 再根据可能到来的高并发压力来计算须要多少实例来承载,而这就须要咱们压出极限。网络
接口开发完成以后就能够进行第一次压力测试。这一次压力测试能够简单压一下, 在本机进行就能够。压力测试的目的是检查代码在高并发下是否会报错。 另外,编译型语言要观察是否存在内存泄漏。 由于本机性能有限,通常来讲按照100、200、300、500进程数进行压力测试, 压到500若是没有报错就能够进行疲劳测试,观察内存占用。session
2.知识剖析
什么Jmeter?
Jmeter 是一款使用Java开发的,开源免费的,测试工具, 主要用来作功能测试和性能测试(压力测试/负载测试). 并且用Jmeter 来测试 Restful API, 很是好用。 同时,JMeter能够帮助你对你的应用程序进行回归测试。经过你建立的测试脚本和assertions来验证你的程序返回了所期待的值。 为了更高的适应性,JMeter容许你使用正则表达式来建立这些assertions.
一、Test Plan (测试计划):用来描述一个性能测试, 包含与本次性能测试全部相关的功能。也就说本的性能测试的全部内容是于基于一个计划的。
二、Threads (Users)线程 用户
1) setup thread group 可用于执行预测试操做。这些类型的线程执行测试前进行按期线程组的执行。
2) teardown thread group. 可用于执行测试后动做。这些类型的线程执行测试结束后执行按期的线程组。
3) thread group(线程组). 这个就是咱们一般添加运行的线程。通俗的讲一个线程组,,能够看作一个虚拟用户组,线程组中的每一个线程均可以理解为一个虚拟用户。 线程组中包含的线程数量在测试执行过程当中是不会发生改变的。
Ramp-Up Period:单位是秒,默认时间是1秒。它指定了启动全部线程所花费的时间, 若是你须要Jmeter当即启动全部线程,将此设定为0便可
循环次数:表示每一个线程执行多少次请求。
三、采样器(Samplers)它们是每个测试计划的基本要素,一切都围绕这些采样器而工做:采样器执行请求(基于配置的请求), 这些请求产生一个或多个响应,后续将被分析。
四、监听器(Listeners):负责收集测试结果,同时也被告知告终果显示的方式。 监听器以报表、树型结构、或简明的日志文件的形式分析结果。 功能是对取样器的请求结果显示、统计一些数据(吞吐量、KB/S……)等。
五、断言(Assertions):用于来判断请求响应的结果是否如用户所指望,是否正确。 断言通常用来设置检查点,用以保证性能测试过程当中的数据交互是否与预期一致。
六、定时器(Timers):负责定义请求(线程)之间的延迟间隔,模拟对服务器的连续请求。 用于操做之间设置等待时间,等待时间是性能测试中经常使用的控制客户端QPS的手段。若是不指定,JMeter会一个请求完成后当即执行下一个请求,没有任何等待时间。
七、逻辑控制器(Logic Controllers):容许自定义JMeter发送请求的行为逻辑,它与Sampler结合使用能够模拟复杂的请求序列。
八、前置处理器和后置处理器负责在生成请求以前和以后完成工做。 前置处理器经常用来修改请求的设置,后置处理器则经常用来处理响应的数据。
九、配置节点(Configuration nodes) 经过使用配置元素你能够将不一样的参数传递给取样器请求。他们提供了建立变量(不一样的和动态的)的一种方式,这些参数以后被采样器所使用。 在采样器被执行前,参数所属节点启动时,这些参数被执行;这就是为何采样器能够依赖这些变量。
测试计划元素执行顺序
1–配置节点
2–前置处理器
3–定时器
4–取样器
5–后置处理器(只在有结果可用状况下执行)
6–断言(只在有结果可用状况下执行)
7–监听器(只在有结果可用状况下执行)
3.常见问题
吞吐量与带宽的区分
利用BadBoy生成测试计划(测试脚本)
4.解决方案
吞吐量和带宽是很容易搞混的一个词,二者的单位都是Mbps.先让咱们来看二者对应的英语, 吞吐 量:throughput ; 带宽: Max net bitrate 。当咱们讨论通讯链路的带宽时,通常是指链路上每秒所能传送的比特数。 咱们能够说以太网的带宽是10Mbps。可是,咱们须要区分链路上的可用带宽(带 宽)与实际链路中每秒所能传送的比特数(吞吐量)。 咱们倾向于用“吞吐量”一次来表示一个系统的测试性能。这样,由于实现受各类低效率因素的影响, 因此由 一段带宽为10Mbps的链路链接的一对节点可能只达到2Mbps的吞吐量。 这样就意味着,一个主机上的应用可以以2Mbps的速度向另外的一个主机发送 数据。
6.扩展思考
如何正确作WEB应用的压力测试
1) 首先说一下如何产生压力,产生压力的方法有不少,一般能够写脚本产生压力机器人对服务器进行发包和收包操做, 也可使用现有的工具(像jmeter、LoadRunner这些),因此说产生压力其实并不难,难点在于产生的压力是否是真实地反映了实际用户的操做场景。 举个例子来讲,对游戏来讲单纯的并发登录场景在整个线上环境中的占比可能并不大(新开服等特殊状况除外), 相反“登录-开始战斗-结束战斗”、不一样用户执行不一样动做这种“混合模式”占了更大的比重。 因此如何从实际环境中提炼出具体的场景比重,而且把这种比重转化成实际压力是一个重要的关注点。
2)产生压力以后,一般咱们能够拿到TPS、响应时延等性能数据,那么如何定位性能问题呢? TPS、响应时延只能告诉你服务器是否存在问题,但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合做用的结果, 这时候能够先关注系统的CPU、内存、IO、网络,对比在tps、时延达到瓶颈时这些系统数据的状况,肯定性能问题是系统哪一部分形成的, 而后再回到代码的逻辑中逐个优化这些点。
3)当服务器的总体性能就能够相对稳定下来,这时候就须要对本身服务器的承载能力有一个预估, 经过产生真实压力、对比系统数据,大体能够对单套系统的处理能力有个真实的评价,而后结合业务规模配置服务器数量。
7.参考文献
https://www.jianshu.com/p/c25...
http://www.51testing.com/html...
1.吞吐量与带宽的区分
当咱们讨论通讯链路的带宽时,通常是指链路上每秒所能传送的比特数。 咱们能够说以太网的带宽是10Mbps。可是,咱们须要区分链路上的可用带宽(带 宽)与实际链路中每秒所能传送的比特数(吞吐量)。 咱们倾向于用“吞吐量”一次来表示一个系统的测试性能。这样,由于实现受各类低效率因素的影响, 因此由 一段带宽为10Mbps的链路链接的一对节点可能只达到2Mbps的吞吐量。 这样就意味着,一个主机上的应用可以以2Mbps的速度向另外的一个主机发送 数据。
2. JMeter的做用?
.JMeter能够用于测试静态或者动态资源的性能(文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其余的资源)。JMeter用于模拟在服务器、网络或者其余对象上附加高负载以测试他们提供服务的受压能力,或者分析他们提供的服务在不一样负载条件下的总性能状况。你能够用JMeter提供的图形化界面分析性能指标或者在高负载状况下测试服务器/脚本/对象的行为。
3.测试计划元素执行顺序?
1–配置节点
2–前置处理器
3–定时器
4–取样器
5–后置处理器(只在有结果可用状况下执行)
6–断言(只在有结果可用状况下执行)
7–监听器(只在有结果可用状况下执行)