高效能一直是我們作為程式設計師..孜孜不倦的追求..

有的時候甚至會為了一句程式碼吵上幾天..

那麼到底應該如何評估我們的效能指標來判斷是否需要優化呢?

今天就來講一下這個..

說明一下,本篇是譯文.

原文地址:https://stackify.com/application-performance-metrics/

下面我們就正式開始

1.使用者滿意度/ Apdex分數

Apdex 全稱是 Application Performance Index，是由 Apdex 聯盟開放的用於評估應用效能的工業標準。Apdex 聯盟起源於 2004 年，由 

Apdex 定義了應用響應時間的最優門檻為 T，另外根據應用響應時間結合 T 定義了三種不同的效能表現：

• Satisfied（滿意）：應用響應時間低於或等於 T（T 由效能評估人員根據預期效能要求確定），比如 T 為 1.5s，則一個耗時 1s 的響應結果則可以認為是 satisfied 的。
• Tolerating（可容忍）：應用響應時間大於 T，但同時小於或等於 4T。假設應用設定的 T 值為 1s，則 4 * 1 = 4 秒極為應用響應時間的容忍上限。
• Frustrated（煩躁期）：應用響應時間大於 4T。

公式如圖:

其中 Satisfied Count 就是指定取樣時間內響應時間滿足 Satisfied 要求的應用響應次數；而 Tolerating Count 就是指定取樣時間內響應時間滿足 Tolerating 要求的應用響應次數；最後的 Total Samples 就是總的取樣次數總數。從公式可以看出，應用的 Apdex 得分與取樣持續時間無關，與目標響應時間 T 相關（在採用總數固定的情況下，T 通過影響 Satisfied Count

假設你的應用期待的響應時間能夠在 1000 ms 內，在 100 次取樣中，有 50 次應用響應時間低於 1000 ms，30 次應用響應時間處於 1000 ms 到 4000 ms（ 4 * 1000ms） 之間，剩下 20 次響應時間長於 4000 ms，那麼，該應用在 T = 1000ms 的情況下的 Apdex 值為：

(50 + 30 / 2) / 100 = 0.65

2.平均響應時間

這個,就不做過多解釋了 - - ,嗯..字面意思很明白.

3.錯誤率

監控錯誤率也是關鍵的應用程式效能指標~

我們一般有三種不同的方式來跟蹤應用程式錯誤：

• HTTP錯誤百分比 - 以錯誤結束的Web請求數量佔的比例.
• 已記錄的異常 - 應用程式中未處理和記錄的錯誤的數量
• 丟擲的異常-所有已被丟擲的異常

在應用程式中，我們可能會丟擲並忽略數千個異常。

然而這些隱藏的應用程式異常通常會導致很多效能問題。

4.應用例項計數

如果我們的應用程式在雲中升級並使用了伸縮彈性擴張服務.

請務必知道執行的伺服器/應用程式例項數量。

伸縮彈性擴張服務確實可以幫助我們確保應用程式的擴充套件以滿足需求，並在非高峰時間節省很多成本.

但是,這也帶來了一些獨特的監控挑戰。

舉個栗子，如果我們的應用程式根據CPU使用率自動升級，我們可能看不到CPU變高。但是我們會看到伺服器例項的數量變高。（更不用說我們的主機帳單..正在嗖嗖嗖...燒錢！）

5.Request請求率

瞭解我們的應用程式獲得的流量會影響我們的應用程式的成功與否。

請求率的增加或減少或多或少都會影響到其他各項效能指標.

Request請求率可以於與其他應用程式效能指標相關聯，以瞭解應用程式擴充套件的動態。

監控請求率也可以很好地觀察峰值和一些不活動的API。如果你有一個請求量很大的API突然沒有請求率，這應該是一件非常糟糕的事情,要注意。

當然你也可以根據這些資料來跟蹤和發現自己的併發使用者數量.

6.應用程式和伺服器CPU

如果我們的伺服器上的CPU使用率非常高.

我們可以保證我們的應用程式效能出現了的問題。(這是句廢話 - -,)

所以監控應用程式伺服器CPU的使用情況是一個基本和關鍵的指標。

幾乎所有的伺服器和應用程式監視工具都可以跟蹤我我們的CPU使用情況並提供監控警報。

因為每個伺服器它們是很重要的.

7.應用可用性

監控和測量我們的應用程式是否線上並且可用也是我們應該跟蹤的關鍵指標。

大多數公司使用它來衡量服務級別協議（SLA）的正常執行時間。

如果您有Web應用程式，則通過簡單的定時HTTP檢查小程式,來監視應用程式可用性是最簡單的方法。

你可以每分鐘為你執行這些型別的HTTP“ping”檢查。

它可以是監視響應時間，狀態程式碼，也可以是查詢頁面上的特定內容。

8.垃圾回收

如果我們的應用程式是用.NET，C＃或其他使用GC程式語言編寫的，

那麼我們要提前會意識到可能會產生的效能問題。

垃圾回收發生時，可能導致我們的程序掛起並佔用很多CPU。

垃圾回收指標雖然不是我們對關鍵效能指標的首選項。

但是這可能是一個隱藏的效能問題，始終是一個很好的主意，要注意。

對於.NET，您可以通過效能計數器“％ GC Time”來監控這一點。Java通過JMX指標具有類似的功能。Retrace可以通過其應用程式指標功能監視這些內容。

前面說了這麼多....那麼作為我們.NET er 的新寵.. .NETCore我們如何監控他的8項效能指標呢?

監視效果如下:

我們下一篇就來講..如何監控.Net Core應用程式..盡請期待..