Siege---Linux性能压测工具及结果分析

Posted 2023-03-25

参考技术A @[性能测试,yoyoyang]

-C,或–config 在屏幕上打印显示出当前的配置,配置是包括在他的配置文件$HOME/.siegerc中,可以编辑里面的参数,这样每次siege 都会按照它运行.

-v 运行时能看到详细的运行信息

-c n,或–concurrent=n 模拟有n个用户在同时访问,n不要设得太大,因为越大,siege 消耗本地机器的资源越多

-i,–internet 随机访问urls.txt中的url列表项,以此模拟真实的访问情况(随机性),当urls.txt存在是有效

-d n,–delay=n hit每个url之间的延迟,在0-n之间

-r n,–reps=n 重复运行测试n次,不能与 -t同时存在

-t n,–time=n 持续运行siege ‘n’秒(如10S),分钟(10M),小时(10H)

-l 运行结束,将统计数据保存到日志文件中siege .log,一般位于/usr/local/var/siege .log中,也可在.siegerc中自定义

-R SIEGERC,–rc=SIEGERC 指定用特定的siege 配置文件来运行,默认的为$HOME/.siegerc

-f FILE, –file=FILE 指定用特定的urls文件运行siege ,默认为urls.txt,位于siege 安装目录下的etc/urls.txt

-u URL,–url=URL 测试指定的一个URL,对它进行”siege “,此选项会忽略有关urls文件的设定

Transactions 访问次数
Availability 成功次数
Elapsed time 测试用时
Data transferred 测试传输数据量
Response time 平均响应时间
Transaction rate 每秒事务处理量
Throughput 吞吐率
Concurrency 并发用户数
Successful transactions 成功传输次数
Failed transactions 失败传输次数
Longest transaction 最长响应时间
Shortest transaction 最短响应时间

yum -y install iftop
iftop
top

Controller及结果分析

一、性能测试概述

1、关于性能测试目标：

①TPS

②一定并发用户数下功能点的响应时间

③一定响应时间内功能点的并发用户数

性能测试不是达到既定目标即可，还要测试软件功能能够达到的极限值。

2、关于性能测试的场景：

在脚本录制调试完成后，需要进行场景的设置，进而对脚本进行压测，分析压测的结果。

性能测试场景：

　　单场景 → 单独某个功能、接口，测试目标是多少(一般10--15分钟)

　　混合场景 → 发现线程死锁和数据库死锁(一般10--15分钟)

　　稳定性场景 → 系统是否稳定运行，发现系统是否有内存泄漏(过程)、内存溢出(结果，系统崩溃)(一般N*12小时)

在进行场景的压测时，相当重要的一点是要保证数据库表中有足够的数据量。

3、loadrunner负载机

用其它机子做负载机为"分布式负载"，这时候在用作负载的机子上，只需要安装loadrunner Agent这个模块就可以了，在进行分布式负载时，可能出现连接不上负载机的情况，检查网络及防火墙的状况。

 

二、Controller的场景概述

 

三、手工性能测试场景

1、为什么要使用分布式负载：

在进行并发的时候，一台PC机能够发送的并发数，可能达不到测试的要求，那么就需要用多台机子进行并发，每台机子分担一定的并发数。

Controller应与Load Generator分开。若测试需要的vu数，超过单负载机所能产生的vu数，则负载机本身将成为性能瓶颈，这是不合理的。

例如，负载机内存512M，一个vu占2.5M，则单台负载机只能产生200vu，若需测试500vu，一台controller调用多台Generator，要考虑负载均衡问题，带宽问题。

2、Controller的场景设置：

①Controller中负载机的设置如下图：

 在进行脚本压测时候，可以如下图进行快速的操作：

上边我们已经描述了在Scenario Groups中，如何进行脚本的选择及负载机是如何进行设置的，接下来要对脚本的并发数及运行时间进行设置：

②脚本虚拟用户初始化：

一般在进行虚拟用户设置的时候，选择弹出框Edit Action中的第一个或者第三个选项

③虚拟用户并发数及加载方式的设置：

注意：在此次设置了多少个虚拟用户进行并发，并不表示在进行压测时，就有设置的并发用户数运行，实际的并发数，取决于服务器的处理能力及代码，TPS/RPS(每秒通过的事务/每秒通过的请求数)

 

• 思考：

压测时2000个用户并发，每秒加载2个用户，并发15分钟，问在15分钟里，用户数能够加载完吗

进行如下设置：

由上图可知，用户的加载时间，不包含用户的并发时间

同理用户的退出时间，也不包含在用户的并发时间内，所以说以上"压测时2000个用户并发，每秒加载2个用户，并发15分钟，问在15分钟里，用户数能够加载完吗"的描述是错误的。

 如下图设置：

