最近幾天詳細的閱讀了一篇經典的關於軟件性能的文章，閱后解答了我很多迷惑，這篇博客就把自己閱讀后的一些思考和總結分享一下，如有不能理解或想閱覽具體內容的請參考原文和譯文內容。。。。
原文地址：Thinking Clearly About Performance
譯文下載鏈接：認清性能問題
1、響應時間VS吞吐量
通常來說，響應時間和吞吐量承反比例（響應時間越長吞吐量越低）。
PS：博客發布后測試群的一個大神說第一點存在描述問題，於是我們就這一點聊了些相關的話題，大概的內容和結論是這樣的：
①、響應時間和吞吐量並沒有直接的關系（但是有間接關系）；
②、性能優化是需要多維度去衡量和優化的領域；
③、一般來說，性能優化的目標是：在盡量保持和降低響應時間的情況下，不斷提高吞吐量，提高流量高峰時間的系統服務可用性（大多數情況，而非全部）；
④、響應時間、吞吐量、可用性等因素有時候存在矛盾，需要綜合考慮業務情況、系統模塊的依賴關系、處理方式（單線程/多線程/負載均衡）等因素，做到合理取舍；
2、描述響應時間的方式
盡量用百分比的方式而非平均值來描述響應時間！————用戶感知到的是差異變化，而非平均！
3、性能需求指標
性能需求指標應該是明確描述的、可量化的指標需求。
4、性能剖析思路
找到最慢的幾個任務（消耗時間最多），分析它們是否有對應關系，每個任務的時間占比，得到一個明確的描述：每個任務運行消耗了多少時間！
5、阿姆達爾定律
系統對某一部件采用更快執行方式所能獲得的系統性能提升程度，取決於這種執行方式被使用的頻率，或所占總執行時間的比例。
6、性能優化排序
優先占用資源最多或消耗時間最多的任務，但要考慮優化的成本、收益、風險（沒有最好的方案，只有最合適的方案）。
7、偏斜度
表示在一組響應時間值中的非一致性程度（比如下面兩組值的對比）
①、表現值和實際值
②、平均響應時間和95%響應時間
8、最小化風險
確認問題根節點，不要讓局部影響到全局。
9、提升效率
性能優化優先原則：首先專注於業務上最需要優先修正的程序，而不是從全局調優來改善性能。
10、負載
負載的一個直觀測量指標：使用率（反映了資源按時間分片的使用情況）；
負載會在並發任務執行時引發資源競爭；
引起負載上升系統變慢的2個原因：隊列延遲和相關性延遲（資源競爭，等待，死鎖等）
11、響應時間
特點：在具備完美擴展性的前提下：RT=servertime（任務執行時間）+querywaittime（隊列等待時間）
12、拐點
響應時間和吞吐量之間的某個最優負載平衡點的資源使用率的值，稱為拐點。
計算公式：響應時間/資源利用率=所得結果最小的值
13、拐點相關性
在完美擴展性前提下，只要系統的平均負載超過拐點，那么系統依然會面臨性能瓶頸，實際生產中的拐點比上圖的拐點數值更小。
拐點主要有以下幾個特點：
①、系統中的每一項資源都存在拐點；
②、系統的拐點都≤上圖中給出的值，系統的擴展完美型越差，拐點越小；
③、對於請求隨機到達的系統，如果資源負載持續超過拐點，那么將遇到性能瓶頸；
14、隨機到達
隨機任務請求往往會聚集等待並引發短暫的資源使用率上升，需要足夠的容量來消費。這種情況下可能會引發隊列延遲並導致響應時間的明顯波動。（等待時間參考：2/5/8原則）
15、容量規划
容量規划特點：
①、某項資源的容量就是高峰期可以輕松運行任務而資源使用率不會超過拐點的值；
②、保持資源利用率低於拐點，系統表現則基本不會低於我們的期望值；
③、如果系統中某項資源超過它的拐點，就會遇到性能瓶頸；
④、遇到容量瓶頸，解決方式是：重新配置負載分配（減少負載OR增加容量）；
關於這篇文章，最后提及到了一個很明確的觀點：過早的考慮優化系統性能，是一場災難！！！