系統效能評價---效能設計
效能設計
1 阿姆達爾解決方案
阿姆達爾定律是這樣的:系統中對某部件採用某種更快的執行方式,所獲得的系統效能的改變程度,取決於這種方式被使用的頻率,或所佔總執行時間的比例。
阿姆達爾定律定義了採用特定部件所取得的加速比。假定使用某種增強部件,計算機的效能就會得到提高,那麼加速比就是如下公式所定義的比率:
加速比反映了使用增強部件後完成一個任務比不使用增強部件完成同一任務加快了多少。阿姆達爾定律為計算某些情況下的加速比提供了一種便捷的方法。加速比主要取決於兩個因素:
(1)在原有的計算機上,能被改進並增強的部分在總執行時間中所佔的比例。這個值稱之為增強比例,它永遠小於等於 1。
(2)通過增強的執行方式所取得的改進,即如果整個程式使用了增強的執行方式,那麼這個任務的執行速度會有多少提高,這個值是在原來條件下程式的執行時間與使用增強功能後程式的執行時間之比。
原來的機器使用了增強功能後,執行時間等於未改進部分的執行時間加上改進部分的執行時間:
2 負載均衡
負載均衡是由多臺伺服器以對稱的方式組成一個伺服器集合,每臺伺服器都具有等價的地位,都可以單獨對外提供服務而無須其他伺服器的輔助。通過某種負載分擔技術,將外部傳送來的請求均勻地分配到對稱結構中的某一臺伺服器上,而接收到請求的伺服器獨立地迴應客戶的請求。
當使用者發現 Web 站點負載量非常大時,應當考慮使用負載均衡技術來將負載平均分攤到多個內部伺服器上。如果有多個伺服器同時執行某一個任務時,這些伺服器就構成一個叢集。使用叢集技術可以用最少的投資獲得接近於大型主機的效能。
1.負載均衡技術的型別
目前,比較常用的負載均衡技術主要有以下幾種:
(1)基於特定伺服器軟體的負載均衡。很多網路協議都支援“重定向”功能,例如,在HTTP 協議中支援 Location 指令,接收到這個指令的瀏覽器將自動重定向到 Location 指明的另一個 URL 上。由於傳送 Location 指令比起執行服務請求,對 Web 伺服器的負載要小得多,因此可以根據這個功能來設計一種負載均衡的伺服器。當 Web 伺服器認為自己負載較大的時候,它就不再直接傳送回瀏覽器請求的網頁,而是送回一個 Location 指令,讓瀏覽器在伺服器叢集中的其他伺服器上獲得所需要的網頁。
在這種方式下,伺服器本身必須支援這種功能,然而具體實現起來卻有很多困難。例如,一臺伺服器如何能保證它重定向過的伺服器是比較空閒的,並且不會再次傳送 Location 指令?Location 指令和瀏覽器都沒有這方面的支援能力,這樣很容易在瀏覽器上形成一種死迴圈。因此這種方式實際應用當中並不多見,使用這種方式實現的伺服器叢集軟體也較少。有些特定情況下可以使用 CGI(包括使用 FastCGI 或 mod_perl 擴充套件來改善效能)來模擬這種方式去分擔負載,而 Web 伺服器仍然保持簡潔、高效的特性。此時,避免 Location 迴圈的任務將由使用者的 CGI 程式來承擔。
(2)基於 DNS(Domain Name Server,域名伺服器)的負載均衡。通過 DNS 服務中的隨機名字解析來實現負載均衡,在 DNS 伺服器中,可以為多個不同的地址配置同一個名字,而最終查詢這個名字的客戶機將在解析這個名字時得到其中一個地址。因此,對於同一個名字,不同的客戶機會得到不同的地址,它們也就訪問不同地址上的 Web 伺服器,從而達到負載均衡的目的。
DNS 負載均衡的優點是簡單易行,並且伺服器可以位於網際網路的任意位置上,當前使用在包括Yahoo 在內的 Web 站點上。然而它也存在不少缺點,一個缺點是為了保證 DNS 資料及時更新,一般都要將 DNS 的重新整理時間設定得較小,但太小就會造成太大的額外網路流量,並且更改了 DNS 資料之後也不能立即生效;另一個缺點是 DNS 負載均衡無法得知伺服器之間的差異,它不能做到為效能較好的伺服器多分配請求,也不能瞭解到伺服器的當前狀態,甚至會出現客戶請求集中在某一臺伺服器上的偶然情況。
(3)反向代理負載均衡。使用代理伺服器可以將請求轉發給內部的 Web 伺服器,使用這種加速模式顯然可以提升靜態網頁的訪問速度。因此也可以考慮使用這種技術,讓代理伺服器將請求均勻地轉發給多臺內部 Web 伺服器,從而達到負載均衡的目的。這種代理方式與普通的代理方式有所不同,標準代理方式是客戶使用代理訪問多個外部 Web 伺服器,而這種代理方式是多個客戶使用它訪問內部 Web 伺服器,因此也被稱為反向代理模式。
實現這個反向代理能力並不能算是一個特別複雜的任務,但是在負載均衡中要求特別高的效率,這樣實現起來就不是十分簡單的事了。每針對一次代理,代理伺服器就必須開啟兩個連線,一個為對外的連線,一個為對內的連線。因此,當連線請求數量非常大的時候,代理伺服器的負載也非常大,最後,反向代理伺服器會成為服務的瓶頸。例如,使用 Apache 的 mod_rproxy 模組來實現負載均衡功能時,提供的併發連線數量受 Apache 本身的併發連線數量的限制。一般來講,可以使用它來連線數量不是特別大、但每次連線都需要消耗大量處理資源的站點來進行負載均衡,例如搜尋。
使用反向代理的好處是,可以將負載均衡和代理伺服器的快取記憶體技術結合在一起,以提供有益的效能;其具備額外的安全性,外部客戶不能直接訪問真實的伺服器。並且實現起來可以採用較好的負載均衡策略,將負載非常均衡地分給內部伺服器,不會出現負載集中到某個伺服器的偶然現象。
(4)基於 NAT(Network Address Translation,網路地址轉換)的負載均衡技術。網路地址轉換指的是在內部地址和外部地址之間進行轉換,以便具備內部地址的計算機能訪問外部網路,而當外部網路中的計算機訪問地址轉換閘道器擁有的某一外部地址時,地址轉換閘道器能將其轉發到一個對映的內部地址上。因此如果地址轉換閘道器能將每個連線均勻轉換為不同的內部伺服器地址,此後,外部網路中的計算機就各自與自己轉換得到的地址上的伺服器進行通訊,從而達到負載分擔的目的。
地址轉換可以通過軟體方式來實現,也可以通過硬體方式來實現。使用硬體方式進行操作一般稱為交換,而當交換必須儲存 TCP 連線資訊的時候,這種針對 OSI/RM 網路層的操作就被稱為第四層交換。支援負載均衡的網路地址轉換為第四層交換機的一種重要功能,由於它基於定製的硬體晶片,因此其效能非常優秀,很多交換機聲稱具備 400MB~ 800MB 的第四層交換能力;然而也有一些資料表明,在如此快的速度下,大部分交換機就不再具備第四層交換能力了,而僅僅支援第三層甚至第二層交換。
使用軟體方式來實現基於網路地址轉換的負載均衡則要實際得多,除了一些廠商提供的解決方法之外,更有效的方法是使用免費的自由軟體來完成這項任務。其中包括 Linux Virtual Server Project 中的 NAT 實現方式。一般來講,使用這種軟體方式來實現地址轉換,中心負載均衡器存在頻寬限制,在 100MBps 的快速乙太網條件下,能得到最高達 80MBps 的頻寬,然而在實際應用中,可能只有 40MBps~60MBps 的可用頻寬。
(5)擴充套件的負載均衡技術。上面使用網路地址轉換來實現負載分擔,毫無疑問所有的網路連線都必須通過中心負載均衡器,那麼如果負載特別大,以至於後臺的伺服器的數量不再在是幾臺、十幾臺,而是上百臺甚至更多,這時,即便是使用效能優秀的硬體交換機也會遇到瓶頸。此時問題將轉變為,如何將那麼多臺伺服器分佈到各個網際網路的多個位置,分散網路負擔。當然這可以通過綜合使用 DNS 和 NAT 兩種方法來實現,然而更好的方式是使用一種半中心的負載均衡方式。
在這種半中心的負載均衡方式下,即當客戶請求傳送給負載均衡器的時候,中心負載均衡器將請求打包併傳送給某個伺服器,而伺服器的迴應請求不再返回給中心負載均衡器,而是直接返回給客戶,因此中心負載均衡器只負責接受並轉發請求,其網路負擔就較小了。
2.伺服器負載均衡
伺服器負載均衡一般用於提高伺服器的整體處理能力,並提高可靠性、可用性和可維護性,最終目的是加快伺服器的響應速度,從而提高使用者的體驗度。
負載均衡從結構上分為本地負載均衡(Local Server Load Balance)和全域負載均衡(Global Server Load Balance),前者是指對本地的伺服器群做負載均衡,後者是指對分別放置在不同的地理位置、有不同的網路及伺服器群之間做負載均衡。
全域負載均衡有以下特點:
(1)解決網路擁塞問題,服務就近提供,實現地理位置無關性;
(2)對使用者提供更好的訪問質量;
(3)提高伺服器響應速度;
(4)提高伺服器及其他資源的利用效率;
(5)避免了資料中心單點失效。
相關文章
- 系統效能評價---效能評估
- 計算機效能評價指標計算機指標
- 資訊系統效能評測
- Simple TPU的設計和效能評估
- 感知系統效能評估分析解決方案
- 如何評價我們分類模型的效能?模型
- 迴歸模型的演算法效能評價模型演算法
- 分類模型的演算法效能評價模型演算法
- 聚類模型的演算法效能評價聚類模型演算法
- PostgreSQL類微博FEED系統-設計與效能指標SQL指標
- 每週要聞速遞|英特爾進軍資料中心GPU;《高效能運算系統效能評價白皮書》釋出GPU
- 效能場景設計
- 大型網站背後的高效能系統架構設計網站架構
- 做好陪玩系統原始碼的前端效能優化,提升系統效能原始碼前端優化
- SAP 系統效能分析 Tcode
- Linux效能評估工具Linux
- JuiceFS 效能評估指南UI
- 3.分散式服務架構:原理、設計與實戰 --- 服務化系統容量評估和效能保障分散式架構
- 測試開發之效能篇-效能測試設計
- 從 HPC 到 AI:探索檔案系統的發展及效能評估AI
- B站評論系統架構設計架構
- JMeter—系統效能分析思路(十三)JMeter
- sysstat——系統效能監控神器
- Linux系統效能調優技巧Linux
- Geekbench 5 測系統效能工具
- Linux新核心:提升系統效能Linux
- 系統效能優化總結優化
- 【效能優化】秒殺系統效能優化初體驗優化
- 高效能佇列設計佇列
- 【IO】IO系統效能之一:衡量效能的幾個指標指標
- 從時延毛刺問題定位到 Netty 的效能統計設計Netty
- 網路配置及程序-系統效能和計劃任務
- 社交系統ThinkSNS+ 效能簡述
- 系統架構效能優化思路架構優化
- MySQL效能優化之索引設計MySql優化索引
- 谷歌效能測評工具lighthouse使用谷歌
- win10系統電源計劃中只有平衡效能怎麼切換為高效能模式Win10模式
- 推薦系統 TOP K 評價指標指標