性能測試day03_前端分析調優思路

　　剛剛看到有人支持我寫的博客，表示仍是比較感動的，發現熱心的用戶在個人博客留言說「一個系統天天有200萬在線用戶，問我怎麼設計性能場景？」，其實這個問題呢就屬於業務沒理清，這個問題就像我問你，一個城市一天有一百萬人出行，請幫我找出交通壓力哪裏最大？這個問題一問你便知道無從下手了。

　　好了，咱們接着來學習今天的內容，以前說了後端協議的知識，今天來講說前端的分析，在講述前端分析以前，你們能夠先去看一本書《高性能網址建設指南》，雖然書是十年前的，可是思想仍是能夠的，我在這先給你們列一下書裏面的主要思想。

　　《高性能網址建設指南》書中有個關於前端優化的黃金原則：只有10%~20%最終用戶響應時間花在了下載HTML文檔上，其他80%~90%時間花在了下載頁面的全部組件上。並提出了14個對應的規則，接下來我簡單提一下這14個規則，詳細的能夠去找書看下。

• 規則1---減小HTTP請求（1.多個圖片能夠轉換成圖片地圖；2.css sprintes 合併圖片；3.使用data:url模式內聯圖片；4.合併腳本和樣式表）
• 規則2---使用內容分發網絡CDN
• 規則3---添加Expires頭（完整緩存）
• 規則4---壓縮組件（gzip壓縮方式，圖片和PDF不該該壓縮，其他能夠壓縮）
• 規則5---將樣式表放在頂部（避免無樣式內容閃爍->使用link標籤將其放在head頭部）
• 規則6---將腳本放在底部（放在頂部會阻塞下載，產生白屏現象）
• 規則7---避免CSS表達式（用事件處理器來爲特定的事件提供所指望的動態行爲）
• 規則8---使用外部的JS和CSS（內聯沒法緩存，外置的能夠緩存，並且組件能夠重用，同時下降了耦合度）
• 規則9---減小DNS查找（經過Keep-alive和較少的域名）
• 規則10---精簡Javascript和css（從代碼移除沒必要要的字符（註釋、換行、空格等），css能夠合併相同類，移除不使用的類）
• 規則11---避免重定向（重定向時的第一個HTTP請求會阻塞後面html文檔的加載）
• 規則12---移除重複腳本（沒必要要的HTTP請求和執行javascript所浪費的時間）
• 規則13---配置ETag（服務器檢測緩存組件和原始服務器組件匹配的方式）
• 規則14---使Ajax可緩存（確保Ajax請求遵照性能指導，尤爲應具備長久的Expires頭）

　上面說了那麼多，我想要不舉個實例給你們看看吧，既然如今騰訊這麼有錢，咱們就去看看騰訊的網站吧，咱們用谷歌去訪問下www.qq.com看一下qq官網的性能如何。

咱們從這個點能夠看得出來，訪問qq首頁有215個請求，大小爲3.1M，總共耗時15.44秒，固然可能有個別不重要的請求拖慢了速度，咱們能夠看到大部分請求完成是在6秒左右，可是這也說明了qq的網站可能仍是存在一些前端性能問題的，咱們來具體看幾個請求，從上往下來看：

第一個請求以下：從第一個請求來看，總共花了158.76ms，雖然不是很大可是這個是個什麼請求咱們不太清楚，由於我沒看到具體返回，有多是將用戶信息發送給服務端吧。

我先說下耗時的組成和具體含義：

• Stalled：這個是TCP鏈接檢測過程（若是過長多是丟包致使，有多是網絡或者服務端的問題）
• Request sent：發送時間（取決於上行帶寬和服務器帶寬）
• Waiting：等待時間（服務器處理時間）
• Content Download：接收時間（取決於下行帶寬和服務器帶寬）

接着咱們看第二個主要的請求：能夠看到這個請求的返回是標準的html和內嵌了css和js，並未進行壓縮，並且也是混寫的，因此其實這個返回是能夠進行優化的。

接着咱們能夠去看，基本上一半的請求都是下載圖片，我想這麼圖片的請求是否是又能夠再進行優化呢（一個頁面200多個請求我的感受是不少的，由於每個請求就是一次交互過程，若是一臺服務器總的hps（hit per second）是固定的，請求數越少是否是就意味着能支持的併發數就會越多呢？尤爲是對騰訊大公司而言，假設首頁減小10個請求，100w的用戶的訪問，那麼就能夠減小總共1000w的請求呢，那麼這個是否是就意味着能夠減小上百臺甚至更多的服務器了呢？因此我感受qq的性能估計是服務器累出來的，但這個能省的錢是否是還能再省一點呢？好比請一個好一點的性能專家呢？哈哈哈，開個玩笑哈！）？我相信qq的首頁前端仍是有必定的優化空間的（當前訪問qq慢也有我的網速不是太好的緣由，不要太計較哈，嘻嘻）。

好了，咱們接着來學習吧，在性能測試的時候，我想最重要的應該仍是「分析思路」，猜想（根據監控和經驗（因此說要很廣的知識面））->測試->驗證->確認，這四個過程不斷循環，這就是性能的分析思路。

這裏提一點，大部分性能問題來源於數據庫喔！

一直說性能須要很廣的知識面，這個是必然的，別人寫一個東西，若是你不清楚別人怎麼寫的並且知道怎麼寫才更好，又怎麼能幫助別人調優呢？因此具有開發、監控、網絡、數據庫、配置等能力都是必不可少的，固然還得有編寫報告和必定的邏輯思惟能力喔！

 　　今天的最後咱們來講一下性能調優的一些思路：

• 化點播爲廣播：至關於服務器主動push資源給客戶端，而不用每一個客戶端主動去請求（電臺廣播和1對1的電話交流的區別）
• 化同步爲異步：異步就至關於用戶請求後先記錄過一段時間再給服務器而後返回，減輕服務器壓力（就像咱們發微信朋友圈，有可能發了一段時間後系統會提示咱們發送失敗，因此是一個異步過程，固然這個發朋友圈也是一個廣播的過程）
• 化實時計算爲預算：點播後異步靜態化廣播（像咱們評論，這個點播計算後經過異步而後靜態化給中間件服務器再廣播給客戶端）
• 層層降級：像秒殺這類操做，整個過程就是1.前端先擋一部分（過濾99%的請求）；2.後臺web端服務器擋一部分（再次過濾99%的請求）；3.而後在代碼中對一個數據類型進行存放，獲取能存入的記錄；4.對這個數據類型一次性寫數據庫

前三天的課程咱們已經將性能的總體思路給你們理了下，接下來的幾天我會跟你們講解下性能的又一大難點--->性能監控，可能須要有必定的linux基礎，能夠提早學習下喔！