支持HW团队,就支付宝领取下面的红包吧!(2018年3月31前,就几毛,也会几块,可以和其他红包叠加使用),你领取消费,HW有奖励。红包使用无条件限制,有条件请注意是不是有病毒。

小伙伴们,给大家发红包喽!人人可领,领完就能用。祝大家领取的红包金额大大大!#吱口令#长按复制此消息,打开支付宝就能领取!er1OEj73Uj

登入 注册 | 验证
| 搜索

博主:初学MPEG

初学MPEG 本博客-采用Python的web框架Django与Mysql数据库,致力于对Python、Django的了解 与研究
Django技术QQ群:XXXXXXX
Python技术QQ群:XXXXXXX

分类

关键字

本站最新博文

友情链接  

【转载】客户时延分析

类别:其他 状态:游客可见,可回,会员可关联(没审核) 阅读:4091 评论:0 时间:九月 17, 2015, 10:02 a.m.
关键字:时延

本文结合一定的业务场景,重点分析下我们应用的总延时和网络延时之间的关系,分析在哪些场景下,网络不可能成为瓶颈因素,我们应该更多的将分析的重点放在应用本身,在哪些场景下,网络延时将显著影响我们的客户体验,此时我们应该更多的来关注网络.在此基础上,可能需要改变我们应用层的协议行为,以适应这种网络环境的变化.
首先我们考虑如何获得一个较通用的计算延时的公式:
        客户延时=传输时延+业务延时
客户延时:客户使用我们的应用,从他发出指令,到最终接收到响应,客户所等待的时间,客户延时越小,则客户体验越好.所以降低客户延时是我们在优化阶段的一个重要目标之一.
传输时延:业务数据在网络上传输需要消耗的时间,该时间组成相当复杂,

业务延时:指我们的业务代码为了处理业务逻辑,需要耗费的时间

根据上述最基本的计算公式,我们来分析三种网络环境下的时延
一:局域网环境下的延时分析
在如下图所示的局域网环境下,传输时延的计算公式如下:

 局域网

         传输时延=传播时延+发送时延+排队时延+交换时延

传播时延:信号从源发送到目的地所花费的时间
发送时延:串行延时,将数据放到传输线路中串行化所花费的时间,该时间取决于带宽以及报文大小
排队时延:由于QOS机制,或者线路拥堵导致分组在交换机中排队等待的时间,该时间一般取决于网络的繁忙程度,
交换时延:数据报第一个字节进入交换机到最后一个字节离开交换机的时延,和交换机背板带宽关系紧密,
上述几个时延的计算公式如下:
        传播时延=传输距离(米)/光速
        发送时延=发送BIT数/带宽
        排队时延=网络负载率× (max)
                -网络负载率:是指当前网络负载占网络带宽的百分比
                - (max)是发送最大以太网帧(1522 byte)所需的时间
        交换时延:目前交换机的背板带宽为Gbps,上百Gbps...,已经可以将交换时延降低到纳秒级,一般来说我们的应用中,客户的交换机是比较高端的,我们假定交换时延为10微秒
在局域网环境下,按照上述公式,传播时延可以忽略.对于1G网络,我们假定业务的请求/应答均为1K字节,那么该场景下发送时延为: 1024*2*8/1G (这里我们忽略协议头部)
计算得到发送时延为 16微秒
假定当时网络负载率为10%,则排队时延为2.4微秒
我们假定该交换机的交换时延为10微秒
由计算得知,其传输时延=0+16+2.4+10=28.4微秒.
一般来说,业务时延总是比较大的(如需要和数据库交互),假定我们的业务时延为1毫秒.
从上述分析可以看出,再1000M网络环境下在时延的组成中,传输时延相对于业务时延,几乎可以忽略.
同理可以分析,对于100M网络,其传输时延为:184微秒(相对与业务时延还是可以忽略)
引申:如何获得当前网络环境的带宽.
从上述的计算分析,我们可以获得一个在局域网环境下,计算两台机器之间网络带宽的一个较为简洁的公式:(在这里,我们忽略传播时延,排队时延,交换时延)仅仅根据发送时延可以大略的估算一个两台主机之间的带宽,要计算A主机和B主机之间的带宽,我们可以通过在A主机PING一下B主机,通过ping的延时,来获得大概的带宽,通过ping指定报文大小,如M字节,如果计算获得的延时为N毫秒(一边ping都可以显示毫秒级的时差)
则带宽为:
        带宽=M*8*1000*2/N
