有興趣了解如何使用AppDynamics捕獲這些Java性能指標(biāo)嗎？ 立即開始免費(fèi)試用 ！

前幾篇文章介紹了應(yīng)用程序性能管理（APM），并指出了有效實施APM戰(zhàn)略的挑戰(zhàn)。 本文通過回顧五個頂級性能指標(biāo)來構(gòu)建這些主題，以評估您的企業(yè)Java應(yīng)用程序的運(yùn)行狀況。

本文專門回顧了以下內(nèi)容：

• 商業(yè)交易
• 外部依賴
• 緩存策略
• 垃圾收集
• 應(yīng)用拓?fù)?

1.商業(yè)交易

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

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

作為一點(diǎn)背景，業(yè)務(wù)交易由它們的入口點(diǎn)來標(biāo)識，這是與啟動業(yè)務(wù)交易的應(yīng)用程序的交互。 可以通過諸如Web請求，Web服務(wù)調(diào)用或消息隊列中的消息之類的交互來定義業(yè)務(wù)交易入口點(diǎn)。 或者，您可以選擇基于URL參數(shù)為同一Web請求定義多個入口點(diǎn)，也可以根據(jù)其正文內(nèi)容為服務(wù)調(diào)用定義多個入口點(diǎn)。 關(guān)鍵是，業(yè)務(wù)交易需要與對您的業(yè)務(wù)有意義的功能相關(guān)聯(lián)。

一旦確定了業(yè)務(wù)交易，便會在整個應(yīng)用程序生態(tài)系統(tǒng)中衡量其性能。 對照其基準(zhǔn)評估每個單獨(dú)業(yè)務(wù)交易的績效以評估正常性。 例如，我們可以確定業(yè)務(wù)交易的響應(yīng)時間是否比行為異常的基線的平均響應(yīng)時間慢兩個偏離標(biāo)準(zhǔn)響應(yīng)時間的標(biāo)準(zhǔn)差。

圖1根據(jù)基準(zhǔn)評估BT響應(yīng)時間

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

總而言之，業(yè)務(wù)交易是對用戶體驗的最具反映性的度量，因此它們是要捕獲的最重要的指標(biāo)。

2.外部依賴

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

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

我們將方法調(diào)用確定為外部依賴項，并將其執(zhí)行歸因于AS / 400。 但是我們也有可以為我們自動識別的Web服務(wù)調(diào)用。 與業(yè)務(wù)交易及其組成的應(yīng)用程序?qū)宇愃?#xff0c;應(yīng)該將外部依賴行為作為基準(zhǔn)，并根據(jù)這些基準(zhǔn)評估響應(yīng)時間。

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

3.緩存策略

從內(nèi)存中服務(wù)對象總是比通過網(wǎng)絡(luò)調(diào)用從數(shù)據(jù)庫等系統(tǒng)中檢索對象要快。 高速緩存提供了一種在本地存儲對象實例的機(jī)制，以避免這種網(wǎng)絡(luò)往返。 但是，如果配置不正確，則緩存可能會帶來自身的性能挑戰(zhàn)。 常見的緩存問題包括：

• 將太多數(shù)據(jù)加載到緩存中
• 緩存大小不正確

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

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

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

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

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

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

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

圖2緩存釋放

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

有興趣了解如何使用AppDynamics捕獲這些Java性能指標(biāo)嗎？ 立即開始免費(fèi)試用 ！

4.垃圾收集

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

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

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

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

• 次要
• 重大的

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

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

圖3可達(dá)性測試

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

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

圖4次要收藏

在次要收集中，將在Eden空間中分配內(nèi)存，直到Eden空間已滿。 它執(zhí)行一個“復(fù)制”收集器，將活動對象（可達(dá)性測試）從伊甸園復(fù)制到兩個幸存者空間之一（到空間和從空間）。 然后可以將留在伊甸園中的物體掃走。 如果幸存者空間已滿，而我們?nèi)匀挥谢顒訉ο?#xff0c;則這些活動對象將被移至保管空間，在那里只有大集合可以釋放它們。

圖5主要收藏

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

如您所料，堆越大，大型集合運(yùn)行的頻率就越小，但是當(dāng)運(yùn)行時，它們比較小的堆花費(fèi)的時間長得多。 因此，調(diào)整堆大小和垃圾回收策略以滿足應(yīng)用程序行為很重要。

5.應(yīng)用拓?fù)?/h2>

在前5個列表中要衡量的最終性能組件是您的應(yīng)用程序拓?fù)洹?由于云的出現(xiàn)，應(yīng)用程序現(xiàn)在本質(zhì)上可以具有彈性：您的應(yīng)用程序環(huán)境可以增長和縮小以滿足用戶需求。 因此，對您的應(yīng)用程序拓?fù)溥M(jìn)行清單清點(diǎn)以確定確定環(huán)境的最佳大小非常重要。 如果您有太多的虛擬服務(wù)器實例，那么您的云托管成本將會增加，但是如果您沒有足夠的數(shù)量，那么您的業(yè)務(wù)交易將會受到影響。

在此評估過程中測量兩個指標(biāo)很重要：

• 商業(yè)交易量
• 容器性能

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

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

由于您的應(yīng)用程序組件可以單獨(dú)擴(kuò)展，因此分析每個應(yīng)用程序組件的性能并相應(yīng)地調(diào)整拓?fù)浞浅Ｖ匾?

結(jié)論

本文介紹了在評估應(yīng)用程序的運(yùn)行狀況時可能需要衡量的前五項指標(biāo)。 總之，前五項是：

• 商業(yè)交易
• 外部依賴
• 緩存策略
• 垃圾收集
• 應(yīng)用拓?fù)?

在下一篇文章中，我們將把本系列的所有主題放在一起，以介紹AppDynamics實施其APM戰(zhàn)略所采用的方法。 這不是一篇營銷文章，而是對為何做出某些決策和優(yōu)化以及它們?nèi)绾螢槟峁┨摂M或基于云應(yīng)用程序運(yùn)行狀況的強(qiáng)大視圖的解釋。

有興趣了解如何使用AppDynamics捕獲這些Java性能指標(biāo)嗎？ 立即開始免費(fèi)試用 ！

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

總結(jié)

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

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