JAVA性能優化調查結果(第二部分)

杜老師說 2022-01-07 08:11:02 阅读数:550

java 性能 第二部 第二 二部

原文地址 原作者:Nikita Salnikov Tarnovski  譯者 嚴亮 校對:方騰飛(清英)

這是我們在2014年10月做的性能調優調查結果系列的第2部分,如果您還沒讀過第1部分。我推薦先讀第1部分。第2部分我們關注Java應用性能的監控問題。我們特別要嘗試弄清楚下面幾個問題:

  • 如何發現性能問題
  • 這些問題都有什麼樣的錶現
  • 這些問題有多少會影響最終用戶
  • 使用什麼工具監控應用

發現性能問題
解决性能故障的前提是要先發現問題。我們詢問受訪者通過什麼方式發現性能問題。286比特受訪者列舉出406種方式。常見的幾種方式如下:軟件監控,支持中心或郵件,負載或壓力測試:

how-did-you-find-out-about-the-performance-issue

 

考慮到很多受訪者來自工程師,我們驚訝的發現超過58%的受訪者提出監控軟件這種方式,同時 38%的受訪者提出壓力測試。這個數據也證明了我在日常工作中的發現: 大多數公司沒有專門人員做壓力測試,創建和維護這樣的測試太費時,經常會被忽略。被7比特受訪者歸類到 “其他方式”,大部分是上線流程,例如外部性能審計。

性能問題的錶現特征
這個問題我們希望弄清楚性能問題的錶現特征,286 受訪者列出 462 錶現特征:
symptoms-of-performance-issue

到目前為止,最常見的特征是資源過度消耗(例如CPU,內存,IO等),205比特受訪者選擇這項。顯然,監控最終用戶操作的方式不太常見,因為監控太過複雜,大多數的系統依然是監控資源消耗,而不是最終用戶的操作。另一方面,事實上,17%的受訪者只有在服務完全不可用時,才會發現性能問題,更好的說明了性能問題的嚴重性。

是否影響最終用戶
下面我們來看這些問題是否會影響最終用戶。284比特受訪者錶現如下:
java-performance-issue-affecting-end-users

82%的受訪者回答“是”,證明了我們的猜想:只有在影響到最終用戶時,性能問題才會引起重視。企業方傾向於增加新功能或完善已有功能,非功能性的需求例如性能,並沒有得到應有的重視。只有在性能問題嚴重到引起用戶抱怨時,才會分配一些資源處理這些問題。

使用的監控工具
本次調查中一個有趣的情况是當前使用監控工具的分布。我們詢問受訪者在正式環境中使用監控工具。284 比特受訪者列舉出365種使用過的工具,而且其中一部分受訪者使用超過5種工具。
java-most-common-performance-monitoring-tools

前三個選項讓人有些驚訝:

  1. 最常見的回答是“沒有”,意味著21%的受訪者沒有使用任何工具監控正式環境
  2. 最常用的工具是仍然是最老舊的Nagios(已經15歲了)。 51 比特 ( 18% )受訪者錶示使用過 Nagios
  3. 第3比特,“其它”選項,包括了38種不同的工具只獲得了1-2票。可以說這個市場非常廣大,有一些工具已經開始占據市場份額。

接下來的 NewRelic, Zabbix, AppDynamics 和 Oracle Enterprise Managers 占到 7% ~13% 之間。NewRelic 和 AppDynamics 有廣泛的應用是可以理解的,但 Zabbix 和 Oracle Enterprise Manager 的廣泛使用有點出人意料。

值得一提的是自建應用和 JVM工具。自建應用選項不在我們的列錶中,有6%的受訪者提到使用自建應用監控,有點出人意料。

末尾的幾個工具提到過幾次,看到大廠商 APM 的工具(CA, Compuware and BMC)被最簡單的工具 Pingdom 擊敗,有點讓人驚歎。根據調查結果,我們承認 Plumbr 的排名有點偏頗,所以對這個排名不要太當真。

原創文章,轉載請注明: 轉載自並發編程網 – ifeve.com本文鏈接地址: JAVA性能優化調查結果(第二部分)

FavoriteLoading添加本文到我的收藏
版权声明:本文为[杜老師說]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201070811014866.html