从上述计算公式可以看出,ping一个64K的报文,在1G网络下,ping显示的时差为1毫秒.所以,当我们不确定2台主机间究竟是100M网络还是1000M网络时可以通过 ping  -l 64000 IP地址来大略判断,如果时间<10毫秒,那么这就是个1000M网络,而如果时间大于10毫秒,小于100毫秒,那么这应该是个100M网络.
上述计算公式之所以成立的关键就是因为我们假定了在高速局域网环境下,网络延迟基本取决于发送时延,这一点从上述分析中,可以看出是成立的.
更一般的,我们可以将该计算公式推广到广域网环境(必须是地面线路),当然,网络越复杂根据上述公式计算获得的带宽越粗糙,但是,我们可以相信计算获得的值在数量级上是可信的.

二:广域网络环境下下的延迟分析
考虑如下图所示的广域网环境:

广域网.jpg

上图中,在路由器A和路由器B之间可能会经过多个网络设备,那么,这中间的排队时延,交换时延相对来说是不可控的.
一方面由于整个广域网环境的不可控,导致我们无法预测报文流尽的所有网络设备的繁忙程度(从而无法准确预估排队时延), 中间网络设备传输报文的高效与否(从而无法准确预测交换时延)
另一方面,由于广域网环境IP报文传输的路径不固定,导致排队时延和交换时延可能会波动
综上两个因素,在广域网环境,我们无法准确评估传输时延.但是,在数量级上,我们还是可以分析的,理由如下:
1:        传播时延还是可以忽略的(相对与光速来说,我们地球实在太小)
2:        由于国内目前广域网的传输带宽相对来说偏小(如我们的客户一般是2M专线,这里我们假定客户是10M专线的带宽)
3:        相对于10M带宽所产生的发送时延,一般来说,排队时延和交换时延的因素基本还是可以忽略的(当然,我们会碰到排队时延和交换时延不能被忽略的情形,一般来说,碰到这种场景,就已经是网络故障的范畴了,在网络正常的情形下,没有一个网络设备的排队时延和交换时延会显著的改变在10M带宽上传输报文的时延)
回到我们的示例:
        我们还是假定业务的请求/应答均为1K字节,通过10M广域网传输,那么那么该场景下发送时延为: 1024*2*8/10M (这里我们忽略协议头部)
        计算获得发送时延=1.6毫秒.
        如果我们为排队时延,交换时延预估一个较大的值,如400微秒(对于正常网络,这已经是偏大的预估了)那么,我们获得,在一个10M广域网环境,报文的传输时延为:
        传输时延=2毫秒
而我们的业务时延仅仅为1毫秒.
可以看到,在广域网环境,在整个客户延时中,传输延时已经占了很大的比例.在这种网络环境下,要提升客户的体验,已经需要对我们的应用层协议做仔细的规划,如,我们考虑一个大的查询,如果服务端一次性将符合条件的所有记录返回,假设该报文为10M.那么根据我们上述的计算分析
该报文的时延为
        传输延时=10S
        业务延时=1毫秒
在这种场景下,无论你再怎么去优化我们的业务代码,费尽九牛二虎之力将业务延时缩短为短短的1微秒,但是整个优化对于客户体验没有任何的改善客户延时还是为10S.所以,在这种场景下,我们需要的不是针对一个个的业务代码做优化,而是从整个业务流程上重新设计,对应用层协议做改造.
如上述客户查询10M的应答数据,我们最简单的做法是一次性返回10M,这对于业务流程是最简单而直接的选择,但其造成的后果是客户体验的急剧下降,我们如果采用流式传输的思想,将10M的大数据,通过分割,为1K,1K的小报文逐步发送给客户端,而客户端在每接收到1K数据之后,就立即展现出来,那么对于用户来说,他的感觉还是相当与在约1毫秒的时间内,就获得了自己的查询结果,由此带来的(仅仅是感觉上)是4个数量级的性能提升.
这里,结合AR的路由转发,再做个说明,由于我们的AR是存储转发,每经过一个AR环节,AR均必须在接收到一个完整的报文后,才会在此路由转发,
那么对于一个大报文的传输,中间经过的AR层级越多,则传输延时越大,客户体验越差.