loadrunner的运行方式有两种：进程方式、线程方式

默认情况下以线程方式运行

在脚本运行前，加载2000个并发用户，这时服务器会启动40个(2000/50=40)mmdrv进程(1个mmdrv进程默认有50（可修改）个线程。也就是说如果是50个进程并发的话，系统会启动一个mmdrv的进程(负载机进程)，如果多于50个线程，就对应启动x个mmdrv进程。如果是以进程方式运行的话，一个并发就是一个mmdrv进程。进程比较耗内存资源，线程比较耗CPU可以这么理解。)

产生的影响：

对负载机来说，开始压力会大一些

对服务器来说，服务器没有任何缓存时间，一下子来2000个并发，可能导致服务器崩溃

热负载：一点一点的加并发

冷负载：所有并发一次性向服务器发送

 

loadrunner支持压测的同时，增加并发用户数，如下图：

在压测时候对比上图①运行的虚拟用户数②请求的响应时间③tps 进行分析

④脚本的串联运行：

方式一、

方式二、lr和QC进行集成

方式三、定时任务

 

四、面向目标的性能测试场景

 

 

五、Analysis：

1、新增监控视图：

2、Analysis报告的简单分析：

上图中，如果标准方差在5以内取Average做作为平均相应时间，如果标准方差大于5取90 Percent作为响应时间。

3、Analysis中，进行视图的合并操作，如下图：

一般合并并发用户数和响应时间或者并发用户数和tps，可以看到不同并发用户数下的响应时间或者tps值的变化情况。

 并发用户数下的响应时间不包含失败事务或者请求的响应时间。

 

六、测试目标对应测试场景的设置实战

实战1、测试响应时间：测试网易体育20个并发的响应时间如何设置？(测试某个功能/接口的响应时间，前提条件是多少个并发)

直接加载需要的用户数去测试某个功能/接口，并发15分钟，得出平均时间即可

在手工场景下进行如下设置：

脚本运行完后，根据标准方差的大小，取平均响应时间或者百分之90的响应时间

 

实战2、测试最大tps 需要知道测试哪个接口或者功能(包含条件是1秒)

直接从1个用户开始测试，通过不断的加压(加用户)去测试最大tps，最大tps的标识是随着用户的不断增加，tps不再增加或者tps反而减小，那么那个不再增加的tps或者出现拐点的tps就是最大的tps

在手工测试场景下，进行如下设置：

扩展：

项目的某一功能的tps如何评估：

①tps是开发、项目经理或者产品经理制定的。分析线上日志，1s最大有多少个用户或请求通过

②只知道在线用户数，如何去衡量系统某个功能的tps是合理的

测试人员心里预估值来源：

最精确来源，线上日志分析(可用awk命令统计日志每分钟通过的请求数，进而得到tps)；

其次可以用28(百分之80的用户会在百分之20的时间段内同时做一件事情)原则，前提知道在线用户数，和用户的访问习惯，譬如有100个用户，在预定的某个10分钟内，要做某件事，那么 100个用户*80%=80个用户，10分钟*20%=2分钟  tps=80/(2*60)

 

实战3：测试最大并发用户数：测试某个功能/接口，响应时间在多少秒以内

用户直接从1开始测试，逐渐加大并发用户数，观察响应时间，直到响应时间达到需要的秒数，再继续观察响应时间是否稳定，如果稳定，那么这个并发数就是最大并发，如果不稳定，那么就需要增加或减少用户

 

四、其它的一些问题：

这里描述一些问题，表述其思考方式，以便举一反三：

1、发送的请求大于处理请求，出现排队的情况，响应时间会越来越长。

2、在允许同一个用户多点登录的情况下，在进行压测的时，不需要进行登录用户的参数化操作；如若不允许同一个用户进行多点登录的话，就需要进行参数化。

3、性能测试压测对象是action中的事务，在init中不影响，参数化的时候，用once的时候，不需要做参数化。

4、lr的循环嵌套：

cotroller里的运行时间 - while(endtime>0) → action的迭代 - while(迭代次数>0) → 脚本里的循环

故在脚本中，设置迭代的次数并不影响压测时，controller的显示。

5、loadrunner测试手机app:app和web一样，app本身就相当于web浏览器，后台调的都是服务，对server有并发对app本身没有并发，测试app分为两部分：后台的服务器的性能(接口),接口不需要录制，只需要知道app接口的说明文档，自己手写脚本；app本身，相当于web前端性能测试，需要用到其它前端性能测试工具。

6、IP欺骗：模拟本机局域网段内的大量IP来进行操作。服务器识别的是网卡IP，单网卡一个IP，双网卡俩IP。

 

---------

释然、感恩，感恩遇到她，感恩曾经一起的美好... ...

越努力越精彩，加油！！！

--------------