有興趣了解如何使用AppDynamics捕獲這些Java性能指標嗎？ 立即開始免費試用 ！

前幾篇文章介紹了應用程序性能管理（APM），并指出了有效實施APM戰略的挑戰。 本文通過回顧五個頂級性能指標來構建這些主題，以評估您的企業Java應用程序的運行狀況。

本文專門回顧了以下內容：

• 商業交易
• 外部依賴
• 緩存策略
• 垃圾收集
• 應用拓撲

1.商業交易

商業交易提供了對真實用戶行為的洞察力：它們捕獲了真實用戶在與您的應用程序交互時所經歷的實時性能。 如前一篇文章中所述，衡量業務交易的性能涉及整體捕獲業務交易的響應時間以及測量其組成層的響應時間。 然后，可以將這些響應時間與最能滿足您的業務需求的基線進行比較以確定正常性。

如果您僅要評估應用程序的一個方面，則建議您評估業務交易的行為。 容器度量標準可以提供大量信息，并可以幫助您確定何時自動擴展環境，而業務交易則決定了應用程序的性能。 而不是詢問應用程序服務器中的線程池使用情況，您應該詢問用戶是否能夠完成其業務交易，以及這些業務交易是否正常進行。

作為一點背景，業務交易由它們的入口點來標識，這是與啟動業務交易的應用程序的交互。 可以通過諸如Web請求，Web服務調用或消息隊列中的消息之類的交互來定義業務交易入口點。 或者，您可以選擇基于URL參數為同一Web請求定義多個入口點，也可以根據其正文內容為服務調用定義多個入口點。 關鍵是，業務交易需要與對您的業務有意義的功能相關聯。

一旦確定了業務交易，便會在整個應用程序生態系統中衡量其性能。 對照其基準評估每個單獨業務交易的績效以評估正常性。 例如，我們可以確定業務交易的響應時間是否比行為異常的基線的平均響應時間慢兩個偏離標準響應時間的標準差。

圖1根據基準評估BT響應時間

用于評估業務交易的基準在業務交易運行的小時內是一致的，但是通過每次業務交易執行來完善業務交易。 例如，如果您選擇了一個基準，將基準時間與一天中某小時和一周中某天的平均響應時間進行比較，則在當前時間結束后，該小時中執行的所有業務將被合并到基準中下周。 通過這種機制，應用程序可以隨著時間的推移而發展，而無需丟棄和重建原始基準。 您可以將其視為隨時間推移的窗口。

總而言之，業務交易是對用戶體驗的最具反映性的度量，因此它們是要捕獲的最重要的指標。

2.外部依賴

外部依存關系可以有多種形式：依存的Web服務，遺留系統或數據庫； 外部依賴關系是您的應用程序與之交互的系統。 我們不必控制在外部依賴項中運行的代碼，但是我們經常可以控制那些外部依賴項的配置，因此了解何時以及何時運行得很好很重要。 此外，我們需要能夠區分應用程序中的問題和依賴關系中的問題。

從業務交易的角度來看，我們可以識別和衡量外部依存關系在它們自己的層中。 有時我們需要配置監視解決方案以識別真正包裝外部服務調用的方法，但是對于常見協議（例如HTTP和JDBC），可以自動檢測到外部依賴關系。 例如，當我在一家保險公司工作時，我們擁有一臺AS / 400，并且使用專有協議與之通信。

我們將方法調用確定為外部依賴項，并將其執行歸因于AS / 400。 但是我們也有可以為我們自動識別的Web服務調用。 與業務交易及其組成的應用程序層類似，應該將外部依賴行為作為基準，并根據這些基準評估響應時間。

業務事務為您提供了應用程序性能的最佳整體視圖，并且可以幫助您分類性能問題，但是外部依賴關系會以意想不到的方式對應用程序產生重大影響，除非您正在觀察它們。

3.緩存策略

從內存中服務對象總是比通過網絡調用從數據庫等系統中檢索對象要快。 高速緩存提供了一種在本地存儲對象實例的機制，以避免這種網絡往返。 但是，如果配置不正確，則緩存可能會帶來自身的性能挑戰。 常見的緩存問題包括：

• 將太多數據加載到緩存中
• 緩存大小不正確

