應用程序的8個關鍵性能指標以及測量方法

 

 

前言

高性能一直是咱們做爲程序員..孜孜不倦的追求..

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

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

今天就來說一下這個..

說明一下,本篇是譯文.

原文地址: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應用程序..盡請期待..