精华内容
下载资源
问答
  • 如不清楚吞吐率(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);
        }
    }

     

     

     

     

     

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

    并发数

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

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

    吞吐率

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

      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% 的数据都不高于这个值)

     

    展开全文
  • JMeter 聚合报告 90%响应时间

    千次阅读 2018-04-20 01:00:09
    90%的响应时间理解 官方解释:90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this. 有10个数: 1、2、3、4、5、6、7、8、9、10 按由大到小将其排列。 ...

    90%的响应时间理解

    官方解释:90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.

    有10个数:

    1、2、3、4、5、6、7、8、9、10 按由大到小将其排列。

    求它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line 就是9

    一组数由小到大进行排列,找到他的第90%个数(假如是12),那么这个数组中有90%的数将小于等于12 ,也就是90%请求响应时间不会超过12 秒。

    展开全文
  • Blog:http://jackei.cnblogs.com描述性统计与性能结果分析——《LoadRunner 没有告诉你的》之一 LoadRunner中的...为什么要有90%用户响应时间?因为在评估一次测试的结果时,仅仅有平均事务响应时间是不够的。为...

    Blog:http://jackei.cnblogs.com

    描述性统计与性能结果分析——《LoadRunner 没有告诉你的》之一

     

    LoadRunner中的90%响应时间是什么意思?这个值在进行性能分析时有什么作用?本文争取用最简洁的文字来解答这个问题,并引申出“描述性统计”方法在性能测试结果分析中的应用。

    为什么要有90%用户响应时间?因为在评估一次测试的结果时,仅仅有平均事务响应时间是不够的。为什么这么说?你可以试着想想,是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求?

    假如有两组测试结果,响应时间分别是 {1,3,5,10,16} 和 {5,6,7,8,9},它们的平均值都是7,你认为哪次测试的结果更理想?

    假如有一次测试,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒,你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信?

    为了解答上面的疑问,我们先来看一张表:

    在上面这个表中包含了几个不同的列,其含义如下:

    CmdID   测试时被请求的页面

    NUM      响应成功的请求数量

    MEAN    所有成功的请求的响应时间的平均值

    STD DEV      标准差(这个值的作用将在下一篇文章中重点介绍)

    MIN              响应时间的最小值

    50 th(60/70/80/90/95 th)          如果把响应时间从小到大顺序排序,那么50%的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义

    MAX      响应时间的最大值

     

    我想看完了上面的这个表和各列的解释,不用多说大家也可以明白我的意思了。我把结论性的东西整理一下:

    1.      90%用户响应时间在 LoadRunner中是可以设置的,你可以改为80%或95%;

    LoadRunner Analysis-〉Tools-〉Options-〉General-〉Summary Report下修改Transaction Percentile

    2.      对于这个表,LoadRunner中是没有直接提供的,你可以把LR中的原始数据导出到Excel中,并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况;

    3.      从上面的表中来看,对于Home Page来说,平均事务响应时间(MEAN)只同70%用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内,那么从平均事务响应时间来看是满足的,但是实际上有10-20%的用户请求的响应时间是大于这个值的;对于Page 1也是一样,假如我们确定对于Page 1 的请求应该在3秒内得到响应,虽然平均事务响应时间是满足要求的,但是实际上有20-30%的用户请求的响应时间是超过了我们的要求的;

    4.      你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th,并利用Excel的图表功能画一条曲线,来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现,那个最大值的出现几率只不过是千分之一甚至万分之一,而且99%的用户请求的响应时间都是在性能需求所定义的范围之内的;

    5.      如果你想使用这种方法来评估系统的性能,一个推荐的做法是尽可能让你的测试场景运行的时间长一些,因为当你获得的测试数据越多,这个响应时间的分布曲线就越接近真实情况

    6.      在确定性能需求时,你可以用平均事务响应时间来衡量系统的性能,也可以用90%或95%用户响应时间来作为度量标准,它们并不冲突。实际上,在定义某些系统的性能需求时,一定范围内的请求失败也是可以被接受的;

    7.      上面提到的这些内容其实是与工具无关的,只要你可以得到原始的响应时间记录,无论是使用LoadRunner还是JMeter或者OpenSTA,你都可以用这些方法和思路来评估你的系统的性能。

    事实上,在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说,性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识,例如数学和统计学,来帮助我们更好的分析性能数据,找到隐藏在那些数据之下的真相。

    描述性统计与性能结果分析(续) ——《LoadRunner 没有告诉你的》之二

    数据统计分析的思路与分析结果的展示方式是同样重要的,有了好的分析思路,但是却不懂得如何更好的展示分析结果和数据来印证自己的分析,就像一个人满腹经纶却不知该如何一展雄才

    一图胜千言,所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。

    在这张图中,我们继续使用了上一篇文章——《描述性统计与结果分析》一文中的方法,对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对Google.com 首页进行测试得来的,在测试中分别使用10/25/50/75/100 几个不同级别的并发用户数量。通过这张图表,我们可以通过横向比较和纵向比较,更清晰的了解到被测应用在不同级别的负载下的响应能力。

    这张图所使用的数据与第一张图一样,但是我们使用了另外一个视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒,分别表示了在整个测试过程中,响应时间在0-2000毫秒范围内的事务数量占成功的事务总数的百分比,响应时间在2001-5000毫秒范围内的事务数量占成功的事务总数的百分比,响应时间在5001-10000毫秒范围内的事务数量占成功的事务总数的百分比,以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数的百分比。

    这几个时间范围的确定是参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准,只要得到企业内的承认就可以。所谓的“2-5-10原则”,简单说,就是当用户能够在2秒以内得到响应时,会感觉系统的响应很快;当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;当用户在5-10秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;而当用户在超过10秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求。

    那么从上面的图表中可以看到,当并发用户数量为10时,超过95%的用户都可以在5秒内得到响应;当并发用户数量达到25时,已经有80%的事务的响应时间处在危险的临界值,而且有相当数量的事务的响应时间超过了用户可以容忍的限度;随着并发用户数量的进一步增加,超过用户容忍限度的事务越来越多,当并发用户数到达75时,系统几乎已经无法为任何用户提供响应了。

    这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。

    Note:上面两个图表中的数据,主要通过Excel 中提供的FREQUENCY,AVERAGE,MAX,MIN和PERCENTILE几个统计函数获得,具体的使用方法请参考Excel帮助手册。

    展开全文
  • 【性能概念】99线响应时间

    千次阅读 2019-09-03 20:46:23
    随着吞吐量的增大,响应时间会逐渐变长,当达到最大吞吐量之后,响应时间会开始急剧飙升,尤其是后面堆积队列中等待的请求 如果仅仅是关注平均值,由于大部分请求的响应时间还是相对较短,有一部分接口可能是10ms...
  • 我在中国外汇交易中心工作过一段时间,当时有个专业的Loadrunner测试团队,他们的测试结果:为什么100个用户的响应时间反而比50个用户的响应时间更短。 分析:首先这肯定是一种不正常的现象,因为按照常理用户越多...
  • 【JMeter】聚合报告中99%line的理解

    千次阅读 2020-11-12 17:04:15
    聚合报告中,经常参考99%line 这个指标,一直理解为99%的用户平均响应时间,直到有次测试发现,99%line 为2s,平均数只有200ms,才发现一直对它有错误的理解。 先看官方文档对这个指标的解释 90%的样本采集时间不...
  • 删除文件时总是要卡在99%一段时间解决方法 对我的电脑无效的解决办法 我去百度搜索了一下,用的是这种解决办法 dism /online /Cleanup-Image /RestoreHealth & sfc /SCANNOW & pause 但是对我没有用 对我...
  • loadrunner 中的90%的请求响应时间

    万次阅读 2014-12-04 12:54:31
    描述性统计与性能结果分析-LoadRunner,学到了平均相应时间和90%事务相应时间的关系,其中平均响应时间满足了但是未必符合性能要求,有时候还要看90%事务相应时间。  具体参看以下内容:  LoadRunner中的90%...
  • 服务响应时间与分布(p99指标)

    千次阅读 2020-10-12 20:32:52
    分析服务响应时间分布,如:均值、中位值、P95值、P99值等如何计算 平均值 我们考察一个服务器的性能,除了QPS数据外,还会考察响应时间,当服务器负载增高时,往往会伴随着响应时间的增长,但是这个值该如何度量...
  • 10分位值 表示有10%的数据小于此数值,反映市场的低端水平。 25分位值 表示有25%的数据小于此数值,反映市场的较低端水平。 50分位值(中位值) 表示有50%的数据小于此数值,反映市场的中等水平。...
  • 90%用户响应时间

    千次阅读 2006-08-18 20:11:00
    LR在场景执行完了会出个报告,其中有两项,事务的平均响应时间是多少 和 90%的用户事务响应时间多少,虽然我用的最多的还是平均响应时间,但我总认为90%的那个数更符合实际,因为90%意味这大部分都是这样.但前天我发现这...
  • Aggregate Report配置可以控制聚合报告的内容,控制90%用户响应时间,或者99.9999的用户响应时间 jmeter的-e -o报告默认显示90%/95%/99%的用户响应时间,可以修改为其他值,比如99.9999%等 ...
  • LoadRunner中的90%响应时间是什么

    千次阅读 2011-07-02 23:13:39
    LoadRunner中的90%响应时间是什么意思?这个值在进行性能分析时有什么作用?本文争取用最简洁的文字来解答这个问题,并引申出“描述性统计”方法在性能测试结果分析中的应用。 为什么要有90%用户响应时间?因为在...
  • CAD打开慢,卡在99%

    千次阅读 2014-12-29 17:27:00
     打开AutoCAD的时候,软件停留在加载99%,点击出现[无法响应],要么等待,要么强行关闭,若平时正常关闭CAD时也异常缓慢。 原因分析  破解版,没有联网就激活了。CAD默认启动需要联网,所以就卡在那。硬件上的...
  • 滤波器的截止频率是怎么影响信号的响应时间
  • 响应时间过长问题分析

    万次阅读 2019-07-18 16:29:49
    响应时间是性能评估的一个重要指标,会对最终用户产生直接影响,一个产品是快是慢,响应时间是最直观的感受。 因此面对响应时间长的问题,一定想尽办法消灭它。 以下定位方法是针对比较典型的nginx+tomcat应用架构。...
  • 上游(后端)的平均响应时间是多少? HTTP状态为200、404的响应数是多少? 不同类别的HTTP状态-2xx,5xx中有多少个响应? 在不到300毫秒的时间内,上游响应了多少个请求? 从300毫秒到500毫秒有多少? 上游处理...
  • 事务的响应时间与子请求响应时间关系
  • Java面试题大全(2020版)

    万次阅读 多人点赞 2019-11-26 11:59:06
    发现网上很多Java面试题都没有答案,所以花了很长时间搜集整理出来了这套Java面试题大全,希望对大家有帮助哈~ 本套Java面试题大全,全的不能再全,哈哈~ 一、Java 基础 1. JDK 和 JRE 有什么区别? JDK:Java ...
  • 这个时间要比北京时间慢八个小时 Cache-Control Cache-Control 是一个通用标头,他可以出现在请求标头和响应标头中,Cache-Control 的种类比较多,虽然说这是一个通用标头,但是有一些特性是请求标头具有的,有一些...
  • MySQL响应时间监测

    千次阅读 2017-11-26 21:11:00
    大家习惯于以响应时间来衡量性能表现,实际响应时间指的正是从接收请求开始到发送响应之间的时间跨度。我们通常的做法是在代码里加入日志计算时间,这个是不准确的,该方式只是单单计算应用程序内部经过的时间,没有...
  • 数据结构与算法之美-问题收集

    千次阅读 2019-11-15 21:42:17
    更多详情:https://blog.csdn.net/william_n/article/details/100174887 1.问题收集 ... 1.没理解统计业务接口99%响应时间啥意思 作者回复: 举一个例子 你写了一个接口 每天...
  • 99%的人都理解错了HTTP中GET与POST的区别

    万次阅读 多人点赞 2019-03-02 23:43:55
    而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。 也就是说,GET只需要汽车跑一趟就把货送到了,而POST得跑两趟,第一趟,先去和服务器打个招呼“嗨...
  • 小甲鱼零基础入门学习python笔记

    万次阅读 多人点赞 2019-08-14 11:06:30
    小甲鱼老师零基础入门学习Python全套资料百度云(包括小甲鱼零基础入门学习Python全套视频+全套源码+全套PPT课件+全套课后题及Python常用工具包链接、电子书籍等)请往我的资源...
  • Jmeter 90%Line 百分位数正确含义

    千次阅读 2020-11-12 15:03:15
    错误理解:90%Line 理解为90%用户的平均响应时间。 90%Line参数正确的含义: 90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this. “90%的样品没有...
  • Oracle数据库中平均事务响应时间的计算公式
  • 系统的常见性能指标 1.基础的日志文件 最基础的,可以从日志文件了解程序 2.响应时间和吞吐量 常用的网站性能测试指标有:...响应时间,反应了系统的快慢,指执行一个请求从开始到最后收到响应数据所花费的总...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 86,933
精华内容 34,773
关键字:

99%响应时间