我與一群不喜歡一般對象關系映射（ORM）工具，特別是不喜歡Level-2緩存的人一起工作。 共識是，ORM工具在決定將哪些數據加載到內存中時過于寬松，并且為了檢索單個對象，該工具需要將大量相關數據圖加載到內存中。 當正確配置工具時，他們對這些工具的擔心幾乎沒有根據，但是他們發現的問題是真實的。 簡而言之，當應用程序僅需要該數據的一小部分時，它們不喜歡將大量相互關聯的數據加載到內存中。

在測量高速緩存的性能時，需要確定加載到高速緩存中的對象數，然后跟蹤正在使用的那些對象的百分比。 要查看的關鍵指標是緩存命中率和從緩存中彈出的對象數。 高速緩存命中計數或命中率報告從高速緩存處理的對象請求的數量，而不需要進行網絡行程來檢索對象。

如果高速緩存很大，則命中率很小（低于10％或20％），并且您看不到從高速緩存中彈出許多對象，那么這表明您正在向高速緩存中加載過多數據。 換句話說，您的緩存足夠大，不會抖動（請參閱下文），并且包含許多未使用的數據。

測量緩存性能時要考慮的另一個方面是緩存大小。 如上例所示，緩存是否太大？ 緩存是否太小？ 還是緩存大小合適？

調整緩存大小時的一個常見問題是無法正確預期用戶的行為以及緩存的使用方式。 讓我們考慮配置為承載100個對象的緩存，但是該應用程序在任何給定時間需要300個對象。 前100個調用會將初始對象集加載到緩存中，但是后續調用將找不到他們要查找的對象。 結果，緩存將需要選擇要從緩存中刪除的對象，以便為新請求的對象騰出空間，例如使用最近最少使用（LRU）算法。

該請求將需要通過網絡執行查詢以檢索對象，然后將其存儲在緩存中。 結果是我們花費更多的時間來管理緩存而不是服務對象：在這種情況下，緩存實際上是在阻礙而不是提高性能。 由于Java的性質以及它如何管理垃圾回收，進一步加劇了問題，這種從緩存中不斷添加和刪除對象的方法實際上會增加垃圾回收的頻率（請參見下文）。

當您將高速緩存的大小設置得太小并且發生上述行為時，我們說高速緩存正在抖動，在這種情況下，沒有高速緩存比抖動的高速緩存更好。 圖2試圖以圖形方式顯示。

圖2緩存釋放

在這種情況下，應用程序從緩存中請求一個對象，但是找不到該對象。 然后，它通過網絡在外部資源中查詢對象，并將其添加到緩存中。 最后，緩存已滿，因此需要選擇一個要從緩存中彈出的對象，以便為新對象騰出空間，然后將新對象添加到緩存中。

有興趣了解如何使用AppDynamics捕獲這些Java性能指標嗎？ 立即開始免費試用 ！

4.垃圾收集

Java提供的核心功能（可追溯到其最初發行版）是垃圾收集，它既是福也是禍。 垃圾回收使我們擺脫了手動管理內存的責任：完成使用對象后，我們只需刪除對該對象的引用，垃圾回收將自動為我們釋放它。 如果您來自需要手動內存管理的語言（例如C或C ++），您將欣賞到這減輕了分配和釋放內存的麻煩。

此外，由于垃圾收集器在沒有對該內存的引用時自動釋放內存，因此它消除了在分配內存并在釋放內存之前刪除對該內存的引用時發生的傳統內存泄漏。 聽起來像萬能藥，不是嗎？

垃圾收集實現了消除手動內存管理并使我們擺脫傳統內存泄漏的目標，但這樣做的代價是有時會很麻煩。 有幾種基于您使用的JVM的垃圾收集策略，并且不涉及本文的討論范圍，但是足以說明您需要了解垃圾收集器的工作方式以及實現垃圾收集的最佳方法。配置它。

垃圾收集的最大敵人被稱為大型或完整垃圾收集。 除了Azul JVM之外，所有JVM都遭受主要垃圾回收的困擾。 垃圾收集有兩種一般形式：

• 次要
• 重大的

較小的垃圾收集相對頻繁地發生，目的是釋放短暫的對象。 它們不會在運行時凍結JVM線程，并且通常不會產生重大影響。

