性能测试 - 响应 vs 延迟 vs 吞吐量 vs 负载 vs 扩展性 vs 压力 vs 健壮性

本文译自Niraj Bhatt 所著 Performance Testing - Response vs. Latency vs. Throughput vs. Load vs. Scalability vs. Stress vs. Stress vs. Robustness. 原文地址:https://nirajrules.wordpress.com/2009/09/17/measuring-performance-response-vs-latency-vs-throughput-vs-load-vs-scalability-vs-stress-vs-robustness/

  通常我发现当人们谈起性能测试时,总是含混不清及概念混淆的。一些人仅仅把性能测试限制在响应时间,反之,另一些人则试图用性能测试来覆盖测试活动的各个方面。 在这篇博文中,有关这两种看法之间的区别,我将阐述一些自己的观点。在性能测试领域,你会经常听到的一些名词有——响应时间,延迟时间,吞吐量,负载,扩展性,压力,健壮性等等。在下面的文章中,我会试着解释这些名词同时简要介绍如何测量评估他们。

  响应时间(Response Time)——系统在接受到一个请求后,处理这个请求所需要花费的时间。比如你有一个API,你想知道这个API执行一次调用需要花费多少时间,你事实上就是在测量响应时间。 那么到底怎么测量响应时间呢?简单来说,使用一个码表(System.Diagnostics)——在调用之前启动它,在接收到响应后停止。这里的时间间隔将会非常小,所以推荐的做法是循环调用这个API,比如说1000次。 或者如果可能的话在调用时传入负载参数(输入/输出 有KBs/MBs/GBs之分。比如,返回不同长度的用户数组)

  延迟时间(Latency)——最简单的解释是,它是远程调用时的响应时间,例如你想访问的是一个网络服务或一张网页。 除了服务器需要的处理响应的时间外,还需要耽搁一些时间用来将请求从客户端传到服务器。那么说到延迟时间,就是刚刚说到的耽搁的时间。而这对于托管网络服务/网页 的远程数据中心来说,是一个很大的问题。想象一下你从印度访问一个在美国的数据中心。尽管延迟时间是很难被改进缩短的,但是测量它却非常之重要。我们怎么来测量延迟时间? 一些模拟网络条件的工具可以帮助你,这里是其中一个工具

  吞吐量(Thoughput)——你的应用/系统每秒钟能处理的事务数。一个典型的企业级应用会有很多用户执行各种不同的事务。在系统正式投入使用之前,你应该保证自己的系统达到企业级应用所要求的能力。这种情况下,负载测试(Load Testing)可视为一个解决方案。策略是,挑选一些事务(时常发生的,重要的,密集发生的)看看在SLAs(Service Level Agreement—服务提供商和终端用户之间一个服务级别的合约。用来定义期望从服务提供商处得到的服务等级)允许的时间范围内的通过率是多少。怎么来衡量呢?你通常需要一个高端专业的工具比如Visual Studio Team System(负载测试功能)。 当然了,你你可以使用一些客制的应用/代码来模拟负载。但我的经验是,客制的代码更适合用来测试响应时间(Response Time)。鉴于编写客制化的代码需要的工作量太大,一个好的负载测试工具比如说VSTS可以让你挑选一系列事务,模拟网络延迟,加入用户思考时间(真实用户的反应时间),测试迭代次数等等。我同时强烈建议负载测试使用真实数据以无限接近真实使用场景。

  扩展性(Scalability)—— 扩展性代表在添加了额外的硬件后你的系统将作何反应。系统能够使用新添加的资源来处理增加的负载吗?考虑到未来可能的增长,这一点对你的系统来说极其重要。这里我们有两种选择-向上/垂直扩展(用更好的机器);或者向外/水平扩展(使用更多的机器)。通常来说后者更受青睐。做水平扩展的一个挑战是,你的设计不能包括一些密切相关(耦合)的服务器,以便负载均衡器可以在不同服务器之间调整负载。通过内置软件或硬件NLB(network load balancer 网络负载均衡器)的负载均衡工具的帮助,你可以衡量系统的扩展性,及保证系统能够承担新增的负载而不出现任何问题。其中一个工具可以监测性能计数器,来检查真实的请求是否已经在服务器间被分派和分享(我计划在未来的博文中谈到NLB)。

  压力测试(Stress Testing)——很多人对压力测试感到困惑,或混淆了它和负载测试。简单的解释是,如果你发现自己连续执行测试超过24小时,你在做的就是压力测试(更精确的说法是在你为了打一个补丁而停下系统之前,系统实际的工作时间/在线时间)。负载测试的动机是衡量你的系统在过载条件下恢复正常的能力。系统是能后恢复到正常,还是彻底崩溃?健壮性,可以视为针对长时间运行且几乎无宕机系统的所做压力测试的一部分。一个简单例子就是内存泄漏。你的系统会在处理峰值负载后释放内存吗?另一个例子是,如果一个磁盘因为持续繁重的I/O(输入输出)负载而失效时会发生什么?你的系统会丢失数据吗?找到并定位这些潜在的风险就是压力测试背后的动机

