本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈如何使用系统性能测试工具,以及对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享如何使用系统性能测试工具的知识,其中也会对进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
如何打开win10系统自带系统评分功能进行电脑性能测试
用win10系统自带系统评分功能进行电脑性能测试操作方法如下如何使用系统性能测试工具:
1、按下键盘上如何使用系统性能测试工具的Windows徽标键+R组合键,打开运行窗口,在命令输入框中输入 winsat formal命令,回车。
2、接着会弹出一个命令提示符窗口,此时系统的性能评估测试就开始如何使用系统性能测试工具了,测试过程会需要一段时间,当性能评估测试完成时,该命令提示符窗口会自动一闪消失。
3、当系统评估测试完成后,重新按下Windows徽标键+R组合键打开运行窗口,在命令框中输入shell:games命令,回车。
4、回车后即可看到系统为计算机的评分。
如何使用win7自带的测试工具测试电脑性能
1、右键计算机,点击属性:
2、然后出现如下图所示界面,这里我们点击要求刷新Windows体验指数:
3、出现为计算机评分并提高其性能,点击立即刷新:
4、随后win7系统的性能检测就开始了:
5、最后评分出来了分数范围是1.0到7.9数值越大说明性能越强:
性能测试工具 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.baidu.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 脚本来个性化定制请求等。希望读完本文,能对您有所帮助哦!
十分钟学会性能测试(上)
本文分上下两个部分
如何使用系统性能测试工具,上半部分主要介绍
如何使用系统性能测试工具:
一、什么是性能测试
二、术语
三、性能测试类型
下半部分主要介绍:
四、性能测试流程
五、性能测试执行(三分钟教会你用Jmeter进行性能压测)
六、结果查看及分析
通篇的风格以寓教于乐为主,介绍知识为辅。希望大家能在快乐中学习,在开心中成长。时间仓促,错误纰漏在所难免,还请“大神”不惜指正
如何使用系统性能测试工具!
一、什么是性能测试
性能测试 是通过对系统进行性能需求分析,在合理评估的性能测试环境上,通过测试工具模拟正常、峰值、以及异常负载条件对系统各项性能指标进行测试,旨在发现性能缺陷、进行能力验证、验证规划能力和性能调优,并针对测试结果进行分析总结定位的测试过程。(* 引自专家测试团队《性能测试白皮书》)
************解释************
通俗点说,就是使用用各种“酒具”(jmeter、LoadRunner、Power平台)配合着各种“红、白、啤酒”(入参数据+并发数)来让你达到“正常嗨(正常)、非常嗨(峰值)、嗨过头(异常负载)”的状态,并在这期间通过“心电图”(JMC-- Java Mission Control)或者把你放到“提前定制化的座椅”(RSMS、Dolphin)来持续对你进行观察、监控,从而记录下你在不同剂量下的反应。并根据观察结果来分析“红酒您能喝几瓶”、“白酒能喝几瓶”、“啤酒能喝几瓶”(能力验证);强化了身体素质(系统性能优化)之后又能喝几瓶;甚至是规划一下“有蒙古大汉自远方来不亦喝乎”时,你能不能喝翻他(容量规划)等等……,这些过程,就是“性能测试”!
二、术语
在继续介绍性能测试之前,我们有必要先解释一下经常用的一些术语。否则我瞎逼逼半天,您一脸懵逼,大家就真的在尬聊了……
1.并发用户数
同一时刻操作某个页面或某个功能的用户数,描述系统能够承受的并发性能。它是一个时间段内发生的事情,它意在表达“并发”的可能性,是压力的一种度量。计算公式:C=nl/t
n : 业务在线的总用户数量
l : 业务产生的平均时间长度
t : 考察的时间段总长度
************解释************
我们假想出一个很长很长的水泥管道,管道入口处站了1000个高矮胖瘦一致的人,其中有400人想要通过这个管道。每个人走过这个管道平均需要1个小时,前面的人没走完时入口不放行下一组进入,且入口处每天只有8小时可以放行让人进入。那么,这时“预期”的并发用户数就是400*1/8=50,也就是说,只有管道宽的可以装下50人并排走,才能在一天之内让400人都通过。
为什么说是“预期”呢?那是因为可能您胆子小,假想的时候没敢想太大,就只想出了一个允许2人通行的小水管。那8小时肯定走不完所有人啊,所以你需要继续想、使劲努力YY出一个巨大的管子(性能优化)!当然,不排除您跟我一样天赋异禀,一开始就构想出能同时并排200人的巨管。这意味着,就并发用户数这一项,您的系统性能指标完爆当前既定业务量。
2.响应时间
用户发起请求到响应返回的时间,描述交易执行快慢程度。(计算规则:响应时间=网络传输时间+系统响应时间)
90%Percent:每个事务90%用户的响应时间在该值以下
Minimum:每个事务所有用户中最小的响应时间
Average:每个事务所有用户的响应时间算数平均值
Maximum:每个事务所有用户中最大的响应时间
************解释************
还是继续走管道……我们给每个人发一个秒表,人们并排进入管道的同时每个人按下秒表。每个人行走的速度不同,虽然是并排进入,但并不是一同出来。每一个人走出管道的同时,再次按下秒表……这时,秒表记录的时间就是这个人(请求)开始到结束的响应时间。
90%Percent:我们把同时走管道的一波人看做一个队伍,队伍中90%的人是在这个时间以内就走出了管道;
Minimum:走的最快的那个人所用的时间;
Average:所有人花费时间的平均值(在这个例子中为1小时);
Maximum:走的最慢的那个人所用的时间。
3.TPS
指每秒处理的事务数,TPS=总事务数/总的时间,描述了服务器的处理能力。
************解释************
一句话,就是每秒钟通过管道的人。这里肯定有人觉得这个概念看着眼熟,很像最开始的并发用户数,对么?仔细看一下他们的区别:并发用户数是指同时进入管道的“肩并肩”的人,吞吐量是指每秒钟那些肩并肩进入管道的人中,平均多少人走了出来。所以,在这里“TPS = 并发数/平均响应时间”
4.二八法则
【80%的业务请求在20%的业务时间里面产生。】
如:信用卡客服系统中"客户信息查询功能”年使用量为4800万次,系统服务时间为7*24小时。每秒请求数:
48000000*80%/365*24*3600*20%=38400000/6307200=6次/秒
************解释************
这个有毛用呢?试想一下,如果我们要压这个信用卡客服系统,是不是真的需要7*24小时不停压一年凑够4800万个请求呢?用脚趾头也能想明白,肯定不用啊!那如何在减少工作量的情况下尽可能的模拟真实场景呢?这个时候二八法则就出场了!(别问我为什么不是三七、四六、五五法则,你当是在分赃吗?)
5. 2-5-8原则
WEB系统性能测试中的2-5-8原则描述如下:
用户在2秒以内得到响应时,系统的响应很快,用户对系统的体验较优;
用户在2-5秒之间得到响应时,系统的响应速度还可以,用户对系统的体验一般;
用户在5-8秒以内得到响应时,系统的响应速度较慢但还在接受范围,用户对系统的体验较慢;
用户在超过8秒后仍然无法得到响应时,通常会认为系统已经失去响应,选择离开或者发起第二次请求,用户对系统的体验很糟糕。
************翻译************
这个没啥好解释的,就是个“业界”非标准化的一个标准……所以,以后在项目中没有明确要求某功能or页面的响应时间时,就拿这个当标准来考量吧!另外需要补充的一点是,我们用jmeter一般是压接口,我们得出的响应时间一般会小于直接压页面,为什么呢?这里影响响应时间的除了网络传输时间+系统响应时间,还有个前端页面渲染的时间。所以如果我们想web用户体验较好(3秒内),压接口的响应时间最好就要低于3秒,这给页面渲染留出一定的冗余时间。
三、性能测试类型
终于要开始介绍性能测试的干货(Fuck foods)了。
1、基准测试
测试系统是否存在线程安全性问题,并得到一定测试条件下的系统的性能基线数据。目的是得到系统的性能基线数据,并对响应时间、TPS和其他与时间相关的需求进行评估。
************翻译************
俗话说的好,“凡事都有个第一次,再丑的媳妇也要见公婆”。这个类型就是针对之前没有做过性能测试,或者是根据新需求而刚刚开发完成的新系统来说的。这时,您就需要来一份“基准测试”啦!先给自己留个底儿,有了性能基线,我们才能继续后面的“调优”不是?
对比测试
对比不同测试条件下的性能差距,常用于系统优化,技术选型,通过相同的用例对比性能数据。测试方式和负载测试类似。
************翻译************
多说无益,我们“举几个比方,打几个栗子”:
我们对系统的某功能进行了优化,需要验证该功能在优化前后的性能对比数据时,可以进行对比测试;
老板让我说出两种系统架构或者实现方法下,哪一种更好,可以进行对比测试;
老板让我说出这两款设备,哪一款更优秀,可以进行对比测试。
说白了,就是各种比较,没有对比就没有伤害;不对比你怎么能知道你有多胖呢,对不对?!(观众:扔砖头!!!)
2、容量规划
测试系统在软硬件上的扩展能力,常用于测试软件扩容,硬件扩容。容量规划也是对比测试的一种。
************翻译************
就如定义中所说,容量规划也是对比测试的一种。这个类型主要使用场景有:
软件扩容:我们用多线程来代替原有的单线程处理请求;
硬件扩容:我们增加了两台redis,加大了weblogic server的内存或者直接增加了4台服务器。
在这里也要额外说一点:我们扩容,特别是硬件扩容,是不能按照倍数来放大扩容效果的。例如,我们2台server时TPS为100,我们增加到4台同样配置的server时,TPS并不是增加到200了。有可能是160、170、180……这其中并没有一个线性的关系,这点很重要需要知悉。所以,很多时候项目组找到我们做性能测试,说我们生产环境与测试环境配置相同,只是数量不同,是否能直接换算性能指标呢?答案是否定的!我们只能说,你在测试环境中如果满足了预期性能指标,那生产环境理论上是没有问题的,no more!
3、稳定性测试
采用系统稳定运行情况下能够支持的最大并发用户数,或者日常运行用户数,持续运行一段时间。目标是检测系统能否持续稳定工作。
************解释************
其实,我们在用Jmeter压测的时候,至少都要持续10~15min以上,为什么呢?我们要让TPS稳定下来,这时采集的数据才有效;当然,并不是说15分钟就一定够了,某些情况下需要更长时间的压测才能发现性能问题。
稳定性测试多用于对“系统稳定性”有“强需求”的系统,比如金融类的银行、证券等等。如系统要求3*24小时运行,测试当系统在一定的压力情况下(如CPU资源使用率维持在50%左右),选取复合场景的案例,持续运行3x24小时,观测系统的稳定性状态数据。
还有一种是:测试人员发现,系统在短时间(1个小时、8个小时甚至1天)内都是正常的,但一超过一定时间后就会CPU利用率徒增,或者内存持续增高(疑似内存泄露),这也需要来一场轰轰烈烈的稳定性测试……
4、负载测试
负载测试是通过逐渐增加用户量来观察在不同的负载下系统的指标,以检验系统的行为和特性,以发现系统可能存在的性能问题,并可以检测系统的伸缩性。
也可以确定在什么负载条件下系统性能处于失效状态,目标是获得系统能提供的最大服务级别。
************解释************
负载测试是大家平时做性能测试使用最多的一种类型,甚至有些时候大家嘴里所说的性能测试,就是指的负载测试。说的直白点,就是你写好脚本跑个100并发,发现对于系统来说“洒洒水啦”,监控显示内存和CPU指标都懒得波动一下。那我们加到400试试,加到500呢,1000……?所以,这就是一个“试”的过程,直到系统“失效”!这里的“失效”不一定是指系统宕机,监控显示CPU、Memory利用率超过80%了也叫失效,系统响应时间超过预期的3秒了也叫失效,就看哪个条件先被打破了……
关于如何使用系统性能测试工具和的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
如何使用系统性能测试工具的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于、如何使用系统性能测试工具的信息别忘了在本站进行查找喔。
暂时没有评论,来抢沙发吧~