java 性能調優

這是系列文章的第二篇，我們將分析2014年10月進行的性能調整調查的結果。如果您尚未閱讀第一部分，我們建議從此處開始 。 第二部分將重點監視Java應用程序的性能問題。 特別是，我們嘗試回答以下問題：

• 人們如何發現性能問題？
• 這些問題的癥狀是什么？
• 這些問題多久影響一次最終用戶？
• 哪些工具用于監視應用程序？

了解性能問題

在調查任何性能事件之前，需要知道它的存在。 我們要求描述受訪者發現問題存在的渠道。 286人通過列出406個渠道進行了回復：

考慮到大多數受訪者來自工程學方面 ，我們真的感到驚訝的是，超過58％的受訪者將監視軟件列為意識來源。 同時， 只有38％的用戶進行了負載/壓力測試來提醒他們 。

這些數據正在驗證我們在日常工作中看到的內容-大多數公司沒有進行負載測試的可能性-創建和維護此類測試需要時間，并且經常被跳過。

歸類為“其他”的11位受訪者大多是指程序性活動，例如正在進行的外部績效審核。

性能問題的癥狀

有了這個問題，我們希望了解問題的癥狀。 286位受訪者列出了462個癥狀來回答以下問題：

到目前為止，引發進一步研究的最常見癥狀是過度使用資源（例如CPU，內存，IO等）。 205，占72％的受訪者將其列為癥狀之一。 顯然，監視最終用戶交易的情況不那么廣泛-通過更復雜的設置，仍然可以從資源端監視大多數系統，而無需考慮最終用戶的交易。

另一方面，與績效相關問題的嚴重性很好地說明了這一事實，即只有17％的受訪者僅在完全服務中斷后才了解問題 。

對最終用戶有影響嗎？

接下來，我們了解了當前的問題是否正在影響最終用戶。 284條回應給了我們以下見解：

回答“是”的82％的受訪者證實了我們的直覺– 只有在相關問題開始影響最終用戶時，性能才引起關注 。 業務方面傾向于將重點放在添加新功能/改進現有功能上，而使諸如性能之類的非功能需求沒有引起應有的關注。 而且只有當對性能的影響如此之大以致最終用戶開始抱怨時，才會分配一些資源來解決當前的問題。

使用的監控解決方案

此次調查中潛在的最有趣的見解之一是當前的監視環境-我們要求受訪者確定他們在生產現場使用的監視解決方案。 284位受訪者列出了365種工具，因為一些受訪者最多使用五種工具來監視其部署：

領獎臺上的地方有些令人驚訝：

該問題最常見的答案是“無”，這意味著21％的受訪者不使用任何工具 來監視生產現場 。

最常用的工具仍然是15歲的Nagios。 51人（ 占受訪者的18％ ）將Nagios列為他們用于監控的工具之一。

第三名被列為“ 其他 ”，由38個不同的工具組成，所有工具均得到1-2次提及。 因此，我們可以說市場上的參與者數量很大，只有一些工具設法獲得了有意義的市場份額。

該列表中的下一個：在7％到13％的案例中提到了NewRelic，Zabbix，AppDynamics和Oracle Enterprise Managers。 預計NewRelic和AppDynamics具有廣泛的部署基礎，但是Zabbix和Oracle Enterprise Manager的部署頻率肯定是出乎意料的。

還值得一提的是自建解決方案和JVM工具的數量。 自建解決方案甚至不在我們的答案列表中，因此讓6％的受訪者構建自己的監控解決方案有點令人驚訝。

結果的尾部包含四次或更多次提到的工具。 看到大型APM供應商（CA，Compuware和BMC）被最簡單的工具Pingdom打敗，這真是很奇怪。

由于該調查已列在我們的網站上，因此我們確實承認Plumbr在此列表中的位置很可能有偏差，因此請以健康的食鹽代替我們在此列表中的位置。

翻譯自: https://www.javacodegeeks.com/2014/11/java-performance-tuning-survey-results-part-ii.html

java 性能調優

總結

以上是生活随笔為你收集整理的java 性能调优_Java性能调优调查结果（第二部分）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。