第一篇：VoIP业务Qos性能优化研究
VoIP 业务QoS 性能及其优化研究
张路宜
200522160013
VoIP(voice over IP)就是通过IP 网络承载语音业务,也称IP 网络电话。当网络出现拥塞或传输差错时,语音包就会产生时延、抖动甚至丢失,导致语音不连续或中断,严重影响语音质量。VoIP 业务有着严格的实时性要求,时延、抖动和丢包这3 个影响VoIP 服务质量的主要因素与承载网的性能密切相关。
目前,优化QoS(服务质量)的业务模型主要有intserv(集成服务)、diffserv(区分服务)和MPLS(多协议标签交换)3 种。intserv 可扩展性差,在现有的网络上实现起来非常困难;diffserv 提供了基于类的QoS ,具有良好的可扩展性,但缺乏有效的end2to2end(端到端)机制;MPLS TE(流量工程)通过有效地管理带宽资源,间接改善网络服务质量,但其带宽管理
以及MPLS TE 隧道都无法做到基于业务类别。如果EF(加速转发)、AF(保证转发)、BE(尽力而为)这几类业务都承载在一个MPLS TE 隧道中,那么EF和AF 业务将受到严重的影响。因此, 单独采用diffserv或MPLS TE 服务模型来优化VoIP 业务的QoS ,效果都不尽如人意。
MPLS diffserv2aware TE 是具有diffserv 感知能力的MPLS 流量工程,综合了diffserv 和MPLS TE 两者的优点形成的一种新的集成业务模型,实现了基于业务类别的带宽管理和隧道服务,可以有效保证VoIP 业务在承载网上的服务质量。VoIP 传输基本原理
传统的电话网采用电路交换方式传输语音,可以确保语音传输质量。VoIP 技术将发送的模拟语音信号数字化之后进行编码、压缩,然后转换为IP数据包在网络上传输;在接收端再进行拆包、解压、解码等逆向处理,最后转化为模拟语音输出。包含基本配置的IP 电话网结构如图1 所示,我们以电话用户025 呼叫022 为例,简单介绍VoIP 的通信接和传输过程。025 话机拨号向022 话机发起呼叫,呼叫信令进入语音网关编码、压缩成特定的帧,经过IP 网络送入关守(GK:gate keeper)后对025 话机进行鉴权。如鉴权成功,则对被叫号码022 进行地址解析,通过落地网关与PSTN(公用交换电话网)建立逻辑通道,分别给主叫送回铃音、给被叫送振铃音。至此,经由接入语音网关与落地网关的一个呼叫流程就建立起来了。发送的模拟语音信号由接入语音网关进行编码、压缩、组帧,语音分组通过IP 网络传输到达落地网关,再经过拆包、解压缩、解码等一系列逆向处理,转变为模拟语音信号,通过PSTN 到达被叫话机。VoIP 业务QoS 性能分析 2.1 时延
时延是一个分组从发送端发出后到达接收端的时间间隔,是端到端的时延。ITU2T G.114 规定,对于高质量语音可接受的单向时延是150ms。网络时延可分为固定网络时延和变化网络时延2 部分。固定网络时延是指在发送端和接收端间的信号传输时延、语音编码时延以及VoIP 编解码的语音打包时间。网络的传输时延值约为6.3μs/ km , G.729编解码标准编码时延为25ms(包括2 个10ms帧加5ms算法时延),打包时延为20ms。变化网络时延主要源自网络拥塞,而拥塞是不定时发生的,所以由此产生的时延也是变化的。这种可变时延会因在外出接口队列中长时间的等待或较大的串行化延迟而迅速增长。语音分组在外出队列中排在一个大数据分组后导致长时延情况如图2所示。为了控制语音数据包到达目的地的时延,必须有足够的带宽来保证。
图2 语音分组排在大数据分组后产生的时延
2.2 抖动
抖动是指由于各种时延的变化导致网络中数据分组到达速率的变化。它主要由以下几个因素引起:排队时延、可变的分组大小、中间链路和路由器上的相对负载。补偿抖动的常用方法是在接收端设备上进行缓冲处理。虽然这与减小时延的目标相悖, 但对消除抖动带来的影响是必要的。如图3 所示,在时延一定时,当抖动增大时抖动缓冲区也得相应增大,而增大缓冲区就意味着需要占用接收端设备更大的存储器空间并带来更大的时延。
抖动幅度与抖动缓冲区大小关系示意图消除抖动的缓冲区大小可按下列方法估算。假设在一次连接中,所有分组中传输时间最短的那个时延值等于固定传输时间, 即Tmin = min{ Tn}式中Tn 是每个分组的时延。
每个分组的时延抖动为Xn = | Tn – Tmin 一段时间内的平均时延抖动(期望值)为M = E(Xn)
平均时延可用来确定消除抖动的缓冲区的大小。在相对稳定的情况下,设某种语音编码方式的帧长为F ,一段时间内的平均时延抖动为M ,帧速为f ,则缓冲区大小为Mf F。
2.3 丢包
语音分组在传输过程中有可能被丢失,其原因主要是分组超时或网络拥塞。IP 数据报在网络中寻径具有随机性,为避免数据报进入死循环,系统在一个新数据报产生时,会在其头部TTL(time to live)标志位设定其在网络中的最大生存时间。如果超过这个时间限制,系统自动将其丢弃。造成拥塞的主要原因是网络中的设备没有足够的缓冲区接收数据,如果通向某一路由的队列排队太长,将会产生溢出,导致分组丢失。当单个分组丢失时,采用插值技术可以近似恢复,对语音的理解影响不大。但是,如果有多个连续分组丢失,那么只能靠插入静默帧来处理。通常,语音编解码可以允许3 %～5 %的丢包率。3 VoIP 业务QoS 性能优化
3.1 MPLS diffserv2aware TE模型
diffserv 将流量分成几个等级并按每个等级分配网络资源。为了避免采用信令协议, 它以6 位diffserv码点(DSCP)直接在数据包上标记等级。DSCP 字段是IP 报头中服务类型(ToS)字段的一部分。IETF 对很少使用的ToS 字段进行了重新定义,将其分隔成6 位DSCP 字段和2 位显式拥塞通知(ECN)字段。diffserv 为流量提供不同的转发处理,从而为不同的流量执行特定的QoS。它是一种可扩展的解决方案,不需要在网络核心基于流信令和状态进行维护。但是,如果流量的传输路径不能提供足够的资源来满足QoS 要求,diffserv 将无法保证QoS。
MPLS TE 利用可用资源沿链路建立标签交换路径(LSP),从而确保始终为特定流提供有保证的带宽,以避免在稳定或故障情况下出现拥塞。如果沿最短路径的可用资源不足, 可以不按照最短路径来设计LSP , 从而实现传输资源优化。
MPLS 通过链路保护和快速重路由等机制实现故障发生时的快速恢复。但MPLS TE 忽略了在一个汇聚级别(包含所有服务类别)的可用带宽上,进行CoS(class of service ,服务等级)的分类和操作。MPLS diffserv2aware TE 通过将diffserv 与TE 两者的功能结合在一起,使MPLS TE 能够感知CoS ,允许根据CoS 细粒度来预留资源,并在每个CoS 级别提供MPLS 容错机制。因此,MPLS diffserv TE 可以用来为VoIP 业务提供QoS 保证,从而满足严格的SLA(servicelevel agreement ,服务等级协定)。
3.2 VoIP 业务QoS 优化方法
在MPLS diffserv2aware TE 中,可以采用BE 和EF这2 种diffserv PHB(per hop behavior ,单跳行为),BE用于数据传输,EF 用于语音传输。EF 在diffserv 域比BE 具有更高的优先级。我们的目标是对语音业务提供服务质量保证。每条链路上配置2 个调度队列,一个用于BE ,另一个用于EF。IETF 要求支持最多8 个CT(class type ,级别类型),从CT0 到CT7。我们将CT0 映射到BE 队列,CT1 映射到EF 队列(用于传输VoIP 业务)。一个diffserv TE LSP 只能传送一个CT 的流量,但是传送同一个CT 流量的LSP 可使用相同或不同的抢占机制。本文从描述的简单性出发,只考虑支持2 种CT , 分别用于语音和数据业务。其中CT1 比CT0 具有更高的资源占用优先级。
我们采用RDM(Russian doll model)带宽分配模式,将CT1(话音流量)的带宽限制在链路的某个比例,以确保话音流量具有较小的队列延迟。通过IGP(内部网关协议)广播每条链路上基于CT 的每个优先级的可用带宽, 采用改进的最短路径优先(CSPF)算法,在原来TE 的限制条件下再加入CT 特定的带宽要求作为限制条件来计算路径。LSP 的CT信息在RSVP 路径消息的全新级别类型对象(CT对象)中进行传输,并规定请求预留带宽的CT。以下2 个规则可确保在网络中渐进部署diffserv TE:CT对象只用于从CT1 LSP(如果CT1 对象丢失,则假定为CT0);节点接收到包含CT 对象的路径信息时,如果它无法识别该消息,将拒绝建立路径。
承载在路径消息中的CT 信息,指定了沿路径的每个节点上都执行许可控制的CT。如果沿路径的节点的资源足够,则接收新LSP ,节点计算每个CT 新的可用带宽和优先级别,这些信息随后被送回IGP。另外,我们采用基于Exp 位的diffserv 处理方法(简称E2LSP),在整个diffserv 域中配置一致的Exp2PHB 映射。简而言之,MPLSdiffserv2aware TE 就是对IGP 进行扩展,收集EF 和BE 类的资源使用情况,分别建立TED(流量工程数据库),通过信令协议携带类别建立LSP。这种集成服务模型的优点在于LSP 的建立是基于每个CT 的带宽要求,既可以实现基于类的QoS ,又可以进行带宽控制,提供了低丢失、低延迟、低抖动以及确定的带宽服务,可以很好地满足VoIP 的QoS 要求。
参考文献
[1 ] 张登银, 张庆英.基于因特网的QoS 技术及其业务分析[J ].计算机工程与科学, 2002 ,24(3):31 —35.[2 ] 桂海源.IP 电话技术与软交换[M].北京:北京邮电大学出版社,2004.[3 ] 张登银, 孙精科.VoIP 技术分析与系统设计[M].北京:人民邮电出版社,2003.[4 ] LOVELL David.Cisco IP 电话技术[M].北京:人民邮电出版社, 2002.[5] VoIP业务Qos性能分析 张登银 施伟 南京邮电学院 江苏通信技术 2005-02
[6] BLAKE S , BLACK D , CARLSON M, et al.An architecture fordifferentiated services[ EB/ OL ].RFC2475 ,1998212.
第二篇：SQL语句性能优化
我也做了很长时间医疗软件，也写过不少sql优化，没有详细记录下来，个人感觉下面转载的更符合医院医疗软件实际业务，很认可大部分所写的原则，固转载过来，以作借鉴。软件的根本还是在于更细更精，在于从客户的实际使用考虑问题。
性能优化原则1:永远避免困境
利用缓存把字典数据取到中间服务器或是客户端替代直接sql查询,如,门诊医生站把字典下载到客户端,减少执行次数。
一次性取数据到客户端，然后再逐条处理，而不是分次取数据，处理好一条数据再取下一条再处理。例：门诊收费取hjcfmxk例子，原来是一张处方条明细都查询一次，查询后再处理，现改为一次把所有明细都取过来，然后一条条处理
尽量减少光标，看能不能用临时表
性能优化原则2:kiss原则
对于where 条件中的左边可以利用索引的字段Keep it simple stupid，左边尽量避免用函数(substring,isnull,upper,lower)，参加计算+,-*/
例子1：select * from ZY_BRFYMXK where substring(zxrq,1,8)='20081212‘
select * from ZY_BRFYMXK where zxrq between '2008121200' and '2008121224' 例子2：
select * from zy_detail_charge where SUBSTRING(patient_id,1,10)=
substring('000005090600',1,10)这句耗时30秒以上
select * from zy_detail_charge where patient_id like substring('000005090600',1,10)+'%' 这句耗时2秒以内
性能优化原则3:尽可能利用到索引
例：select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0
select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0 and b.syxh=3
性能优化原则4:or,避而远之
对于索引字段尽力避免用or，普通字段可以用or，解决要么分解成多个sql,要么用业务规则避免，例：declare @rq1 ut_rq16,@syxh ut_syxh
select @rq1='20081201'
select @syxh=157
性能优化原则5:避免大批量数据取到前台
例： select * from ZY_BRSYK cyrq between ‘20080901’ and ‘20081201‘,对于大医院每天100多人，90天是9000条数据
性能优化原则6:事务,尽可能的短吧
所有计算、对临时表的更新都应但放在事务外，事务中最好只有更新和插入正式表操作.因为事务中产生的锁只有在commit tran是才会释放。
性能优化原则7:热表，留在最后吧
热表是频繁调用的表。如：sf_mzcfk,zy_brfymxk,bq_fyqqk.对于热表尽量放在事务最后：这样锁的时间短。大家都坚持这样，死锁的可能性就小。如果都是热表各个存储过程更新表的顺序应当一样这样可以避免死锁
性能优化原则8:创建临时表一定要避免在事务中作
如create #tempXX(…)
Select * into #tempXX from …
因为创建临时表会锁tempdb的系统表
例：生成#temp1放在事务内外，用sp_lock2 ‘’观察结果
if object_id('tempdb..#temp1','U')is not null
drop table #temp1
begin tran
select * into #temp1 from ZY_BRSYK where ryrq>'20080901‘
select * from #temp1
waitfor delay '00:00:10'
commit
性能优化原则9:大的报表查询避免与正常业务碰撞
如果没有查询服务器，那要在存储过程中限制不能操作加上如：
declare @rq1 ut_rq16,@rq2 ut_rq16,@now ut_rq16
select @rq1=convert(varchar(8),getdate(),112)+'08:00:00'
select @rq1=convert(varchar(8),getdate(),112)+'11:30:00'
select @now=convert(char(8),getdate(),112)+convert(char(8),getdate(),8)
if @now>@rq1 and @now<@rq2
begin
select '上午繁忙时间段不能作此查询'
return
end
性能优化原则10:存储过程避免大的if…else…
这个常出项在业务相同表不同的存储过程中，因为这样常到if …else …原来医技接口中很多这种存储过程，当时把门诊住院业务放在一个存储过程中。这样最大的问题是sql server会根据sql语句来compile存储，这个过程会生成优化计划，决定用那个索引。如果存储过程用到门诊表compile一下，到用到住院表是发现不对，又会compile一下，这样不停compile.compile很号时间要1-2秒，而且一个存储过成在compile是，所有调用这个存储过程的进程都要在排队等候,因为他会独占锁这个存储过程
例：usp_yjjk_getwzxxm_old.sql,后改为：
usp_yjjk_getwzxxm.sql, usp_yjjk_getwzxxm_mz.sql,usp_yjjk_getwzxxm_zy.sql
性能优化原则11:进攻是最好的防守
在普通编程语句对于数据校验总是用防守办法先判断,后再作相应处理。而在sql中先处理再判断性能会好很多。
--更新药品库存。
If exists(select 1 from YK_YKZKC WHERE idm=100 and kcsl>50)
begin
update YK_YKZKC set kcsl=kcsl-50 where idm=100
End
Else begin
rollback tran
Select ‘F库存不够’
return
end
--改为
update YK_YKZKC set kcsl=kcsl-50 where idm=100 and kcsl>50
If @@rowcount<=0
Begin
Rollbakc tran
Select ‘F库存不够’
end
--取未执行的医技项目,日表没有数据就到年表中查找
if exists(select a.* from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
begin
select a.* into #temp1 from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
end
else begin
select a.* into #temp1 from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
end
--改为
Insert into #temp1 select a.*
from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
If @@rowcount=0
Begin
Insert into #temp1 select a.*
from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
end
性能优化原则12:trig最后的手段
Trig（触发器）的处理的处理机制是满足条件时就会在源语句后面加上trig中的代码进行执行。
它有两个致命的弊端：（1）不清楚有trig的人会对于执行结果感到迷惑。如常有在插入一张表如果主键是indentity的值常取用select @@identity。但如是有trig,tring中有表插入操作，这时的@@identity可能就不是想要的值。（2）trig会束缚选择。如：有一套单据主表和明细表，当明细表的金额更新时，要同步主表的金额，当程序是一条条更新明细时用trig的作法是每当更新一条明细记录时都算一处所有明细表的总金额，再去更新主表的金额。这样有多少条明细就要算多少次，好的作法是不要trig,直接在sql语句中明细更新完明后，一次性算出总金额每条单据的总金额，再更新主表的金额。
对于trig如果有其他手段就一定要避免用trig.性能优化原则13:用户说好才是真的好
1）有时sql语句性能难以优化，但用户对于系统响应速度还是不满意。这时可以从业务分析处理。
如：我们退费模块录入发票号原来是用fph like ‘XXX%’。用户报怨慢，后来改为先用fph=‘XXX’来查，如查不到再fph like ‘XXX%’。这样在绝大部情况下速度都非常快，同时也满足小部分情况下模糊查询的需求。
如：我们的程序要查日表和年表。如果通过日表union表视图去查会非常慢，性能也难以优化。程序改为普通情况下不查年表，用户勾上年表标志时才查年表。
（2）查询统计很多数据时间比较长，就以查询完一部分数据后可以显示这部分数据或是用提示，这样用户清楚系统在作事情也知道大概进度。这样情绪上会好很多。
（3）查询模块常有一进入时也默认一个查询，如果性能好，查询又合用户心意，这种设计非常好，如果性能不好，那就不是好的设计。用户对于进入都困难的模块是没有好感的。
（4）有户的耐心与查询出的记录成正比。用户痛恨等待很久却没有查询出记录。
对于非常慢的查询，如果有些子查询非常快可以先作这样查询以避免查询很久却没有数据出来的情况。如：按病历号查在院病人所有费有明细，可以先查一下这个病历是不是有对应病人。
实战技巧1:用exists、in代替distinct
Distinct实际上是先收集再删除这样两步都耗资源。
Exists,in会隐式过滤掉重复的记录
例查自2009年以来有金额大于100的药品的病人
select distinct a.blh,a.hzxm from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and c.zxrq>'2009' and c.zje>100--改为
select a.blh,a.hzxm from ZY_BRXXK a where exists(select 1 from ZY_BRSYK
b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and
c.zxrq>'2009'and c.zje>100)
实战技巧2:缩短union
select …from A,B,C,D,E1
where(E1的条件)
and(其他表联接条件)
union
select …from A,B,C,D,E2
where(E2的条件)
and(其他表接接条件)
改为
select …from A,B,C,D,(select...from E1where(E1条件)
union
select …from E2where(E2条件))E where(其他条件)
当涉及ABCD表部分耗资源而E1,E2不耗资源时是这样，如果反过来则改后的性能不一定好。查2009年4月后入院的在院病人在2905病区发生的所有费用明细
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YK_YPCDMLK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm
union all
select a.hzxm,b.cyrq,d.name,d.xmgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YY_SFXXMK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.ypdm=d.id and c.idm=0
--改为
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),(select ypmc,ypgg,ypdm,idm idm from YK_YPCDMLK union select name,xmgg,id,0 from YY_SFXXMK)d
where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm and c.ypdm=d.ypdm
实战技巧3:合并sql
把表和where条件类似的两个或是多个sql合并为一个sql.--查2009年以后的普通、急诊、专家挂号人数
declare @ptghs int,@jzghs int,@zjghs int
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=0
select @jzghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=1
select @zjghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=2
select @ptghs,@jzghs,@zjghs
--改为
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=sum(case when ghlb=0 then 1 else 0 end),@jzghs=sum(case when ghlb=1 then 1 else 0 end), @zjghs=sum(case when ghlb=2 then 1 else 0 end)
from GH_GHZDK where ghrq>'2009'
select @ptghs,@jzghs,@zjghs
实战技巧4:去掉游标
把游标当作编程语言的for,do---while的方式，很多情况下都可以去掉,如果光标中间sql语句只有一条一般都是可以去掉光标改为一句sql。
--查当天出院出院日期在2009年4月1到9日间病人的zfdj,zfje置为0
declare @syxh ut_syxh
declare cur1 cursor for select syxh from ZY_BRSYK where cyrq>='20090401' and cyrq<'20090410'
open cur1
fetch cur1 into @syxh
while @@fetch_status=0
begin
fetch cur1 into @syxh
end
close cur1
deallocate cur1
--改为
update ZY_BRFYMXK set zfdj=0,zfje=0
from ZY_BRFYMXK a,ZY_BRSYK b
where a.syxh=b.syxh and b.cyrq>='20090401' and b.cyrq<'20090410'
实战技巧5:取代count
利用内部函数代替
declare @count int
select * into #tmep1 from ZY_BRFYMXK WHERE zxrq>'200901'
select @count=@@rowcount—可以得到count值
select @count
select @count=count(*)from #tmep1—可以被取代
select @count
利用exists而不count判断有没有记录
declare @count int
Select @count=count(1)from ZY_BRFYMXK WHERE zxrq>'2009‘
If @count>0 … else ….--改为
If exists(Select 1 from ZY_BRFYMXK WHERE zxrq>'2009’)… else ….
第三篇：气象信息网络系统备用网络及QoS优化
气象信息网络系统备用网络及QoS优化
1备用网路的设计选择
根据气象信息传输业务实时性及高时效性特点、气象信息广域网系统的可靠性要求，备份网络系统是必不可少的。而且，备份网络系统还必须具备实时热备、无缝隙切换机能，即能保证主备线路在故障发生时及排除后能迅速自动切换。对于备份线路具有诸多可选择方案，如再建设一条SDH专线或者MPLSVPN线路作为备用线路，其中前者费用较高，而后者由于其传输带宽不是用户独享的，对流媒体应用支持不太理想，同时MPLSVPN普及度还不是太高。对于边远山区的台站可能无法提供接入。目前还有一种应用比较广泛、技术比较成熟的方式，即基于Internet的VPN，具有性价比较高、带宽资源利用率高、接入方便、网络环路比较完善等特点，在极端灾害情况下，其受到的损害相对较少，恢复速度相对较快；缺点是带宽不够稳定、对视频会商等流媒体支持比较薄弱。
根据自身应用需求等情况，选择符合自身实际的备用线路接入方式，与主干网络充分有效地衔接与融合，从而提高气象信息广域网络系统稳定性和可靠性，是备用路由设计与选择的基本原则。
2QoS策略优化
随着省、市、县三级高清视频会商系统的建设和应用，对网络带宽及带宽的稳定性有了非常高的要求。省一市一县三级气象广域网络的带宽有限，承载的传输业务比较重，进行视频会商时，网络中不可避免地出现数据拥塞乃至丢包。为了解决带宽拥塞的这一问题，分析数据传输对数据丢失敏感，但对延迟没有很高的要求；音频传输对丢失率和延迟都有很高的要求；而视频传输对延迟敏感，但允许一定的信号丢失。若把弱实时保证能够嵌入到现有业务网络中，在Qos要求得到保证的前提下可提高网络的利用率。具有弱实时约束的会话，其分组被分为选择性分组和强制性分组两类。选择性分组可以传输也可以丢失，而强制性分组必须传输。即连续Z个分组中至少保证n个强制性分组得到传输，其余z—n个选择性分组可以丢弃。
此文由才子城论文设计网搜集
第四篇：计算机系统性能优化总结
计算机系统性能优化总结
现今，计算机技术在社会各行各业都得到了广泛的应用。计算机给我们的学习、生活和工作都带来了极大的便利。但随着我们对计算机整体性能要求的提高，计算机系统性能的优化就显得尤为重要。
一、计算机系统运行不佳的原因分析
计算机系统运行性能不佳的原因有很多。如，系统平台结构不好、系统配置不好或参数设置不对；应用系统数据结构设计不合理，加大了系统的输入和输出需求；应用系统算法或逻辑处理有问题，使计算机系统达不到最佳的运行状态。
二、计算机系统性能优化措施
1.合理地配置各种软件，使计算机系统发挥最好的功能。计算机系统由硬件系统和软件系统组成，二者之间相互依赖，这就要求我们在使用计算机软件的过程中，使用一些速度较快、版本较高和功能较完善的软件，并仔细阅读各种软件的使用说明，避免在应用过程中发生冲突。作为编程人员，在编写应用程序的过程中，要充分考虑应用系统数据结构设计的合理性，以便使计算机系统达到最佳的运行状态。
2.调整输入和输出系统。在计算机系统的应用过程中，我们进行的大多数操作就是输入和输出。因此，输入和输出操作是影响计算机性能的一个重要因素。随着科技的日益发
展，磁盘的平均寻址时间日益缩短，但与中央处理器的运算相比，仍然缓慢很多。在观察一些系统运行时，经常出现中央处理器处在空闲状态而应用程序却迟迟不能完成的情况。究其原因，就是因为磁盘的输入和输出的速度太慢，数据没有读（写）入内存中。因此，在实际的应用过程中，我们可以考虑把数据文件存放在不同的磁盘上，让多个磁盘并行工作，从而解决输入和输出的瓶颈问题。如果输入和输出总数明显不合理，就要考虑查找引起输入和输出数量增大的原因，从而优化应用程序，减少输入和输出的次数，提高系统的性能。
3.安排相同性质的处理过程同时运行，以确保中央处理器和输入和输出的绝对通畅。一台计算机能够同时运行多个应用程序，从使用系统资源的角度来看，这些应用程序可以分为面向输入和输出与面向运算2种类型。
系统中如果有2个或多个面向输入和输出的应用在同时运行，就会造成中央处理器闲置而大量磁盘输入和输出拥塞和等待的情况，使得各个应用程序的性能变差。系统中如果有2个或多个面向运算的应用程序同时运行时，就会造成磁盘空转的情况。因此，要尽量避免让多个面向输入和输出或多个面向运算的应用程序同时运行。最好的安排就是让面向输入和输出与面向运算的应用程序合理搭配，使每个应用都能获得足够的系统服务而又互不影响。
4.合理地使用中央处理器。一般来说，在一个计算机系统中，中央处理器的速度要远远高于输入和输出的速度，因而输入和输出速度往往是影响系统性能的主要因素。但必须指出的是，这种规则只适用于普通的情况。如果不知道中央处理器能力也有一定限制，盲目地、不合理地使用中央处理器，中央处理器也会成为影响系统性能的主要因素。
通过对计算机系统的性能进行优化，排除了系统中的各种不合理因素，缩短了系统的响应时间，使计算机系统能更好地发挥作用，从而为我们提供更好的服务。
第五篇：网站前端性能优化总结
一、服务器侧优化
1.添加 Expires 或 Cache-Control 信息头
某些经常使用到、并且不会经常做改动的图片（banner、logo等等）、静态文件（登录首页、说明文档等）可以设置较长的有效期（expiration date），这些HTTP头向客户端表明了文档的有效性和持久性。如果有缓存，文档就可以从缓存（除已经过期）而不是从服务器读取。接着，客户端考察缓存中的副本，看看是否过期或者失效，以决定是否必须从服务器获得更新。
各个容器都有针对的方案,，以 Apache 为例：
ExpiresActive On ExpiresByType image/gif “access plus 1 weeks”
表示gif文件缓存一周，配置可以根据具体的业务进行调整，具体配置可以参考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_expires.html
2.压缩内容
对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。
表示zlib在压缩时可以最大程度的使用内存，压缩html、文本、xml和php这几种类型的文件，指定扩展名为html、htm、xml、php、css和js的文件启用压缩。
具体配置可以参考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_deflate.html
3.设置 Etags
在使用etags之前，有必要复习一下 RFC2068 中规定的返回值 200 和 304 的含义：
200--OK 304--Not Modified
客户端在请求一份文件的时候，服务端会检查客户端是否存在该文件，如果客户端不存在该文件，则下载该文件并返回200；如果客户端存在该文件并且该文件在规定期限内没有被修改（Inode，MTime和Size），则服务端只返回一个304，并不返回资源内容，客户端将会使用之前的缓存文件。而etags就是判断该文件是否被修改的记号，与服务器端的资源一一关联，所以etags对于CGI类型的页面缓存尤其有用。
下图是优化前的首页：（注意，此时没有压缩首页图片，即使使用了缓存，仍需要5s左右的时间）
化前的某页面
需要注意的是，使用etags会增加服务器端的负载，在实际应用中需要自行平衡。
二、Cookie优化
1.减小Cookie体积
HTTP coockie可以用于权限验证和个性化身份等多种用途。coockie内的有关信息是通过HTTP文件头来在web服务器和浏览器之间进行交流的。因此保持coockie尽可能的小以减少用户的响应时间十分重要。
使cookie体积尽量小；
在合适的子域名上设置bookie，以免影响其他子域名下的响应；
设置合理的过期时间，去掉不必要的cookie。
下面对比一下各个网站的cookie：
图中可以看出，6K的cookie显然是不必要的。
2.对于页面内容使用无coockie域名
当浏览器在请求中同时请求一张静态的图片和发送coockie时，服务器对于这些coockie不会做任何地使用。因此它们只是因为某些负面因素而创建的网络传输。所以你应该确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。
例如，域名是
3.切分组件到多个域
主要的目的是提高页面组件并行下载能力，但注意，也不要同时使用过多的域名，否则就会出现第一条DNS lookup过多的问题，一般情况下两个域名就可以了。
4.杜绝 http 404 错误
对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪可以有效减少 404 错误，并提升用户体验。
后记：
这次总结给我带来的启发并不在于提升系统性能性能本身，提升性能只是一个很表面上的东西，网上的方法有很多，测试的方法也有很多，照着都做一遍，性能确实会有所提升，但是这种知其然而不知其所以然的性能提升是没有意义的，这便是本文的目的所在。
点击咨询 