認清性能問題

最近幾天詳細的閱讀了一篇經典的關於軟件性能的文章，閱後解答了我不少迷惑，這篇博客就把本身閱讀後的一些思考和總結分享一下，若有不能理解或想閱覽具體內容的請參考原文和譯文內容。。。。

原文地址：Thinking Clearly About Performance

譯文下載連接：認清性能問題

 

一、響應時間VS吞吐量

   一般來講，響應時間和吞吐量承反比例（響應時間越長吞吐量越低）。

PS：博客發佈後測試羣的一個大神說第一點存在描述問題，因而咱們就這一點聊了些相關的話題，大概的內容和結論是這樣的：

    ①、響應時間和吞吐量並無直接的關係（可是有間接關係）；

    ②、性能優化是須要多維度去衡量和優化的領域；

    ③、通常來講，性能優化的目標是：在儘可能保持和下降響應時間的狀況下，不斷提升吞吐量，提升流量高峯時間的系統服務可用性（大多數狀況，而非所有）；

    ④、響應時間、吞吐量、可用性等因素有時候存在矛盾，須要綜合考慮業務狀況、系統模塊的依賴關係、處理方式（單線程/多線程/負載均衡）等因素，作到合理取捨；

二、描述響應時間的方式

   儘可能用百分比的方式而非平均值來描述響應時間！————用戶感知到的是差別變化，而非平均！

三、性能需求指標

   性能需求指標應該是明確描述的、可量化的指標需求。

四、性能剖析思路

   找到最慢的幾個任務（消耗時間最多），分析它們是否有對應關係，每一個任務的時間佔比，獲得一個明確的描述：每一個任務運行消耗了多少時間！

五、阿姆達爾定律

   系統對某一部件採用更快執行方式所能得到的系統性能提高程度，取決於這種執行方式被使用的頻率，或所佔總執行時間的比例。

六、性能優化排序

   優先佔用資源最多或消耗時間最多的任務，但要考慮優化的成本、收益、風險（沒有最好的方案，只有最合適的方案）。

七、偏斜度

   表示在一組響應時間值中的非一致性程度（好比下面兩組值的對比）

   ①、表現值和實際值

   ②、平均響應時間和95%響應時間

八、最小化風險

   確認問題根節點，不要讓局部影響到全局。

九、提高效率

   性能優化優先原則：首先專一於業務上最須要優先修正的程序，而不是從全局調優來改善性能。

十、負載

   負載的一個直觀測量指標：使用率（反映了資源按時間分片的使用狀況）；

   負載會在併發任務執行時引起資源競爭；

   引發負載上升系統變慢的2個緣由：隊列延遲和相關性延遲（資源競爭，等待，死鎖等）

十一、響應時間

    特色：在具有完美擴展性的前提下：RT=servertime（任務執行時間）+querywaittime（隊列等待時間）

十二、拐點

    響應時間和吞吐量之間的某個最優負載平衡點的資源使用率的值，稱爲拐點。

    計算公式：響應時間/資源利用率=所得結果最小的值

    

1三、拐點相關性

    在完美擴展性前提下，只要系統的平均負載超過拐點，那麼系統依然會面臨性能瓶頸，實際生產中的拐點比上圖的拐點數值更小。

    拐點主要有如下幾個特色：

    ①、系統中的每一項資源都存在拐點；

    ②、系統的拐點都≤上圖中給出的值，系統的擴展完美型越差，拐點越小；

    ③、對於請求隨機到達的系統，若是資源負載持續超過拐點，那麼將遇到性能瓶頸；

1四、隨機到達

    隨機任務請求每每會彙集等待並引起短暫的資源使用率上升，須要足夠的容量來消費。這種狀況下可能會引起隊列延遲並致使響應時間的明顯波動。（等待時間參考：2/5/8原則）

1五、容量規劃

    容量規劃特色：

    ①、某項資源的容量就是高峯期能夠輕鬆運行任務而資源使用率不會超過拐點的值；

    ②、保持資源利用率低於拐點，系統表現則基本不會低於咱們的指望值；

    ③、若是系統中某項資源超過它的拐點，就會遇到性能瓶頸；

    ④、遇到容量瓶頸，解決方式是：從新配置負載分配（減小負載OR增長容量）；

 

關於這篇文章，最後說起到了一個很明確的觀點：過早的考慮優化系統性能，是一場災難！！！