精华内容
下载资源
问答
  •  并发数是指在同一个时间点,同时请求服务的客户数量。  比如大家常说的:『 我的网站可以承受一万并发。 』在通常情况下指的是:如果同时有一万名用户访问网站,所有人都可以正常获得服务。而不会有超时或连接...

    并发数

      并发数是指在同一个时间点,同时请求服务的客户数量。

      比如大家常说的:『 我的网站可以承受一万并发。 』在通常情况下指的是:如果同时有一万名用户访问网站,所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。

    吞吐率

      吞吐率指的是服务处理请求的效率,计算方式为 ( 总处理请求数 / 总耗时 )。

      HTTP 服务的吞吐率通常以 RPS(Requests Per Second 请求数每秒)作为单位。吞吐量越高,代表服务处理效率就越高。换句话说就是网站的性能越高。

      注意:吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子,并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。

      但是在性能测试中,二者之间通常会呈现出一种关联关系。当并发数增大时,吞吐率通常也会随之上升( 多用户发挥出并行处理优势) 。但在并发数超过某个边界值后,吞吐率则会下降 (用户过多,花在上下文切换的开销急剧增大,又或者内存消耗过多)。

    响应时间

      响应时间指的是用户从发出请求到接收完响应之间的总耗时,它由网络传输耗时、服务处理耗时等多个部分组成。通常以毫秒(ms)作为单位。

      与并发数的关系:一般来说,随着并发数增大,单个用户的响应时间通常会随之增加。这很好理解,餐馆吃饭的人越多,单个顾客等待的时间就越长。

      与吞吐率的关系:更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。

    平均响应时间与百分位响应时间

      平均响应时间指的是所有请求平均花费的时间,如果有100个请求,其中 98 个耗时为 1ms,其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。

      百分位数( Percentile - Wikipedia )是一个统计学名词。以响应时间为例, 99% 的百分位响应时间 ,指的是 99% 的请求响应时间,都处在这个值以下。

      拿上面的响应时间来说,其整体平均响应时间虽然为 2.98ms,但 99% 的百分位响应时间却是 100ms。

      相对于平均响应时间来说,百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间,比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。

    平均响应时间: 所有请求的平均响应时间,取的平均值
    95%percentile : 统计学术语,如果将一组数据从小到大排序,并计算相应的累计百分位,则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为:一组n个观测值按数值大小排列。如,处于p%位置的值称第p百分位数。

    例如有100个请求, 每个请求的响应时间分别是 1-100 平均分布
    平均响应时间: 1-100 的平均值,即 50.5 
    95% percentile : 按从小到大排序,累计第95百分位,也就是 95 (即样本里95% 的数据都不高于这个值)

     

    展开全文
  • 如不清楚吞吐率(RPS)、平均响应时间、99%响应时间的概念请参考:性能测试的几个指标(并发数、吞吐率、响应时间、平均响应时间、99%响应时间) 1、原生Redis的两种主要性能测试指标 在原生的Redis benchm...

    这篇文章总结的是Redis的benchmark源码修改中增加一些性能测试指标所应思考的问题,以及解决问题的方法,权当本渣渣一篇笔记,如果您发现有疏漏错误之处,烦请留言指出!

    如不清楚吞吐率(RPS)、平均响应时间、99%响应时间的概念请参考:性能测试的几个指标(并发数、吞吐率、响应时间、平均响应时间、99%响应时间)

    1、原生Redis的两种主要性能测试指标

    在原生的Redis benchmark性能测试中,只提供了两种主要的测试指标:

    一是RPS(requests per second),即每秒完成的请求数量,反映的是服务器处理请求的吞吐率,这是redis最主要的性能测试指标。

    二是,当你不使用quiet模式输出(不使用-q参数)时,redis会展示出响应时间低于1ms、2ms、3ms...等的请求数占总请求数的百分比。如下图所示。

    下面我们分别说明以上两种测试指标的实现方式:

    首先我们需要知道benchmark.c文件的一个重要的数据结构static struct config。

    本文所讲的性能测试指标的最红显示和实现都是在redis-benchmark.c文件中的showLatencyReport函数中实现,所有修改也都在此函数中进行。

    static struct config {
        aeEventLoop *el;
        const char *hostip;
        int hostport;
        const char *hostsocket;
        int numclients;
        int liveclients;
        int requests;//总请求数
        int requests_issued;
        int requests_finished;//已完成的请求数
        int keysize;
        int datasize;
        int randomkeys;//1表示key值随机化
        int randomkeys_keyspacelen;//key值取0~该值中的随机数
        int keepalive;
        int pipeline;
        int showerrors;
        long long start;//性能测试前记录开始时间
        long long totlatency;//记录性能测试所用的总延时
        long long *latency;//算是一个数组指针,在堆空间开辟,存放每一笔请求的延时,一共有config.requests个
        const char *title;
        list *clients;
        int quiet;
        int csv;
        int loop;
        int idlemode;
        int dbnum;
        sds dbnumstr;
        char *tests;
        char *auth;
    } config;

    主要关注requests、 start、totlatency、*latency!

    (1)RPS的实现:总请求数 / 性能测试的总延时, 即 

    reqpersec = (float)config.requests_finished/((float)config.totlatency/1000);

    (2)响应时间低于1ms、2ms、3ms...等的请求数占总请求数的百分比实现:先对latency数组中的所有请求的响应时间进行从小到大排序,然后遍历,当遍历到响应时间低于1ms时计算响应百分比即可,以此类推。

    原生Redis实现的代码如下(以上两种指标的实现)

    //定义比较函数
    static int compareLatency(const void *a, const void *b) {
        return (*(long long*)a)-(*(long long*)b);
    }
    
    static void showLatencyReport(void) {
        int i, curlat = 0;
        float perc, reqpersec;
    
        reqpersec = (float)config.requests_finished/((float)config.totlatency/1000);
        if (!config.quiet && !config.csv) {
            printf("====== %s ======\n", config.title);
            printf("  %d requests completed in %.2f seconds\n", config.requests_finished,
                (float)config.totlatency/1000);
            printf("  %d parallel clients\n", config.numclients);
            printf("  %d bytes payload\n", config.datasize);
            printf("  keep alive: %d\n", config.keepalive);
            printf("\n");
    
            qsort(config.latency,config.requests,sizeof(long long),compareLatency);//对每条请求的响应时间进行升序排序
            for (i = 0; i < config.requests; i++) {//打印出低于1ms、2ms...等的请求数与总请求数的百分比
                if (config.latency[i]/1000 != curlat || i == (config.requests-1)) {
                    curlat = config.latency[i]/1000;
                    perc = ((float)(i+1)*100)/config.requests;
                    printf("%.2f%% <= %d milliseconds\n", perc, curlat);
                }
            }
            printf("%.2f requests per second\n\n", reqpersec);//打印rps
        } else if (config.csv) {
            printf("\"%s\",\"%.2f\"\n", config.title, reqpersec);
        } else {
        	printf("%s: %.2f requests per second\n", config.title, reqpersec);
    }

    2、添加平均响应时间、99%响应时间

    平均响应时间的实现

    平均响应时间=总响应时间÷总请求数, 公式很简单,但是我们深入思考会发现一些问题:刚开始时我把总响应时间误以为就是上面的totlatency,后来发现不对,这里说清楚区别:

    totlatency是在benchmark测试前后做的一个时间记录差值,即相当于服务器处理完requests条请求所花费的时间,这里面也包含了一部分客户端的函数执行的时间开销(我测试时使用单个客户端连接(即只有一个并发连接)、不使用管道pipelining的时候,测试出来的totlatency是大于【把latency数组中所有请求的响应时间相加所得sum】)。

    所以把latency数组中所有请求的响应时间相加所得sum(我们姑且称之为响应时间之和),跟延迟差值totlatency是不一样的!

    响应时间之和是所有请求的响应时间加到一块,而totlatency只是测试开始前后的一个时间差!但是你千万别以为响应时间之和就应该小于或者等于totlatency(因为你在测试过程中也有客户端的一些函数时间执行开销),我刚开始就是这样认为的!这种情况仅仅是当只有一个并发连接,并且不使用pipeline的时候,它确实是这样的!

    当不止一个并发连接的时候,客户端怎么操作的呢? 假如说有10个并发连接客户端,那么这十个客户端就会逐个发送请求,哪个客户端收到请求回复了就再接着发请求,一直到请求数全部得到回复。这里模拟的是10个客户端并发连接请求的情况。所以这样你会发现:最后算的响应时间之和是远远大于totlatency的!

    当使用pipelining的时候呢?假如-P的参数是5,即一条管道可以一次放5条请求。使用管道其实就是每次客户端把5个请求打包到一起然后一块发给服务器进行处理,服务器处理完之后把五个请求的结果再打包到一起返回给客户端。所以五条请求的响应时间是一样的!那这个时候五条请求的响应时间之和怎么算呢?是五个请求的响应时间全加起来,还是只算一个响应时间呢? 自习想一样,应该是把5个请求看做一个整体,他们的响应时间之和就是其中一个的响应时间。为什么这样算呢?很明显人家五个一起花了5ms,你不能说人家五个一共花了25ms吧! 比如说5个人团购一张券吃饭花了5块,那么每个人实质上是只用了1块,五个人一共用5块,而不是25块。所以当我们使用管道的时候,求平均响应时间和99%响应时间的时候需要整体除以管道大小pipeline。

    99%响应时间的实现

    先排序,然后找到99%所在的位置,把对应位置的响应时间记录即可。

    修改后的实现代码

    static void showLatencyReport(void) {
        int i, curlat = 0;
        float perc, reqpersec;
    
        reqpersec = (float)config.requests_finished/((float)config.totlatency/1000);
        if (!config.quiet && !config.csv) {
            printf("====== %s ======\n", config.title);
            printf("  %d requests completed in %.2f seconds\n", config.requests_finished,
                (float)config.totlatency/1000);
            printf("  %d parallel clients\n", config.numclients);
            printf("  %d bytes payload\n", config.datasize);
            printf("  keep alive: %d\n", config.keepalive);
            printf("\n");
    
            qsort(config.latency,config.requests,sizeof(long long),compareLatency);//对每条请求的响应时间进行升序排序
    		long long sumLatency = 0;//响应时间之和
    	    float avg, percentile99 = (float)config.latency[config.requests - 1]/1000;//平均响应时间、99%响应时间(初始化为最后一个请求的延迟),单位ms
    		int flag = 0;//临时辅助标志位
            for (i = 0; i < config.requests; i++) {
    			sumLatency += config.latency[i];//requests条命令的响应时间总和
    			if(flag == 0 && (float)(i + 1)/config.requests >= (float)0.99) { 
    				percentile99 = (float)config.latency[i]/1000;//99%响应时间
    				flag = 1;
    			}
                if (config.latency[i]/1000 != curlat || i == (config.requests-1)) {//打印出低于1ms、2ms...等的请求数与总请求数的百分比
                    curlat = config.latency[i]/1000;
                    perc = ((float)(i+1)*100)/config.requests;
                    printf("%.2f%% <= %d milliseconds\n", perc, curlat);
                }
            }
    		avg = (float)sumLatency/((float)config.requests*1000);//requests条请求的平均响应时间,单位是ms
    		if(config.pipeline > 1) {//考虑使用管道的特殊情况
    			avg /= config.pipeline;
    			percentile99 /= config.pipeline;
    		}
    		//printf("总延迟: %lldms  响应时间之和: %lldms\n", config.totlatency, sumLatency/1000);
            printf("%.2f requests per second | average response time: %.2fms | 99%%response time: %.2fms \n\n", reqpersec, avg, percentile99);
        } else if (config.csv) {
            printf("\"%s\",\"%.2f\"\n", config.title, reqpersec);
        } else {
        	printf("%s: %.2f requests per second\n", config.title, reqpersec);
        }
    }

     

     

     

     

     

    展开全文
  • 压测十二个小时之后的效果平均响应时间和TPS如下图: 整个场景是要录入一个贷款的客户信息,使用50用户并发压测12小时以上;其中输入完客户信息后,点击保存按钮这个操作,随着压测的进行,响应时间越来越慢。并且...

    1. 现象

    最近做的性能测试中,有一支交易随着压测时间的增加,响应时间越来越慢,TPS越来越低 。压测十二个小时之后的效果平均响应时间和TPS如下图:
    在这里插入图片描述
    在这里插入图片描述
    整个场景是要录入一个贷款的客户信息,使用50用户并发压测12小时以上;其中输入完客户信息后,点击保存按钮这个操作,随着压测的进行,响应时间越来越慢。并且停止压测后过一段时间,即使使用一个用户进行同样的操作,响应时间还是很慢,并不会恢复到最初压测的响应时间。整个场景中只有这一个操作会越来越慢,其他操作响应时间很稳定。

    2. 定位问题

    首先排除了物理资源和中间件引起的问题,如果是这些问题,整支交易的所有操作应该都会越来越慢,而不会只体现在这一个方法上。而且通过监控资源,服务器CPU、内存、IO都不存在瓶颈。初步判断是该方法本身出现了问题,肯定出现了资源占用后不能释放的问题,导致随着压测的进行,响应时间越来越慢,并且停止压测一段时间后,资源也不会释放。
    开发同事通过对该方法的调试,并没有发现明显的问题,于是只能使用排除法,分步注释该方法的代码块,最后把整个方法体完全注释之后,只返回null结果,压测一段时间后,问题仍然存在。又判断问题不是出现在方法本身,有可能是在方法的上一层,或者是传入的参数对象有问题。开发使用的是Spring架构,页面表单的超大型对象数据直接提交到后台时,系统框架和spring框架解析此对象时可能存在全局变量,随着压测时间的增加,此变量大小线性递增,因此导致了响应时间越来越慢。

    3. 调优

    修改了页面对象提交到后台的数据格式,优化前为整个表单直接提交,优化后为整个页面数据用JSON字符串格式提交到后台,不使用Spring自带的方式解析对象,而是自己使用gjson实现。改完之后再压测,问题完美的解决了,所有操作平均响应时间都是趋于平稳的。

    展开全文
  • 挑战 :: 创建具有两个端点的Web服务器: 端点1(/ process / *): ... 具体来说,响应JSON必须包含以下字段 ... 自服务器启动以来发出的请求总数和平均响应时间(按HTTP方法分类)。 主动请求的数量,按H
  • 首先,定义各参数 samples:总请求数 duration:持续时间(基于jmeter原理,实际持续时间可能大于填写持续时间) thread:并发数 totalrt:所有请求的响应时间之和 1.TPS:每秒事务数 ...2.平均响应时间(...

    首先,定义各参数

    samples:总请求数

    duration:持续时间(基于jmeter原理,实际持续时间可能大于填写持续时间)

    thread:并发数

    totalrt:所有请求的响应时间之和

    1.TPS:每秒事务数

    在jmeter中,大多数情况下,Throughput吞吐率被认为等于TPS

    Throughput=samples/duration=TPS 公式一

    2.平均响应时间(avgrt)

    avgrt=totalrt/samples 公式二

     在部分测试中,TPS被认为等于并发数除以平均响应时间,即

    TPS=thread/avgrt 公式三

    下面从数学公式角度讨论公式一与公式三是否等价

    公式一 TPS=samples/duration
    公式三 TPS=thread/avgrt=thread/(totalrt/samples)=(samples*thread)/totalrt

    假定公式一与公式三等价,即

    samples/duration=(samples*thread)/totalrt
    duration=totalrt/thread

    由上可知,理论上,在不考虑预热时间(ramp-up),而各线程又能在持续时间结束时立即结束的情况下,公式一和公式三可以近似等价;其他情况均有误差,且根据情况的不同,误差大小不等

    展开全文
  • 并发数 = QPS*平均响应时间 QPS(TPS):每秒钟request 每秒查询率QPS:对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,即每秒请求数,即最大谈吐能力。并发数:并发数和QPS是不同的概念,一般...
  • 当时,面试官问我:如何找到并发数、平均响应时间、tps的最佳平衡点? 初次听到这个,是不是一脸懵逼? 先回顾下基础,性能测试常用的指标有三个:并发、响应时间、tps 并发:跑道里参加赛跑的人数(这里的并发是...
  • grep '15:10:00' daily-2015-12-20.log| grep 'RESPONSE'|awk 'BEGIN {t = 0;} {split($10,a,"=");t+=a[2];} END {print t/NR;}'其中NR代表已经处理的行数,常见的awk内置数据见下表 属性 说明 $0 ...
  • Jmeter平均响应时间和TPS的计算方法

    万次阅读 2018-05-19 17:35:00
    Jmeter的Throughput和平均RT的计算 1.TPS:每秒处理的事务数,jmeter的Throughput为吞吐率(请求数/秒),在加了事务控制器后,TPS=Throughput ...宏观上:TPS=并发数/响应时间,jmeter的Throughput = (number o...
  • 并发数 = QPS*平均响应时间

    千次阅读 2017-04-28 16:48:00
    并发数 = QPS*平均响应时间 QPS(TPS):每秒钟request 每秒查询率QPS:对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,即每秒请求数,即最大谈吐能力。 并发数:并发数和QPS是不同的...
  • kibana制作nginx平均响应时间的dashboard

    千次阅读 2018-02-11 14:32:21
    1.平均响应时间涉及到数值的计算,所有首先应该保证nginx的响应时间upstream_response_time字段在kibana上nginx的索引中为number类型,而该字段的类型需要在logstash的filter中显式的指定 mutate { convert =&...
  • 在小编所经历的两个项目中压测关注的重要指标是平均响应时间和TPS,lr这个软件分析结果给指标有很多,但是检验一个软件运行的速度和负载能力,平均响应时间和TPS是大多数验收人员最为关注的。 平均响应时间:就是...
  • 并发数、QPS、平均响应时间三者之间关系  上图横坐标是并发用户数。绿线是CPU使用率;紫线是吞吐量,即QPS;蓝线是时延。  开始,系统只有一个用户,CPU工作肯定是不饱合的。一方面该服务器可能有多个cpu...
  • 10分位值 表示有10%的数据小于此数值,反映市场的低端水平。 25分位值 表示有25%的数据小于此数值,反映市场的较低端水平。 50分位值(中位值) 表示有50%的数据小于此数值,反映市场的中等水平。...
  • 整理了下Jmeter的Throughput和平均RT的计算,如下公式: ...RT=所有sample样本响应时间和/样本个数 1.TPS:每秒处理的事务数,jmeter的Throughput为吞吐率(请求数/秒),在加了事务控制器后,TPS=Throughput ...
  • TPS和事物的平均响应时间 怎么个关系,有关系吗 问者:每秒处理的事物数和事物的平均响应时间 怎么个关系,有关系吗 kaku21:举个例子:一个高速路 有10个入口,每个入口每秒钟只能进1辆车,请问1秒钟最多能进几...
  • 事物平均响应时间

    2011-10-20 15:08:15
    看老白的DBA日记中多记提到 事物平均响应时间 。找找是怎么算出来的:avg response time =一个事件的时间/所占百分比/60/报告的时间/每秒的事物数*100最后得到一个S为单位的时间!一个事件的时间/所占百分...
  • 3、统计某路由平均响应时间($upstream_response_time参数): grep "keyword" access.log | awk '{print $NF}' | grep -P '\d{3}?$' | awk '{sum += $0;}END {if(sum==0)print 0;else print sum/NR}' 用if...
  • TPS,QPS,系统吞吐量,并发量,平均响应时间 TPS:每秒处理完的事务数量,在分布式系统中,一次事务可能包含多次请求。 QPS:每秒处理完的请求数量。 并发量:系统能同时处理的请求数。 平均响应时间:一次请求处理...
  • 在网上看到一篇文章,tps 与 事务平均响应时间关系对答。可以帮助能更清楚的了解二者之间的关系。   问者:每秒处理的事务数和事务的平均响应时间 怎么个关系,有关系吗 kaku21:举个例子:一个高速路 有10...
  • 在跑场景时,会碰到这样一种情况,使用LoadRunner测试出来的响应时间比实际使用浏览器感受到的时间要长,例如,实际使用浏览器打开一个系统时只需要1~2秒,而使用LoadRunner跑一个用户所得出的结果可能是远远超过实际...
  • 1、广义并发:广义的并发实际上是在一个时间内操作事务的虚拟用户,是存在。 对地铁这个系统而言,每个时间都有新来的人,也有走的人,大家做的事情基本都相同,乘地铁。假定某个时刻地铁大厅中有10000人,检票口...
  • 然后使用 JMeter 进行接口的调用,在 聚合报告 中发现平均响应时间偏长;如图: 如果有用户反映某功能响应时间太长了,别着急,根据下面的方法进行排查,绝对方便又快速的找到问题原因。 Arthas 问题排查: 首先需要...
  • summary report里面给出的,是整个测试过程中,这个事务的平均响应时间,而average reponse time图表里面,默认显示的是“图中所标示的那些点的平均响应时间”。所以两者当然是不一致的。你可以在legend colu
  • 运维组在zabbix中需要获取缓存节点中每台ats上的客户端平均响应时间这个指标,来向用户展示我们缓存服务的QoS指标,如何实现呢? 思路 需要理顺traffic_top.cc的源码实现细节: 首先命令行运行 tstop 从下图...
  • TPS和事务响应时间的关系、计算公式

    万次阅读 多人点赞 2016-09-08 10:24:11
    例子:一个高速路有10个入口,每个入口每秒钟只能进1辆车 1、请问1秒钟最多能进几辆车?  TPS=10 ... TPS = 10,reponse time = 1 (10个为一等份,分成两等份,平均tps (10/1+10/2)/2=7.5 平均响应
  • Oracle数据库中平均事务响应时间的计算公式
  • loadrunner平均事务响应时间

    千次阅读 2015-12-29 12:17:33
  • LoadRunner中响应时间与事物时间详解11
  • sampleresult.default.encoding

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 146,374
精华内容 58,549
关键字:

平均响应时间