关于性能测试的几个要点

时间 2019-11-07

标签关于性能测试几个要点栏目系统性能繁體版

原文原文链接

几个定义

性能测试（Performance Test）

一般收集全部和测试有关的全部性能，一般被不一样人在不一样场合下进行使用。测试软件在系统中的运行性能，度量系统与预约义目标的差距。html

关注点：how much和how fastlinux

负载测试（Load Test）

负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否可以承担。经过逐步增长系统负载，肯定在知足性能指标的状况下，系统所能承受的最大负载量。git

关注点：how muchgithub

压力测试（Stress Test）

压力测试是一种高负载下的负载测试，也就是说被系统处于一个负载的状况，再继续对他进行加压，造成双重负载，知道系统崩溃，并关注崩溃后系统的恢复能力，之前再加压的一个过程，看看系统究竟是否已经被完全破坏掉了。web

有个很形象的说法就是：你可以承担100千克的重量，并且也能走，可是你可否承担100千克的重量行走1个月。apache

外部的负载叫压力，内部的压力叫负载。负载注重关注内部的以及系统自身一些状况；而压力更关注系统外部的表象.缓存

性能测试模型

性能测试的执行过程是由轻到重，逐渐对系统施压。一般用户最关心的性能指标包括：响应时间、吞吐量、资源利用率和最大用户数。咱们能够将这张图分红3个区域，即：轻负载区域、重负载区域和负载失效区域。服务器

轻负载区域
在这个区域您能够看到随着虚拟用户数量的增长，系统资源利用率和吞吐量也随之增长，而响应时间没有特别明显的变化；cookie
重负载区域
在这个区域您能够发现随着虚拟用户数量的增长，系统资源利用率随之缓慢增长，吞吐量开始也缓慢增长，随着虚拟用户数量的增加，资源利用率保持相对的稳定（知足系统资源利用率指标），吞吐量也基本保持平稳，后续则略有下降，但幅度不大，响应时间会有相对较大幅度的增加；网络
负载失效区域
在这个区域系统资源利用率随之增长并达到饱和，如CPU利用率达到95％甚至100%，并长时间保持该状态，而吞吐量急剧降低和响应时间大幅度增加（即：出现拐点）。
两个交界点
在轻负载区域和重负载区域交界处的用户数，咱们称为"最佳用户数"。而重负载区域和负载失效区域交界处的用户数则称为"最大用户数"。

当系统的负载等于最佳用户数时，系统的总体效率最高，系统资源利用率适中，用户请求可以获得快速响应；

当系统负载处于最佳用户数和最大用户数之间时，系统能够继续工做，可是响应时间开始变长，系统资源利用率较高，并持续保持该状态，若是负载一直持续，将最终会致使少许用户没法忍受而放弃；

而当系统负载大于最大用户数时，将会致使较多用户因没法忍受超长的等待而放弃使用系统，有时甚至会出现系统崩溃，而没法响应用户请求的状况发生。

并发用户数

相对并发用户数(`用户视角`)

即线用户数，在一个时间段内，与服务器进行了交互、对服务器产生了压力的用户的数量。这个时间段，能够是一天，也能够是一个小时。

一般像ab、wrk等并发工具设定的并发数，就是指的这个并发数，好比在JMeter中，若是将某个线程组的线程数设置为100，那是否是对于这个类型的请求，并发量就是100。从宏观的角度，这样理解也是对的，就比如请了100我的，每一个人独立地完成一连串的工做，确实是100个在并行。可是对于服务器感觉到的压力，可能就不是100了。

这里所谓的100个并行对于服务端而言并非严格的所有并行，由于每一个虚拟用户执行的节奏是独立。假设这个操做须要3个请求完成，那么颇有可能出现这样的状况：某个虚拟用户还在等待第一个请求的响应，可是另外一个虚拟用户已经收到了第一个请求的响应并发起了第二个请求。那么对于服务端而言，在某一个时刻，不管是对于请求1仍是请求2，并行度都没有到100。这个模型比较相似于图中右边部分所示的模型。理解这个模型对于并行的理解很是重要。

这里的差别在于宏观上的并行仍是严格意义上的并行，好比就某个请求的严格意义上的并行或许能够经过TCP链接的保持数来看。经过“netstat|grep ESTABLISH|wc-l”命令得到保持链接状态的TCP请求数量。也就是下面的绝对并发用户数。

并发与并行是相关的概念，可是也有不少细节上的差别。并发意味着两个或更多的任务正在取得进展，即便它们不是同时执行的。例如，能够用时间片的方式实现这一点，每一个任务在时间片内执行一小部分，并与其它任务的切片混合执行。如并发收集器。并行的出现使任务实现了真正的同时执行。

绝对并发用户数(`服务器视角`)

主要是针对某一个操做进行测试，即多个用户同一时刻发起相同请求。

图中，每个颜色的线段表明一种操做。在任意一个时刻，服务器都知道它有10个事务须要处理，这10个事务也是有10个用户产生的。但它不知道的是，整个时间段内的全部事务，是由多少个用户与系统交互而产生的。时刻1，10个当前事务是由10个用户发起的。时刻2，依然是10个正在进行的事务，但多是彻底不一样的10我的发起的。在这段时间内，服务器每个时刻都在处理10个事务，可是参与了这个交互过程（对服务器产生压力）的人可能会达到上百个，也可能只有最开始的10个。那么，对于服务器来讲，压力是什么呢？显然只是每时刻这10个同时处理的事务。

Think Time

