应用程序的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應用程序..盡請期待..
相關文章：?
互聯網級監控系統必備-時序數據庫之Influxdb技術
互聯網級監控系統必備-時序數據庫之Influxdb集群及踩過的坑
原文地址：http://www.cnblogs.com/GuZhenYin/p/7161480.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的应用程序的8个关键性能指标以及测量方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ASP.NET Core之跨平台的实时性
- 下一篇： 推荐一份基于Docker的DevOps实