吞吐量和延迟的理解。。。

原文:http://www.javaranger.com/archives/1264

关于吞吐量(throughput)和延迟(latency),如果你要搞性能优化,这两个概念是必须要知道的,它们看似简单实则不是。很多人都曾经认为高吞吐量就意味着低延迟,高延迟就意味着吞吐量变小。下面的比喻可以解释这种观点是错误的。

我们可以把网络发送数据包比喻成去街边的 ATM 取钱。每一个人从开始使用 ATM 到取钱结束整个过程都需要一分钟,所以这里的延迟是60秒,那吞吐量呢?当然是 1/60 人/秒。现在银行升级了他们的 ATM 机操作系统,每个人只要30秒就可以完成取款了!延迟是 30秒,吞吐量是 1/30 人/秒。很好理解,可是前面的问题依然存在对不对?别慌,看下面。

因为这附近来取钱的人比较多,现在银行决定在这里增加一台 ATM 机,一共有两台 ATM 机了。现在,一分钟可以让4个人完成取钱了,虽然你去排队取钱时在 ATM 机前还是要用 30 秒!也就是说,延迟没有变,但吞吐量增大了!可见,吞吐量可以不用通过减小延迟来提高。

好了,现在银行为了改进服务又做出了一个新的决定:每个来取钱的客户在取完钱之后必须在旁边填写一个调查问卷,用时也是30秒。那么,现在你去取钱的话从开始使用 ATM 到完成调查问卷离开的时间又是 60 秒了!换句话说,延迟是60秒。而吞吐量根本没变!一分钟之内还是可以进来4个人!可见,延迟增加了,而吞吐量没有变。

从这个比喻中我们可以看出,延迟测量的是每个客户(每个应用程序)感受到的时间长短,而吞吐量测量的是整个银行(整个系统)的处理效率,是两个完全不同的概念。

正如银行为了让客户满意不光要提高自身的办事效率外,还要尽量缩短客户在银行办事所花的时间一样,系统不光要尽量让吞吐量大,而且还要让每个请求的延迟尽量小。这是两个不同的目标。

时间: 2024-10-29 19:12:10

吞吐量和延迟的理解。。。的相关文章

IxChariot:网络吞吐量及延迟)测试工具

IxChariot 目录 软件 安装linux endpoit 如何测试网络吞吐量 面向吞吐能力的测试: 测试两点间最大吞吐 面向响应速度的测试:测试能够达到最快的响应速度 混合模型:吞吐+响应速度 IxChariot 是一个商业测试工具,,它通过模拟真实应用流来预测现实负载情况下的网络设备和系统的性能,在应用层性能测试领域得到业界认可. 对于企业来说,IxChariot可应用于设备选型.网络建设及验收.日常维护等3个阶段,提供设备网络性能评估.故障定位和SLA基准等服务. IxChariot测

高吞吐低延迟Java应用的垃圾回收优化

原文链接: linkedin 翻译: ImportNew.com- hejiani译文链接: http://www.importnew.com/11336.html 高性能应用构成了现代网络的支柱.LinkedIn有许多内部高吞吐量服务来满足每秒数千次的用户请求.要优化用户体验,低延迟地响应这些请求非常重要. 比如说,用户经常用到的一个功能是了解动态信息——不断更新的专业活动和内容的列表.动态信息在LinkedIn随处可见,包括公司页面,学校页面以及最重要的主页.基础动态信息数据平台为我们的经济

深入理解Flink核心技术及原理

前言 Apache Flink(下简称Flink)项目是大数据处理领域最近冉冉升起的一颗新星,其不同于其他大数据项目的诸多特性吸引了越来越多人的关注.本文将深入分析Flink的一些关键技术与特性,希望能够帮助读者对Flink有更加深入的了解,对其他大数据系统开发者也能有所裨益.本文假设读者已对MapReduce.Spark及Storm等大数据处理框架有所了解,同时熟悉流处理与批处理的基本概念. 文章转载自:深入理解Flink核心技术 一.Flink简介 Flink核心是一个流式的数据流执行引擎,

Loadrunner中Throughput(吞吐量)的分析与计算

Throughput翻译为吞吐量,按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和,其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量,但这个理解在Loadrunner记录的Throughput中是错误的! 先提出正确的结果,然后用具体的试验加以证明: Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和,与本地发出的字节数无关! 我们用baidu.com做个试验,过程很简单: 1.使用VUGen录制baidu的首页,仅打开首页即可 2.在Reco

ReplicaManager之DelayedOperation

DelayedOperation包括两种:DelayedFetch和DelayedProduce,它们的存在是由Kafka Protocol决定的,而Kafka Protocol是由实际需求决定的…… 存在DelayedFetch是为了更有效率的fetch,也就是batch fetch:存在DelayedProduce是为了等待更多副本的写入,以达到用户指定的持久性保证(也就是消息更不容易丢). 对于这些DelayedOperation而言,什么时候不再需要delay是必须指明的,跟据操作的不同

(转)如何构建高性能,稳定SOA应用之-负载均衡-Decoupled Invocation(一)

当我们在为一个软件设计架构的时候,我们不仅仅要确保所做出来的架构要满足系统的业务需求,更加要确保做出来的架构要满足可维护性,安全,稳定性的非业务行的需求. 另外一个非常重要的非功能性需求就是性能.性能涉及到很多方面的关注点,例如吞吐量,延迟等.SOA的很多的设计原则和一些指导从来没有告诉我们如何去解决SOA中遇到的性能问题,因为SOA的关注点不在这里,其实SOA天生就是会导致很差的性能的:因为SOA涉及到了分布式,这就决定了它有很多不得不要的延时和不同的层之间的通信问题. 任何问题,都有其对应的

最佳线程数

影响最佳线程数的主要因素: 1.IO 2.CPU 根据公式:服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量 一般来说是IO和CPU.IO开销较多的应用其CPU线程等待时间会比较长,所以线程数量可以开的多一些,相反则线程数量要少一些,其实有两种极端,纯IO的应用,比如proxy,则线程数量可以开到非常大(实在太大了则需要考虑线程切换的开销),这种应用基本上后端(比如这个proxy是代理搜索的)的QPS能有多少,proxy就有多少. 另一种是耗CPU的计算

使用异步servlet提升性能

本文发布之后, 收到了很多的反馈.基于这些反馈,我们更新了文中的示例,使读者更容易理解和掌握, 如果您发现错误和遗漏,希望能给我们提交反馈,帮助我们改进. 本文针对当今 webapp 中一种常碰到的问题,介绍相应的性能优化解决方案.如今的WEB程序不再只是被动地等待浏览器的请求, 他们之间也会互相进行通信. 典型的场景包括 在线聊天, 实时拍卖等 -- 后台程序大部分时间与浏览器的连接处于空闲状态, 并等待某个事件被触发. 这些应用引发了一类新的问题,特别是在负载较高的情况下.引发的状况包括线程

庖丁解牛(一):监控系统

好朋友"雪糕"是前Baidu的高工,当年我们一起参与构建了一个庞大的运维自动化系统Noah.转载一些他的关于监控系统的感悟,我也深有同感. 我们在后来也用Python写了个简易版:51reboot/rebootMon-4 · GitHub 最近借着出去分享的机会,画了张简化的监控系统架构图: 写在前面 我从事运维自动化相关的工作,也已经8年了.当初刚开始做的时候,运维开发(devops)这词还不火.很少人知道.国内对运维的理解,也就是机房.服务器.苦逼的7*24小时值班.甚至当时还流传