三:卫星网络下的延迟分析
大家可能都知道恒生中间件不宜适用于卫星传输,或者,即令可以,其用户体验一定糟糕的一塌糊涂,会什么呢?我们考虑如下图所示的卫星网络环境:

卫星传输.jpg

主机A和主机B之间交换数据(我们还是假定我们的业务延时为固定的1毫秒),那么在这种网络环境下,传输时延是多少呢?
重新回顾下传输时延的公式:
        传输时延=传播时延+发送时延+排队时延+交换时延
卫星网络相对与地面网络,排队时延+交换时延没有太大的区别,而一般来说卫星网络的显著优点就是其高带宽,所以这里发送时延也是可以忽略的在卫星网络中,真正影响用户体验的,是其传播时延:
记住如下几个常数:
        光速            30万   千米/s 
        同步轨道卫星高度:3.6万  千米
那么从主机A到达主机B的传播时延,其实就是从地面站A到卫星,再从卫星到地面站B的传输时延:
        地面站A到达卫星需要:120毫秒(这已经是极限了,无法再做提升)
        总的传输时延为:        120*4=480毫秒
而更糟糕的是,一次传输,可能会两次上天,即从主机A到主机B的真正传输路径有可能是:
        主机A--->地面站A--->卫星--->地面站B--->卫星--->地面站C--->主机B
那么在这种场景下,其传输时延接近1S,在这么巨大的传输时延下,任何对业务代码的优化都显得是徒劳无功的.

下面我们粗略的分析下,为什么恒生业务在卫星网络下将是不可行的(或者是糟糕的),由于本人仅对证券业务有一丝了解,仅以证券柜台业务为例:
证券柜台启动后的第一件事情是柜员的登录,而柜员登录中间会牵扯到多个业务请求,这些请求和请求之间是串行的,即在接收到前一请求的应答之前,不会发送下一个请求,我们假定总的业务请求个数为N,然后,我们假设卫星传输两次上天,也即传输时延为1S那么,我们可以看到,即令每个的业务请求/应答均为小报文,其客户延时至少为:
        最少的客户延时=N秒
而在证券系统中,该N的取值一般在10之上,大家可能觉得10S的延时似乎还可以接受,那么我们再考虑另外一个方面:
        每次的请求的应答报文的大小,我们假定应答报文大小为100K,从主机B发送给主机A(这不夸张)
卫星是个高带宽链路,也许,我们会认为应答报文100K还是1K对于经由卫星链路传输,其传输时延应该相差不大.确实,如果我们通过卫星链路从主机A来ping主机B,那么我们选择一K字节来ping还是选择64K字节来ping,显示的时间差确实差异不大,而这就是卫星传输的优越性.但是,我们要考虑到TCP协议的行为,由于TCP的发送窗口限制,TCP在发送一定数量的数据后,在接收到对之前发送数据的确认前,不会发送余下的数据而在卫星网络中,来自对端的确认将在1S后才能到达.这样,如果我们在主机B捕获报文,会发现,主机B一次性发送N字节的数据(取决于当前发送窗口大小)而后,就等待1S钟,然后再发送另外的N字节,如此反复,直到发送完完整的100K报文.
考虑到主机B的这种发送特性,那么证券业务,柜员的一次登录,可能需要花费分钟级的延时.
而这是不可接受的.
使得恒生业务适合卫星网络的可能性:
有没有办法使得恒生业务可以通过卫星链路运行呢?或者至少使得用户体验不是那么差,如将客户延时控制在10S?
为了适应卫星链路,我们需要至少做两个优化:
1:TCP缺省协议行为的更改,
        a:加大发送窗口
        b:更改TCP拥塞控制和避免策略
        对于TCP协议行为上的优化,有许多商业公司有所谓的TCP加速技术,并且也已经行程了规范,但是,对于金融领域,使用所谓的TCP加速技术,其潜在风险
        是很高的(会造成TCP会话两端对TCP会话状态的认识不一致)
2:更艰难的是,对业务流程的重整
        将各个串行化的业务请求异步化处理,以避免那个N秒的延时
        这将是对整个流程的重整,工作量巨大
上述无论是更改TCP协议栈缺省行为还是更改业务流程其风险均是巨大的,所以我认为,恒生业务不适合在卫星链路上传输.

操作:

Please Login (or Sign Up) to leave a comment