java 性能調(diào)優(yōu)

這是本系列中的最后一篇文章，我們將分析我們?cè)?014年10月進(jìn)行的Java Performance Tuning Survey的結(jié)果。如果您尚未閱讀第一篇文章，建議您首先閱讀以下內(nèi)容：

• 性能問題的頻率和嚴(yán)重性
• 最受歡迎的監(jiān)控解決方案
• 查找根本原因的工具和技術(shù)

這篇文章打開了一些有趣的相關(guān)數(shù)據(jù)并總結(jié)了結(jié)果。

復(fù)制是快速成功的關(guān)鍵

當(dāng)您負(fù)責(zé)解決性能問題時(shí)，您需要證據(jù)來(lái)找到根本原因。 為了獲得證據(jù)，您通常需要重現(xiàn)問題。 在調(diào)查中，我們?cè)儐柫耸茉L者是否能夠重現(xiàn)該問題 ：

• 9％不需要復(fù)制，已經(jīng)有足夠的證據(jù)
• 27％無(wú)法重現(xiàn)該問題
• 64％設(shè)法重現(xiàn)該問題

在另一個(gè)問題中，我們問“ 找到并解決您遇到的問題需要花費(fèi)多長(zhǎng)時(shí)間”。 平均而言，這花費(fèi)了80個(gè)小時(shí) 。 我們分析了是否有27％無(wú)法重現(xiàn)該問題的人是否還在苦苦掙扎。 結(jié)果很明顯：

• 如果受訪者能夠重現(xiàn)問題，則平均需要65個(gè)小時(shí)
• 如果響應(yīng)者無(wú)法重現(xiàn)該問題，則 需要花費(fèi) 113個(gè)小時(shí)或74％的時(shí)間才能找到根本原因并加以解決。

區(qū)別清晰可見。 造成這種差異的原因隱藏在故障排除過(guò)程中。 要解決問題，您需要證據(jù)，通常是從各種來(lái)源收集的證據(jù)，例如日志文件，線程轉(zhuǎn)儲(chǔ)或堆轉(zhuǎn)儲(chǔ)。 但是，只有在能夠重現(xiàn)案件的情況下（最好是隨心所欲），您才能獲得證據(jù)。 如果您無(wú)法重現(xiàn)問題，那么您將沒有證據(jù)，而武庫(kù)中唯一的工具往往是良好的舊嘗試和錯(cuò)誤。 面對(duì)超過(guò)100,000行代碼，您注定會(huì)在此過(guò)程中面臨許多失敗的嘗試。

有些問題比其他問題難。

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

讓我們?cè)俅位仡櫼幌?#xff0c;發(fā)現(xiàn)和解決問題的平均時(shí)間為80個(gè)小時(shí)。 在按問題類型進(jìn)行分類時(shí)，我們發(fā)現(xiàn)了以下內(nèi)容：

• 查找和修復(fù)最簡(jiǎn)單的問題與網(wǎng)絡(luò)IO有關(guān)：平均花費(fèi)51個(gè)小時(shí)。
• 內(nèi)存泄漏按所花費(fèi)的時(shí)間準(zhǔn)確地排在平均水平：平均發(fā)現(xiàn)并修復(fù)一個(gè)泄漏所花費(fèi)的時(shí)間為80小時(shí)24分鐘。
• 另一方面是架構(gòu)問題–根本原因與整體架構(gòu)和HTTP會(huì)話膨脹有關(guān)，分別花費(fèi)了98 和105個(gè)小時(shí)。 查找和解決原因的時(shí)間增加了大約100％ 。

從極端來(lái)看，這實(shí)際上并不奇怪。 當(dāng)您的體系結(jié)構(gòu)引起性能問題時(shí)，修復(fù)程序本身往往很復(fù)雜且耗時(shí)，因此需要更多的時(shí)間來(lái)修復(fù)。 而且當(dāng)您傾向于濫用網(wǎng)絡(luò)時(shí)，它通常可以歸結(jié)為一個(gè)惡意呼叫，您可以輕松地對(duì)其進(jìn)行隔離和修復(fù)。

隨機(jī)工具幫助

接下來(lái)，我們分析了用于解決某些潛在根本原因的工具和技術(shù)。 我們注意到，平均而言，用戶不會(huì)嘗試使用不少于四種不同的工具來(lái)收集證據(jù)并找到根本原因 。 最流行的工具和技術(shù)涉及日志分析，堆/線程轉(zhuǎn)儲(chǔ)和分析器。

當(dāng)我們研究工具在各種潛在問題中的使用時(shí)，我們感到非常驚訝。 根本的問題和用于進(jìn)行故障排除的工具之間幾乎沒有關(guān)聯(lián)-列出了相同的工具，而頻率與出現(xiàn)的問題無(wú)關(guān)。

最好的例子可能是線程轉(zhuǎn)儲(chǔ)分析。 這是收集有關(guān)并發(fā)問題的證據(jù)的好方法。 實(shí)際上，解決并發(fā)問題的受訪者中有52％使用線程轉(zhuǎn)儲(chǔ)分析作為根本原因分析來(lái)源之一。 但是例如，當(dāng)眼前的問題是內(nèi)存泄漏時(shí)，則有42％的情況列出了相同的線程轉(zhuǎn)儲(chǔ)分析。

或者，從工具的角度看–與問題類型無(wú)關(guān)，有41-53％的受訪者使用探查器收集證據(jù)，而與癥狀和潛在問題無(wú)關(guān)。

從這些數(shù)據(jù)得出結(jié)論是很棘手的，但是看來(lái)證據(jù)收集和分析過(guò)程是非常非正式的，涉及使用該特定人員以前使用或聽說(shuō)過(guò)的工具和技術(shù)。

結(jié)論

進(jìn)行這項(xiàng)調(diào)查是為了指導(dǎo)Plumbr的進(jìn)一步發(fā)展。 對(duì)我們而言，主要結(jié)論基于調(diào)查的四個(gè)關(guān)鍵結(jié)果：

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

我們承諾從這里開始，并為上述問題提供解決方案。 使用Plumbr監(jiān)視系統(tǒng)，可以立即將您準(zhǔn)確定位到根本的根本原因，從而完全跳過(guò)“嘗試復(fù)制-收集證據(jù)-解釋證據(jù)”的周期：

我們當(dāng)前的產(chǎn)品允許線程鎖定，低效率的GC和內(nèi)存泄漏，但是我們一直在擴(kuò)展我們的產(chǎn)品，因此您將擁有一個(gè)安全網(wǎng)來(lái)應(yīng)對(duì)影響JVM的所有性能問題。

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

java 性能調(diào)優(yōu)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。