对于应用服务器与数据库服务器的测试,关注的性能指标分别是什么呢

对于应用服务器与数据库服务器的测试,关注的性能指标分别是什么呢,第1张

最重要的性能指标就应该是SPEC web99。SPEC web99为Web用户提供了用于评测系统用作Web服务器能力的最客观、最具代表性的基准; 而如果是选购应用服务器,关注SPEC jbb200和SAP SD这两个指标就能知道大概其了,因为SPEC jbb200是专门用来评估服务器系统运行Java应用程序能力的基准测试,而SAP SD 的测试结果为客户提供了基本的规模建议。

QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。互联网中,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

TPS:是TransactionsPerSecond的缩写,也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。QPS vs TPS:QPS基本类似于TPS,但是不同的是,对于一个页面的一次访问,形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“QPS”之中。如,访问一个页面会请求服务器2次,一次访问,产生一个“T”,产生2个“Q”。

响应时间:执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。响应时间RT(Response-time),是一个系统最重要的指标之一,它的数值大小直接反应了系统的快慢。

并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。

系统的吞吐量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高,外部系统接口、IO速度越慢,系统吞吐能力越低,反之越高。系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间。

QPS(TPS):(Query Per Second)每秒钟request/事务 数量
并发数: 系统同时处理的request/事务数
响应时间: 一般取平均响应时间
理解了上面三个要素的意义之后,就能推算出它们之间的关系:

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

我们通过一个实例来把上面几个概念串起来理解。按二八定律来看,如果每天 80% 的访问集中在 20% 的时间里,这 20% 时间就叫做峰值时间。

1、每天300w PV 的在单台机器上,这台机器需要多少QPS?
( 3000000 08 ) / (86400 02 ) = 139 (QPS)

2、如果一台机器的QPS是58,需要几台机器来支持?
139 / 58 = 3

对同一个系统而言,支持的线程数越多,QPS越高。假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 125
多线程场景,如果把服务端的线程数提升到2,那么整个系统的QPS则为 2(1000/80) = 25, 可见QPS随着线程的增加而线性增长,那QPS上不去就加线程呗,听起来很有道理,公司也说的通,但是往往现实并非如此。

我们想象的QPS、RT关系如下

实际的QPS、RT关系如下

刚好消耗完服务器的瓶颈资源的临界线程数,公式如下

在达到最佳线程数的时候,线程数量继续递增,则QPS不变,而响应时间变长,持续递增线程数量,则QPS开始下降。
每个系统都有其最佳线程数量,但是不同状态下,最佳线程数量是会变化的。
瓶颈资源可以是CPU,可以是内存,可以是锁资源,IO资源:超过最佳线程数-导致资源的竞争,超过最佳线程数-响应时间递增。

打开APP
Mar三月
关注
TP99 TP999 原创
2022-03-11 11:48:04
1点赞

Mar三月
码龄6年
关注
带你理解下啥是tp99
我们现在已有认知:一次请求从前端到后端的请求时间,这个接口的总时间=在网络耗时+服务端处理的耗时。这个通常是一个普通人可以关注到的点,也是最外漏的点。
但是刨去网络耗时外部原因,有没有对服务端处理真正的耗时进行过研究。
服务端耗时=请求到达服务端,服务端开始处理,到最后响应的时间。
接口tp99耗时:就是衡量接口性能的指标,tp99越低,接口性能越好。根据对一个 接口反复测试耗时时间,接口的平均耗时其实就约等于tp99耗时,拿着个值就可以去监控上配置,当接口的tp99耗时超过 这个值,就会触发报警,因为 我们认为接口超过to99耗时是不合理的。可以配置此项报警监控。
接口tp99耗时,就是帮助我们监控接口的一个指标,一旦超出了这个指标,我们就认为我们接口是存在问题的,此时我们需要对接口的内部逻辑 进行下梳理,看看到底那块耗时,我们是否能优化,
目前有很多 成熟的系统,对接口进行了各种监控,因为这是一项通用的指标,因此会被抽出来,他们会对接口的 性能、可用率进行监控。
目前还有很多成熟的系统,能对服务器进行监控,这也是一项通用的指标,因此会被抽出来,他们会对机器本身的指标cpu、磁盘、系统负载进行监控。
以上只是对单个服务进行了接口、机器本身的监控,实际在微服务时代由于各个服务之间相互调用,因此又产生了一项新的监控指标,就是监控服务和服务调用之间的调用链,这些监控都是服务上线之后需要去监控的,能帮助开发人员省去很多时间,有利于线上出问题后第一时间关注,
以下是专业的对tp99的说明
TP指标: TP50:指在一个时间段内(如5分钟),统计该方法每次调用所消耗的时间,并将这些时间按从小到大的顺序进行排序,取第50%的那个值作为TP50 值;配置此监控指标对应的报警阀值后,需要保证在这个时间段内该方法所有调用的消耗时间至少有50%的值要小于此阀值,否则系统将会报警。
TP90,TP99,TP999与TP50值计算方式一致,它们分别代表着对方法的不同性能要求,TP50相对较低,TP90则比较高,TP99,TP999则对方法性能要求很高
The tp90 is a minimum time under which 90% of requests have been served
tp90 = top percentile 90
Imagine you have response times:
10s
1000s
100s
2s
Calculating TP is very simple:
1 Sort all times in ascending order: [2s, 10s, 100s, 1000s]
2 find latest item in portion you need to calculate
21 For TP50 it will be ceil(405) = 2 requests You need 2nd request
22 For TP90 it will be ceil(409) = 4 You need 4th request
3 We get time for the item found above TP50=10s TP90=1000s
可以认为 TP90的意思是保证90%请求都能被响应的最小耗时。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13258315.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-06-27
下一篇 2023-06-27

发表评论

登录后才能评论

评论列表(0条)

保存