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

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

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

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

1.商業(yè)交易

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

如果您僅要評(píng)估應(yīng)用程序的一個(gè)方面，則建議您評(píng)估業(yè)務(wù)交易的行為。 容器度量標(biāo)準(zhǔn)可以提供大量信息，并可以幫助您確定何時(shí)自動(dòng)擴(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)識(shí)，這是與啟動(dòng)業(yè)務(wù)交易的應(yīng)用程序的交互。 可以通過諸如Web請(qǐng)求，Web服務(wù)調(diào)用或消息隊(duì)列中的消息之類的交互來定義業(yè)務(wù)交易入口點(diǎn)。 或者，您可以選擇基于URL參數(shù)為同一Web請(qǐng)求定義多個(gè)入口點(diǎn)，也可以根據(jù)其正文內(nèi)容為服務(wù)調(diào)用定義多個(gè)入口點(diǎn)。 關(guān)鍵是，業(yè)務(wù)交易需要與對(duì)您的業(yè)務(wù)有意義的功能相關(guān)聯(lián)。

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

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

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

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

2.外部依賴

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

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

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

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

3.緩存策略

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

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

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

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

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

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

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

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

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

圖2緩存釋放

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

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

4.垃圾收集

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

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

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

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

• 次要
• 重大的

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

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

圖3可達(dá)性測試

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

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

圖4次要收藏

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

圖5主要收藏

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

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

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

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

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

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

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

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

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

結(jié)論

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

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

在下一篇文章中，我們將把本系列的所有主題放在一起，以介紹AppDynamics實(shí)施其APM戰(zhàn)略所采用的方法。 這不是一篇營銷文章，而是對(duì)為何做出某些決策和優(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)容還不錯(cuò)，歡迎將生活随笔推薦給好友。