zoukankan      html  css  js  c++  java
  • jmeter性能测试整理总结

    1、最长关注的几项性能指标:

    •  QPS(TPS):每秒钟处理request/事务的数量。

    • 并发用户数: 系统同时处理的request/事务的用户数量。

    • 响应时间(Response Time,RT): 可以理解为服务器处理响应的耗时,一般取平均响应时间。

    2.并发用户数常见的评估方法

    对于已有系统来说,评估并发用户数,可以从如下几个方面去做数据参考。

    • 1. 系统用户数

    • 2. 在线用户数

    • 3. 并发用户数

    一般来说,可选取高峰时刻,在一定时间内使用系统的人数,这些人数可认为是在线用户数,而并发用户数可以取其中8%~15%的比例基数,例如在1个小时内,使用系统的在线用户数为10万,那么取8%~15%(即8000~1.5万)作为并发用户数就基本足够了。

    3、作为一个用户你可以对吞吐量(QPS、TPS)、并发用户数这些毫不关心,但响应时间却是用户感受系统性能的主要体现。从用户角度来说,软件性能就是软件对用户操作的响应时间。说得更明确一点,对用户来说,当用户单击一个按钮,发出一条指令或在web页面上单击一个链接,从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来,这个过程所消耗的时间就是用户对软件性能的直观印象。

    `响应时间=呈现时间+网络传输时间+系统处理时间

    1. 呈现时间

    呈现时间主要是指前端的响应时间,这部分时间主要取决于客户端而非服务端。当然,这个呈现时间也不能全怪罪客户端身上!它还和承载它的操作系统有关,以及电脑硬件比如cpu 、内存有关。

    2. 网络传输时间

    千万不要忽视数据传输时间。试想一下,如果你要寄信给你一个远方的朋友,你想是什么影响你将信息传递给远方的朋友?不是你写信的过程(如果你写的信不像书一样厚的话),也不是你朋友读信的过程,而是送信的过程。

    你的带宽是多少?有没有考虑网络延迟? 互联网是个网,就是算是相同的起点与终点,它有可能走的不同的路线。

    这也是为什么我们在一般做性能测试时,一般要强调要在局域网中进行

    3. 系统处理时间

    在进行性能测试时,呈现时间和数据传输时间通常都是我们很难控制的,用户使用的电脑千差万别,用户的网络状况也是千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短。

    3.3 系统吐吞量(QPSTPS)

    QPS:全名 Queries Per Second,意思是“每秒查询率”,是一台服务器每秒能够响应的查询次数,简单的说,QPS = req/sec = 请求数/秒。比如执行了select操作,相应的QPS就会增加,它代表的是服务器的机器的性能最大吞吐能力。

    计算QPS的常用公式:

    QPS(TPS)= 并发数/平均响应时间

    另外,关于峰值QPS计算方式,一般也可参照2/8原则(供参考,并非一定):

    • 原理:每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间

    • 公式:( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)

    • 问:每天300w PV 的在单台机器上,这台机器需要多少QPS?

    • 答:( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

    • (这种方式计算我个人觉得,更像是计算TPS,因为PV是页面访问量。一个页面访问,可能包括多个请求在里面)

    TPS即 Transactions Per Second 的缩写,指每秒处理的事务数量。一个事务是指一个客户机向服务器发送请求然后服务器做出回应的过程。

    TPS 的过程包括:客户端请求服务端、服务端内部处理、服务端返回客户端。

    关于TPS的获取评估方式,对于已有系统来说:可选取高峰时刻,在一定时间内(如3-10分钟),获取系统总业务量,计算单位时间(秒)内完成的笔数,乘以2-5倍作为峰值的TPS,例如峰值3分钟内处理订单18万笔,平均TPS是1000,峰值TPS可以是2000-5000。

    对于新系统来说,因为没有历史数据作参考,一般建议通过业务部门进行评估。

    (有些资料上TPS也是,按照上面的方法计算的)

    QPS和TPS之间的区别,也是很多新手刚接触时容易搞混的,那他们之间到底有什么区别和联系。

    一般来说,QPS基本类似于TPS,但不同的是,对于一个页面的一次访问,会形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就会计入“QPS”之中。

    如果是对一个接口(单场景)压测,且这个接口内部不会再去请求其它接口,那么TPS=QPS。

    例如:访问一个 Index 页面会请求服务器 3 次,包括一次 html,一次 css,一次 js,那么访问这一个页面就会产生一个“TPS”,产生三个“QPS”。

    对于衡量单个接口服务的处理能力,一般采用QPS比较多,一般如果衡量事务业务场景的处理能力一般则采用TPS。

    注:Jmeter聚合报告中,Throughput是用来衡量吞吐量,通常是由TPS来表示。

    最后,几点小结和建议:

    • 系统的性能一般由TPS决定,跟并发用户数没有太大直接关系。

    • 系统的最大TPS是一定的(在一个范围内),但并发用户数不一定,可以调整。

    • 建议性能测试的时候,不要设置过长的思考时间,以最坏的情况下对服务器施压。

    • 一般情况下,大型系统(业务量大、机器多)做压力测试,10000~50000个用户并发,中小型系统做压力测试,5000个用户并发比较常见。

    • 通过系统的监控工具,发现系统的性能瓶颈,通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等,而缓存系统容易发生瓶颈的地方是内存,储存型系统则是I/O。

  • 相关阅读:
    c#中对rgb的使用
    编写高质量代码改善C#程序的157个建议——建议141:不知道该不该用大括号时,就用
    编写高质量代码改善C#程序的157个建议——建议140:使用默认的访问修饰符
    编写高质量代码改善C#程序的157个建议——建议139:事件处理器命名采用组合方式
    编写高质量代码改善C#程序的157个建议——建议138:事件和委托变量使用动词或形容词短语命名
    编写高质量代码改善C#程序的157个建议——建议137:委托和事件类型应添加上级后缀
    编写高质量代码改善C#程序的157个建议——建议136:优先使用后缀表示已有类型的新版本
    编写高质量代码改善C#程序的157个建议——建议135: 考虑使用肯定性的短语命名布尔属性
    编写高质量代码改善C#程序的157个建议——建议134:有条件地使用前缀
    编写高质量代码改善C#程序的157个建议——建议133:用camelCasing命名私有字段和局部变量
  • 原文地址:https://www.cnblogs.com/fkkk/p/11957566.html
Copyright © 2011-2022 走看看