在进行相对并发用户数的测算时，think time的设置会影响测试的结果。设想这样的一个场景，一个真实的用户在某个电商网站上购物，一个简化的流程可能以下： 1）进入首页 2）搜索一个商品 3）查看商品详情 4）加入购物车 5）提交订单 6）完成支付基于上面的讨论咱们能够构造一系列JMeter请求，放在一个线程组里面。若是咱们要测试针对这样的用户，咱们的系统能够支持多少人同时来购物。假设咱们已经考虑了用户登陆帐号和购买商品的参数化问题，是否能够直接将线程组的数值设置到一个较大的数值，而后并发执行呢？

这样能够执行起来，可是有一个很大的问题。在于真实用户和脚本的不一样。脚本若是是基于前面方法录制的，两个请求的执行时间以前是没有任何其余停顿的，其间隔只是依赖于上一个服务的响应时间和测试机发起请求所需的时间。可是显然真实的用户不是机器，他们在作上面每个步骤的时候都有一个思考的时间，这也是Think Time这个词的意义来源。

固然，这个思考时间也是泛指，包括了用户操做的时间，好比进入首页后，用户须要在搜索框中输入想购买商品的关键词，打开输入法并输入相关的词可能也须要少则几秒钟的时间，搜索结果出来以后用户须要浏览和选择，找到感兴趣的商品并点击查看详情，后面的步骤也是相似。试想一下，对比请求连续执行和每一个步骤间加入模拟真实用户的Think Time以后，对于同一个系统，能支持的同时在线购物人数一定会有绝大的差别，而有Think Time的作法显然更接近真实状况。

准备工做

不一样的机器、操做系统、web服务器以及相关参数等的不一样，也会影响性能测试的结果。有必要在测试前对参数进行一下配置。
参考作一个正确的性能测试以及高负载系统，网络参数调整进行调优。这里列一下操做系统的几个重要参数。

fs.file-max = 999999  
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.ip_local_port_range = 1024    61000
net.ipv4.tcp_rmem = 4096 32768 262142
net.ipv4.tcp_wmem = 4096 32768 262142
net.core.netdev_max_backlog = 8096
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn.backlog=1024

file-max：这个参数表示进程（好比一个worker进程）能够同时打开的最大句柄数，这个参数直接限制最大并发链接数，需根据实际状况配置。
tcp_tw_reuse：这个参数设置为1，表示容许将TIME-WAIT状态的socket从新用于新的TCP链接，这对于服务器来讲颇有意义，由于服务器上总会有大量TIME-WAIT状态的链接。 - tcp_keepalive_time：这个参数表示当keepalive启用时，TCP发送keepalive消息的频度。默认是2小时，若将其设置得小一些，能够更快地清理无效的链接。
tcp_fin_timeout：这个参数表示当服务器主动关闭链接时，socket保持在FIN-WAIT-2状态的最大时间。
tcp_max_tw_buckets：这个参数表示操做系统容许TIME_WAIT套接字数量的最大值，若是超过这个数字，TIME_WAIT套接字将马上被清除并打印警告信息。该参数默认为180000，过多的TIME_WAIT套接字会使Web服务器变慢。
tcp_max_syn_backlog：这个参数表示TCP三次握手创建阶段接收SYN请求队列的最大长度，默认为1024，将其设置得大一些可使出现Nginx繁忙来不及accept新链接的状况时，Linux不至于丢失客户端发起的链接请求。
ip_local_port_range：这个参数定义了在UDP和TCP链接中本地（不包括链接的远端）端口的取值范围。
net.ipv4.tcp_rmem：这个参数定义了TCP接收缓存（用于TCP接收滑动窗口）的最小值、默认值、最大值。
net.ipv4.tcp_wmem：这个参数定义了TCP发送缓存（用于TCP发送滑动窗口）的最小值、默认值、最大值。
netdev_max_backlog：当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。这个参数表示该队列的最大值。
rmem_default：这个参数表示内核套接字接收缓存区默认的大小。
wmem_default：这个参数表示内核套接字发送缓存区默认的大小。
rmem_max：这个参数表示内核套接字接收缓存区的最大大小。
wmem_max：这个参数表示内核套接字发送缓存区的最大大小。
tcp_syncookies：该参数与性能无关，用于解决TCP的SYN攻击。

测试工具

性能测试工具的几个核心的模块

压力生成器（Virtual User Generator）
结果采集器（Result Collector）
负载控制器（Controller）
系统资源监控器（Monitor）
结果分析器（Analysis）

由此能够看出，像wrk、apache bench这类的工具，其实不算是完整的性能测试工具，由于它们并无系统资源监控器，这样的话，其实简单测试出来的结果并非很准确，只能说是简单粗暴凑合着用。

被测系统资源监控

性能测试数据收集中很重要的一部分是被测系统的资源使用状况，由于系统性能和资源使用是密切相关的，主要的目的有下面几个方面：了解在当前压力下，系统各项资源的使用状况，也能够用于横向对比。经过资源使用状况的分析能够看出当前是否测出了系统最大的性能。是否有某项资源的使用已经到达上限，成为瓶颈。是否有其余非被测系统的模块占用了资源。一般在性能测试中，测试人员都会去收集CPU、内存、网络等服务器资源使用状况，可是若是只是笼统地给出一个百分比是不够的，须要进一步细分来提供更多有参考价值的数据。

所以若是只是简单地用wrk这类测试，记得关注被测试系统的cpu、io(网络/文件)、内存等使用状况。对于互联网的应用，特别要关注网络链接数。

系统资源瓶颈

稳定系统资源状态

系统资源瓶颈

峰值流量估算

可根据历史日均压力、日最高压力等信息，估算出将来几年的日均以及日最高压力。再经过一些通用估算方法、如二八原则（80%的工做在20%时间内完成，至关于2小时完成一天8小时的工做量），将日压力转换成峰值压力。

假设系统日均pv 8000w，一天按照4w秒算，8000w/4w=2000，平均大概2000QPS，按28原则算，峰值的qps则有2000*4=8000 QPS