【讀書筆記】高性能網站架構-瞬時響應

4、高性能-瞬時響應

檢查請求各個環節的誒之,分析哪個環節響應時間不合理、超出預期;
檢查監控數據,分析影響性能的主要因素是內存、磁盤、網絡、還是 CPU,是代碼問題還是架構設計不合理,或者系統資源確實不足。

性能測試指標

響應時間、併發數、吞吐量、性能計數器等。

響應時間

每個響應時間比較短不好測試,常用方法是重複請求很多次,求平均時間。

併發數

系統能夠同時處理請求的數目,對於網站而言,指同時提交請求的用戶數目。


測試程序通過多線程/協成模擬併發用戶的辦法來測試系統的併發處理能力,爲了真實的模擬用戶行爲,測試程序並不是啓動多線程後不停地發送請求,而是再兩次請求中間加入一個隨機等待時間,被稱爲思考時間。

吞吐量

TPS(每秒事務數)
HPS(每秒HTTP請求數)
QPS(每秒查詢數)

性能計數器

System Load、對象與縣城數、內存使用、CPU 使用、磁盤與網絡 I/O 等指標。
系統監控、報警。


System Load(系統負載),指當前正在被 CPU 執行和等待被執行的進程數目總和,是反應系統忙閒程度的重要指標。
Load 理想值是 CPU 數目,Load 高於 CPU 數目的時候表示系統資源不足,影響程序的執行性能。

top 命令查看,3 個浮點數,表示最近 1min、5min、15min 運行隊列平均進程數。

性能優化

前端性能優化

減少 HTTP 請求

合併 CSS 文件、合併 JS 文件、合併圖片、懶加載等。

使用瀏覽器緩存

緩存 CSS、JS、Logo、圖表等靜態資源。
通過設置 HTTP 頭中的 Cache-Control 和 Expires 屬性,控制瀏覽器的緩存。

有時候靜態資源變化需要及時應用到瀏覽器,可以通過修改文件名實現,即更新 JS 文件並不更新 JS 文件內容。

逐漸更新:一次更新一部分圖標文件等等。

啓用壓縮

文本文件的壓縮可達 80% 以上,因此 HTML、CSS、JS 通過啓用 GZip 壓縮可以達到好的效果,但是壓縮對服務器和瀏覽器會產生一定的壓力,在網絡狀況好的情況下要權衡考慮。

CSS 放在頁面最上面,JS 放在頁面最下面

瀏覽器會在下載完全部的 CSS 後纔對網頁進行渲染。
瀏覽器在加載 JS 後立即執行,有可能阻塞整個頁面。

減少 Cookie 傳輸

減少 Cookie 次數。Cookie 會包含在每次的請求和響應中,太大的 cookie 會影像數據傳輸。
靜態資源的傳輸,有時候帶上 Cookie 沒有意義,有的時候有意義(比如圖片驗證碼)。

CDN 加速

emmm 類似於緩存

反向代理

emmm 類似於緩存

服務端性能優化

網站性能優化第一定律:優先考慮緩存優化性能。

分佈式緩存

注意要合理使用緩存。緩存穿透、雪崩、擊穿!!!
頻繁修改的數據!
沒有熱點的訪問!
數據不一致和髒讀!
緩存可用性!


緩存預熱!

異步操作

消息隊列等。
消息隊列(削峯作用)。

使用集羣

配置負載均衡。

代碼優化

多線程、協成。
資源使用統一管理(池,進程池、線程池、連接池、對象池、單例)

數據結構

哈希?

垃圾回收

。。。

存儲性能優化

機械硬盤、固態硬盤。

B+樹、LSM 樹。

傳統的關係數據庫使用的是 B+ 樹,層次最多三層。
現在很多 NoSQL 數據庫使用 LSM 樹。

存儲陣列

RAID0、RAID1、RAID10、RAID5、RAID6。
HDFS 中,系統在整個存儲集羣的多態服務器上進行數據併發讀寫備份,可以看做在服務器集羣規模上上線了類似 RAID 的功能,因此不需要磁盤 RAID。
MapReduce 併發訪問,遷移計算而不是不遷移數據。


HDFS 中兩個重要的服務器角色:NameNode(名字服務器節點)和 DataNode(數據存儲節點)。
NameNode 在 HDFS 中只部署一個實例,提供元數據服務,相當於操作系統中的文件分配表 FAT,管理文件名 Block 的分配,維護整個文件系統的結構。
DataNode 則部署在 HDFS 集羣中其他所有服務器上,提供真正的數據存儲服務。




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章