這是系列文章中的最后一篇，我們將分析我們在2014年10月進行的Java Performance Tuning Survey的結果。如果您還沒有閱讀第一篇文章，我建議您首先閱讀以下內容：

• 性能問題的頻率和嚴重性
• 最受歡迎的監控解決方案
• 查找根本原因的工具和技術

這篇文章打開了一些有趣的相關數據，并總結了結果。

復制是快速成功的關鍵

當您負責解決性能問題時，您需要證據來找到根本原因。 為了獲得證據，您通常需要重現問題。 在調查中，我們詢問了受訪者是否能夠重現該問題 ：

• 9％不需要復制，已經有足夠的證據
• 27％無法重現該問題
• 64％設法重現了問題

在另一個問題中，我們問“ 找到并解決您面臨的問題需要多長時間”。 平均而言，這花費了80個小時 。 我們分析了是否有27％無法重現該問題的人是否還在苦苦掙扎。 結果很明顯：

• 如果受訪者能夠重現問題，則平均需要65個小時
• 如果響應者無法重現該問題，則 需要花費 113個小時或74％的時間才能找到根本原因并加以解決。

區別清晰可見。 造成這種差異的原因隱藏在故障排除過程中。 要解決問題，您需要證據，通常是從各種來源收集的證據，例如日志文件，線程轉儲或堆轉儲。 但是，只有能夠重現此案（最好隨意），您才能獲得證據。 如果您無法重現問題，那么您將沒有證據，而且武庫中唯一的工具往往是良好的舊嘗試和錯誤。 面對超過100,000行代碼，您注定會在此過程中面臨許多失敗的嘗試。

有些問題比其他問題要難。

受訪者還向我們提供了他們正在解決的性能問題的根本原因。 我們研究了不同的問題，以了解某些問題是否比其他問題更難解決

讓我們再次回顧一下，發現和解決問題的平均時間為80個小時。 按問題類型分類時，我們發現了以下內容：

• 查找和修復最簡單的問題與網絡IO有關：平均花費51個小時。
• 內存泄漏按花費的時間準確地排在平均水平：平均發現并修復一個泄漏要花費80個小時24分鐘。
• 另一方面是架構問題–根本原因與整體架構和HTTP會話膨脹有關，分別花費了98 和105個小時。 查找和解決原因的時間增加了大約100％ 。

從極端來看，這實際上并不奇怪。 當您的體系結構引起性能問題時，修復程序本身往往很復雜且耗時，因此需要更多的時間來修復。 而且當您傾向于濫用網絡時，它通常可以歸結為一個惡意呼叫，您可以輕松地對其進行隔離和修復。

隨機工具幫助

接下來，我們分析了用于解決某些潛在根本原因的工具和技術。 我們注意到，平均而言，用戶不會嘗試更多，至少四個不同的工具來收集證據并找到根本原因 。 最流行的工具和技術涉及日志分析，堆/線程轉儲和分析器。

當我們研究工具在各種潛在問題中的使用時，我們真的感到非常驚訝。 根本的問題和用于進行故障排除的工具之間幾乎沒有關聯-列出了相同的工具，而頻率與出現的問題無關。

最好的例子可能是線程轉儲分析。 這是收集有關并發問題的證據的好方法。 確實，解決并發問題的受訪者中有52％使用線程轉儲分析作為根本原因分析來源之一。 但是例如，當眼前的問題是內存泄漏時，則有42％的情況列出了相同的線程轉儲分析。

或者，從工具的角度來看–與問題類型無關，有41-53％的受訪者使用探查器來收集證據，與癥狀和根本問題無關。

從這些數據得出結論是很棘手的，但是看來證據收集和分析過程是非常非正式的，并且涉及使用該特定人員以前使用或聽說過的工具和技術。

結論

進行這項調查是為了指導Plumbr的進一步發展。 對我們而言，主要結論基于調查的四個關鍵結果：

• 查找和解決性能問題的平均時間為80小時
• 對于76％的案例，大部分時間都花在了惡性的“試圖復制-收集證據-解釋證據”周期中。
• 27％的情況無法復制。 在這種情況下，查找和解決問題所花費的時間增加了73％。
• 證據收集過程是完全非正式的，平均涉及四個隨機選擇的工具

我們承諾從這里開始，并為上述問題提供解決方案。 使用Plumbr監視系統可立即將您定位到實際的根本原因，從而完全跳過“嘗試重現–收集證據–解釋證據”的周期：

我們當前的產品允許線程鎖定，低效率的GC和內存泄漏，但是我們一直在擴展我們的產品，因此您將擁有一個安全網來應對影響JVM的所有性能問題。

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

總結

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

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