前言

高性能一直是我們作為程式員..孜孜不倦的追求..

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

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

今天就來講一下這個..

說明一下,本篇是譯文.

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

下面我們就正式開始

正文

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

Apdex 全稱是 Application Performance Index，是由 Apdex 聯盟開放的用于評估應用性能的工業标準。Apdex 聯盟起源于 2004 年，由 Peter Sevcik發起。Apdex 标準從使用者的角度出發，将對應用響應時間的表現，轉為使用者對于應用性能的可量化為範圍為 0-1 的滿意度評價。

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

以及

Tolerating 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應用程式..盡請期待..

作者：顧振印

出處：http://www.cnblogs.com/GuZhenYin/

如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”将是我最大的寫作動力！本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面

應用程式的8個關鍵性能名額以及測量方法