第一篇：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 錯誤，并提升用戶體驗。
后記：
這次總結給我帶來的啟發并不在于提升系統性能性能本身，提升性能只是一個很表面上的東西，網上的方法有很多，測試的方法也有很多，照著都做一遍，性能確實會有所提升，但是這種知其然而不知其所以然的性能提升是沒有意義的，這便是本文的目的所在。
點擊咨詢 