分析Java EE應用程序 - 尋找什麼以及做出哪些更改？

我對分析應用程序以提高性能有點新。我選擇了YourKit作爲我的分析器。毫無疑問，YourKit提供了非常有趣的統計數據。我陷入困境的是如何處理這些統計數據。分析Java EE應用程序 - 尋找什麼以及做出哪些更改？

例如，考慮一種在JAXB POJO上運行的方法。該方法遍歷POJO來訪問深度嵌套在XML中的標籤/元素。這需要4層的for循環去的元件/標籤，如下所示：

List<Bundle> bundles = null; 
    List<Item> items = null; 
    for(Info info : data) { 
     bundles = info.getBundles(); 
     for(Bundle bundle : bundles) { 
     items = bundle.getItems(); 
     //.. more loops like this till we get to the required element 
     }   
    }

YourKit告訴我，上述代碼是「熱點」和80級的對象得到垃圾收集每次調用包含此代碼的方法。上面的代碼只是一個例子，並不是我陷入困境的唯一部分。大部分時間我都不知道如何處理探查器提供的信息。我可以做些什麼來減少上述代碼中臨時對象的數量？是否有任何明確的原則來反映應用程序的性能？分析應用程序時需要哪些統計信息以及每種統計信息會產生什麼影響？

編輯：分析應用程序的主要目標是提高吞吐量和響應時間。目前的吞吐量僅爲所需吞吐量的10％！

來源

2012-09-13 CKing

這取決於你的性能目標是什麼（響應時間？吞吐量？CPU使用？內存使用？） – meriton

我主要關心吞吐量和響應時間。我們有充足的內存和一個非常強大的處理器！ – CKing

重點關注與您的表現目標相關的統計數據。您對最小響應時間感興趣，因此請考慮每種方法對響應時間的貢獻程度，並着重於那些貢獻很大的方法（對於單線程處理，這只是在方法調用期間耗費的時間，對所有方法的調用進行總結）。我不確定YourKit將什麼定義爲熱點（查看文檔），但它可能是經過時間最長的累計方法，所以熱點是一件好事。相反，對象分配對響應時間沒有直接影響，並且與您的情況無關（除非您確定垃圾收集器貢獻了大部分cpu時間，但通常不會）。

來源

2012-09-13 11:18:10 meriton

改進循環的一種方法是更改模式並使模型變平，當然這取決於您是否可以更改模式。這樣生成的Java將不需要4層循環。當然，在一天結束的時候，你需要問自己的代碼是否真的是一個問題 - 80個對象正在變得如此糟糕？你的應用程序運行緩慢嗎？您是否遇到內存問題？請記住，過早優化是所有邪惡的根源！

分析和優化是一個複雜的野獸，取決於可能的事情（Java版本，32對64位操作系統等）。此外，優化可能並不總是需要更改代碼，例如，您可以通過在JVM上更改GC策略來解決問題 - 例如，在您的代碼創建許多需要GC的小對象的情況下，GC策略更有效經常。如果你有具體細節，可能會更容易幫助你，但是你的問題似乎過於寬泛。事實上，有很多關於主題的書可能值得一讀。

來源

2012-09-13 11:20:15 ramsinb

我完全同意給出的答案。

我想補充一點，考慮到您的具體示例，您實際上可以通過使用xpath api訪問XML中的特定位置來進行改進。

在你不需要真正迭代整個DOM的情況下，這應該是你的第一選擇，因爲它是聲明性的，因此更具表現力，更不容易出錯。（對於非常複雜的查詢，情況可能並非如此，但您似乎有一個簡單的場景）。

來源

2012-09-13 15:20:47 Vitaliy

我們不直接訪問XML。 JAXB將我們的Apache CXF Web服務收到的XML解組爲POJO。我們將POJO作爲我們Web服務端點的參數。簡而言之，xpath是否可以插入到JAXB中，以便生成的POJO包含使用XPATH的方法？ – CKing

另外請注意，遍歷整個DOM是必要的在許多情況下，應用程序所需的每個標記遍歷的屬性之前，從葉標記獲取信息 – CKing

我不知道一種技術，可以讓你插入xPath進入JAXB。事實上，這與技術的目的相矛盾。我很抱歉，但我忽略了您正在處理JAXB pojo並且無法直接訪問Xml的事實。但是，正如其他人所說，創建和收集80個對象對於JVM來說沒有任何意義。至於你的一般問題，可能是你看錯了地方。你是如何得出這樣的結論：這段代碼是花費最多時間的代碼？ – Vitaliy

分析Java EE應用程序 - 尋找什麼以及做出哪些更改？

回答

相關問題