时间: 2024-10-18 13:31:29

性能测试 - 响应 vs 延迟 vs 吞吐量 vs 负载 vs 扩展性 vs 压力 vs 健壮性的相关文章

性能测试指标:TPS,吞吐量,并发数,响应时间

性能测试指标:TPS,吞吐量,并发数,响应时间 常用的网站性能测试指标有:TPS.吞吐量.并发数.响应时间.性能计数器等. 并发数并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力. 响应时间响应时间是一个系统最重要的指标之一,它的数值大小直接反应了系统的快慢.响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间. 吞吐量吞吐量是指单位时间内系统能处理的请求数量,体现系统处理请求的能力,这是目前最常用的性能测试指标. QPS(每秒查询数).TPS(每秒事务数)是吞吐量的

scikit-learn:7. Computational Performance(计算效能<延迟和吞吐量>)

参考:http://scikit-learn.org/stable/modules/computational_performance.html 对于有些应用,estimators的计算效能(主要指预测新样本时的延迟和吞吐量)非常关键,我们也考虑训练的效能,但由于训练可以offline,所以我们更关注预测时的效能问题. 预测延迟(Prediction latency):预测一个新样本花费的时间(the elapsed time necessary to make a prediction). 预

[ios高级] UIButton 不响应或延迟响应 UIControlEventTouchDown 事件的解决办法

UIControlEventTouchDown即按钮按下时应触发的方法.实际使用过程中会出现延迟响应或间歇无响应,但是放开手指时会直接响应UIControlEventTouchDown.UIControlEventTouchUpInside两个方法,这种情况下,按下按钮不响应任何事件,当移动手指时会响应UIControlEventTouchDown. 1.延迟响应: 一般是因为button放在了UIScrollVIew或UITableView上面,按下按钮时系统会判断是不是滑动手势.将UIScr

<ubuntu ping响应慢 延迟严重的解决>

解决ubuntu反应慢.延迟问题 最近发现线下有几台ubuntu server12.04.2的,ping  www.baidu.com反应慢的要命,ip配的也没问题,dns解析写的也完全ok,它奶奶的,ping 就是反应慢的要命,有时还不通,监控一直报警,烦的要命. 排除这几项: ip配置问题: dns解析问题: 网线问题: 试着新装ubuntu server看看,ping 依旧存在此问题,centos.redhat玩多了,碰到这个还真是太相信自己水平,但就是解决不了ping的问题. 后来发现是

HDFS副本机制&负载均衡&机架感知&访问方式&健壮性&删除恢复机制&HDFS缺点

副本机制 1.副本摆放策略 第一副本:放置在上传文件的DataNode上:如果是集群外提交,则随机挑选一台磁盘不太慢.CPU不太忙的节点上:第二副本:放置在于第一个副本不同的机架的节点上:第三副本:与第二个副本相同机架的不同节点上:如果还有更多的副本:随机放在节点中: 2.副本系数 1)对于上传文件到HDFS时,当时hadoop的副本系数是几,那么这个文件的块副本数就有几份,无论以后怎么更改系统副本系数,这个文件的副本数都不会改变,也就是说上传到HDFS系统的文件副本数是由当时的系统副本数决定的

标准Web系统的架构分层

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

标准Web系统的架构分层[转]

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

(系统架构)标准Web系统的架构分层

标准Web系统的架构分层 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的通信(这在下面的内容

LOSF 海量小文件问题综述

1.LOSF问题概述 在互联网(尤其是移动互联网).物联网.云计算.大数据等高速发展的大背景下,数据呈现爆炸式地增长.根据IDC的预测,到2020年产生的数据量 将达到40ZB,而之前2011年6月的预测是35ZB.然而,社会化网络.移动通信.网络视频音频.电子商务.传感器网络.科学实验等各种应用产生的数 据,不仅存储容量巨大,而且还具有数据类型繁多.数据大小变化大.流动快等显著特点,往往能够产生千万级.亿级甚至十亿.百亿级的海量小文件,而且更多地 是海量大小文件混合存储.由于在元数据管理.访问