另一方面，主要的垃圾收集有時也稱為“世界停止”（STW）垃圾收集，因為它們在運行時會凍結JVM中的每個線程。 為了說明這種情況是如何發生的，我在本書《 Pro Java EE 5性能管理和優化》中提供了一些數據。

圖3可達性測試

運行垃圾回收時，它將執行稱為可達性測試的活動，如圖3所示。它構造對象的“根集”，其中包括每個運行線程直接可見的所有對象。 然后，它遍歷由根集中的對象引用的每個對象以及這些對象引用的對象，依此類推，直到所有對象都被引用為止。 在執行此操作時，它“標記”活動對象正在使用的內存位置，然后“清除”所有未使用的內存。 更恰當地說，它從根集中釋放了沒有對象引用路徑的所有內存。 最后，它壓縮或整理內存碎片，以便可以分配新對象。

次要集合和主要集合取決于您的JVM，但圖4和5顯示了次要集合和主要集合如何在Sun JVM上運行。

圖4次要收藏

在次要收集中，將在Eden空間中分配內存，直到Eden空間已滿。 它執行一個“復制”收集器，將活動對象（可達性測試）從伊甸園復制到兩個幸存者空間之一（到空間和從空間）。 然后可以將留在伊甸園中的物體掃走。 如果幸存者空間已滿，而我們仍然有活動對象，則這些活動對象將被移至保管空間，在那里只有大集合可以釋放它們。

圖5主要收藏

最終，保有權空間將被填滿，并且次要集合將運行，但是保管空間中將沒有任何空間可以復制不適合生存空間的活動對象。 發生這種情況時，JVM凍結JVM中的所有線程，執行可達性測試，清除年輕的一代（Eden和兩個幸存者空間），并壓縮保有權空間。 我們稱此為主要收藏。

如您所料，堆越大，大型集合運行的頻率就越小，但是當運行時，它們比較小的堆花費的時間長得多。 因此，調整堆大小和垃圾回收策略以滿足應用程序行為很重要。

5.應用拓撲

在前5個列表中要衡量的最終性能組件是您的應用程序拓撲。 由于云的出現，應用程序現在本質上可以具有彈性：您的應用程序環境可以增長和縮小以滿足用戶需求。 因此，對您的應用程序拓撲進行清單清點以確定確定環境的最佳大小非常重要。 如果您有太多的虛擬服務器實例，那么您的云托管成本將會增加，但是如果您沒有足夠的數量，那么您的業務交易將會受到影響。

在此評估過程中測量兩個指標很重要：

• 商業交易量
• 容器性能

應該將業務交易作為基準，并且您應該在任何給定的時間知道滿足基準所需的服務器數量。 如果您的業務事務負載意外增加，例如超過正常負載標準偏差的兩倍，則您可能需要添加其他服務器以滿足這些用戶的需求。

另一個要衡量的指標是容器的性能。 具體來說，您要確定是否有任何服務器層處于脅迫狀態，如果存在，則可能需要向該層添加其他服務器。 查看整個層中的服務器很重要，因為單個服務器可能由于垃圾收集等因素而處于脅迫狀態，但是如果層中很大比例的服務器處于脅迫狀態，則可能表明該層無法支持負載它正在接收。

由于您的應用程序組件可以單獨擴展，因此分析每個應用程序組件的性能并相應地調整拓撲非常重要。

結論

本文介紹了在評估應用程序的運行狀況時可能需要衡量的前五項指標。 總之，前五項是：

• 商業交易
• 外部依賴
• 緩存策略
• 垃圾收集
• 應用拓撲

在下一篇文章中，我們將把本系列的所有主題放在一起，以介紹AppDynamics實施其APM戰略所采用的方法。 這不是一篇營銷文章，而是對為何做出某些決策和優化以及它們如何為您提供虛擬或基于云應用程序運行狀況的強大視圖的解釋。

有興趣了解如何使用AppDynamics捕獲這些Java性能指標嗎？ 立即開始免費試用 ！

翻譯自: https://www.javacodegeeks.com/2015/05/top-5-java-performance-metrics-to-capture-in-enterprise-applications.html

總結

以上是生活随笔為你收集整理的企业应用程序中需要捕获的5大Java性能指标的全部內容，希望文章能夠幫你解決所遇到的問題。

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