建站
咨詢
售后
建站咨詢
新聞中心
本系列文章涵蓋許多基礎(chǔ)性內(nèi)容：它給出了應(yīng)用程序性能管理（APM）的總體概述；指明了實(shí)現(xiàn)一個(gè) APM 策略的主要挑戰(zhàn)；提出了衡量，評(píng)估一個(gè)企業(yè)級(jí) Node.js 應(yīng)用程序運(yùn)行狀況的最重要的 5 條指標(biāo)；并提出了通過(guò) AppDynamics 方式構(gòu)建一個(gè) APM 解決方案。在文章的***部分，還提出了一些提示和技巧類以幫助您實(shí)現(xiàn)***的 APM 策略。具體地說(shuō)，本文討論了以下主題：
成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),綠春企業(yè)網(wǎng)站建設(shè),綠春品牌網(wǎng)站建設(shè),網(wǎng)站定制,綠春網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,綠春網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
業(yè)務(wù)交易優(yōu)化
快照調(diào)優(yōu)
閾值調(diào)優(yōu)
層級(jí)管理
上下文信息捕獲
1.業(yè)務(wù)交易優(yōu)化
本文章系列里，我會(huì)不斷重復(fù)強(qiáng)調(diào)的就是監(jiān)控方案里的業(yè)務(wù)交易優(yōu)化一環(huán)。要最有效地利用業(yè)務(wù)交易監(jiān)控，您需要做到以下幾項(xiàng)：
恰當(dāng)?shù)孛麡I(yè)務(wù)交易以配合您的業(yè)務(wù)功能
正確識(shí)別您的業(yè)務(wù)交易
通過(guò)排除您并不關(guān)心的業(yè)務(wù)交易來(lái)降低噪音
AppDynamics 可以為您自動(dòng)識(shí)別業(yè)務(wù)交易，并且盡可能給出***的命名。不過(guò)這樣取決于您的應(yīng)用是如何編寫(xiě)的，應(yīng)用名可能可以如實(shí)反映業(yè)務(wù)交易，也可能不可以。例如，您可 能有一個(gè)業(yè)務(wù)交易叫做“POST/payment”，對(duì)應(yīng)著檢驗(yàn)流程。那么如果將其命名為“Checkout”的話，就更能如實(shí)反映業(yè)務(wù)功能，這將更利于 操作人員操作，也便與生成報(bào)表與執(zhí)行人員查看。
下面，如果您有多個(gè)業(yè)務(wù)交易，卻只有一個(gè)入口的話，你需要花一些時(shí)間將其分割為獨(dú)立的業(yè)務(wù)單元。以下幾個(gè)可能發(fā)生的例子，包含如下特點(diǎn)：
多個(gè) URL 都路由到相同的 MVC 控制器和動(dòng)作
根據(jù)有效負(fù)載的制定業(yè)務(wù)交易功能
根據(jù) GET 參數(shù)制定業(yè)務(wù)交易功能
復(fù)雜的 URL 路徑
如果一個(gè)入口卻對(duì)應(yīng)著多個(gè)業(yè)務(wù)功能，那么就需要根據(jù)不同的指標(biāo)配置業(yè)務(wù)交易。例如，如果 body 里有一個(gè)”operation“元素對(duì)應(yīng)著”operation“操作的話，那么就需要根據(jù)”operaiton“對(duì)交易進(jìn)行分割。又如果有一 個(gè)”execute“動(dòng)作接受一個(gè)”command“URL 參數(shù)，那么就需要根據(jù)”command“字段對(duì)交易進(jìn)行分割。***，URL 模式可能會(huì)因應(yīng)用不同而不同，所以您需要與您的應(yīng)用最匹配的形式。例如，AppDynamics 會(huì)根據(jù)兩段式自動(dòng)為您的 URL 定義業(yè)務(wù)交易，例如 one/two。大多數(shù) Node.js MVC 框架都會(huì)自動(dòng)路由到對(duì)應(yīng)的應(yīng)用控制器和動(dòng)作。如果您的應(yīng)用使用的是一段式，或者四段式，那么您需要根據(jù)命名規(guī)則來(lái)定義業(yè)務(wù)交易。
命名和識(shí)別業(yè)務(wù)交易單元可以確保您捕捉到了正確的業(yè)務(wù)功能，但是盡可能多的減噪也同樣重要。您是否有些并不關(guān)心的業(yè)務(wù)交易呢？比如，會(huì)不會(huì)有一個(gè)網(wǎng) 頁(yè)游戲會(huì)每隔幾秒就檢查對(duì)高分呢？又或者如果有一個(gè)每晚都執(zhí)行的 Node.js 的 CLI 作業(yè)，每次都執(zhí)行很長(zhǎng)時(shí)間，但是由于脫機(jī)運(yùn)行，它并不影響終端用戶，您不關(guān)心么？ 如果是的話，排除這些交易，以便減少分析噪音。
2. 快照調(diào)優(yōu)
正如在前面文章提到的，AppDynamics 每隔一段時(shí)間就會(huì)智能捕獲性能快照，并可以逐漸縮小每次性能會(huì)話里快照的個(gè)數(shù)。由于這兩個(gè)值都是可以調(diào)整的，所以有利于調(diào)優(yōu)。
AppDynamics 直接捕獲整個(gè)進(jìn)程的調(diào)用關(guān)系圖，同時(shí)去掉配置閾值以下的記錄。如果你只對(duì)“大的”性能問(wèn)題感興趣，那么你可能不需要精確到 10 毫秒以下。如果你把間隔時(shí)間增加到 50 毫秒，你會(huì)丟失粒度。如果你想微調(diào)應(yīng)用程序，你可能需要 10 毫秒的粒度，但是如果你不打算讓方法在 50 毫秒內(nèi)執(zhí)行完畢，為什么需要那種級(jí)別的粒度呢？問(wèn)題在于你應(yīng)該分析需求然后做相應(yīng)的調(diào)整。
接下來(lái)，觀察你的產(chǎn)品故障排除模式，然后判斷 AppDynamics 捕獲的進(jìn)程快照數(shù)在你當(dāng)前狀況下是否合適。如果你發(fā)現(xiàn)每分鐘捕獲 2 個(gè)快照太多了，那么你可以配置 AppDynamics 來(lái)調(diào)整快照間隔。嘗試配置 AppDynamics 讓其每分鐘最多捕獲一個(gè)快照。另外如果你只對(duì)系統(tǒng)性問(wèn)題感興趣，你可以把***快照數(shù)降低至 5 個(gè)。這會(huì)顯著地減少持續(xù)的消耗，但代價(jià)是可能會(huì)導(dǎo)致捕捉不到有代表性的快照。
3. 閾值調(diào)優(yōu)
AppDynamics 設(shè)計(jì)了一套通用的監(jiān)控解決方案，并且對(duì)于比正常情況慢兩個(gè)標(biāo)準(zhǔn)差的業(yè)務(wù)事務(wù)提供警告。這在大多數(shù)情況下是有效的，但是你需要知道你的應(yīng)用程序響應(yīng)時(shí)間有多不穩(wěn)定，以便確定這對(duì)你的業(yè)務(wù)需求來(lái)說(shuō)是否為***配置。
根據(jù)業(yè)務(wù)事務(wù)對(duì)比基準(zhǔn)線的估算值，AppDynamics 定義了三種閾值：
標(biāo)準(zhǔn)差: 比較業(yè)務(wù)事務(wù)的響應(yīng)時(shí)間與基準(zhǔn)線的幾個(gè)標(biāo)準(zhǔn)差
百分比: 比較業(yè)務(wù)事務(wù)的響應(yīng)時(shí)間與基準(zhǔn)線的差值百分比
靜態(tài) SLA: 比較業(yè)務(wù)事務(wù)的響應(yīng)時(shí)間和靜態(tài)值，比如2秒
如果您的應(yīng)用程序的響應(yīng)時(shí)間不穩(wěn)定,那么默認(rèn)的兩個(gè)標(biāo)準(zhǔn)差臨界值可能導(dǎo)致太多的錯(cuò)誤警報(bào)。在這種情況下，您可能希望增加更多的標(biāo)準(zhǔn)差或換一種方式來(lái) 處理。如果您的應(yīng)用程序的響應(yīng)時(shí)間比較穩(wěn)定，你就會(huì)想減少你的臨界值提前發(fā)出警告。此外，如果你有提供給特殊協(xié)定用戶的服務(wù)或 API（應(yīng)用程序接口），你應(yīng)該為此業(yè)務(wù)設(shè)置一個(gè)穩(wěn)定的協(xié)定值。AppDynamics（應(yīng)用性能管理）會(huì)提供給你個(gè)人或企業(yè)業(yè)務(wù)定義警報(bào)規(guī)則的靈活性。
你需要分析你的應(yīng)用程序的行為，并相應(yīng)地配置報(bào)警引擎。
4. 分層調(diào)優(yōu)
在前面我已經(jīng)提到過(guò)，AppDynamics 不僅能夠捕獲業(yè)務(wù)事務(wù)性能的基準(zhǔn)，同時(shí)它也能捕獲一個(gè)業(yè)務(wù)事務(wù)在不同服務(wù)層上的性能基準(zhǔn)。打個(gè)比方，如果你的業(yè)務(wù)事務(wù)調(diào)用了一個(gè)規(guī)則引擎提供的服務(wù)，那么 AppDynamics將正確捕獲你的業(yè)務(wù)事務(wù)對(duì)規(guī)則引擎部分的調(diào)用數(shù)以及規(guī)則引擎的平均響應(yīng)時(shí)間，并且將會(huì)把這些數(shù)據(jù)正確反映到業(yè)務(wù)事務(wù)的性能基準(zhǔn)中。 正是因?yàn)?AppDynamics 的這個(gè)特性，因此在你的整個(gè)系統(tǒng)中***能夠清晰定義所有的服務(wù)層，這樣你可以得到一個(gè)非常清晰而且優(yōu)秀的業(yè)務(wù)事務(wù)性能基準(zhǔn)。
如果你沒(méi)有明確指定系統(tǒng)的服務(wù)層次，那么AppDynamics將根據(jù)一定的規(guī)則（不同的協(xié)議棧）自動(dòng)分析你的應(yīng)用的服務(wù)層次。比如，它將自動(dòng)把你 的應(yīng)用分解成 HTTP 服務(wù)層，JMS 服務(wù)層，JDBC 服務(wù)層。舉一個(gè)具體的例子，如果 AppDynamics 發(fā)現(xiàn)你的代碼中有一個(gè)對(duì) Database 的操作，那么它就會(huì)假設(shè)你的整個(gè)業(yè)務(wù)邏輯中存在一個(gè)數(shù)據(jù)庫(kù)訪問(wèn)層，因此它就會(huì)自動(dòng)計(jì)算你的業(yè)務(wù)邏輯用在數(shù)據(jù)庫(kù)訪問(wèn)上的時(shí)間。這個(gè)對(duì)于調(diào)優(yōu)你的業(yè)務(wù)邏輯是非 常重要的，因?yàn)槟悴幌Ｍ谛阅芑鶞?zhǔn)中只是看到一個(gè)信息說(shuō)你的 ORM class 中的 save 方法執(zhí)行的非常慢，相反的你希望能夠看到更具體的信息，比如說(shuō) save 方法花了多少時(shí)間把數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，又花了多少時(shí)間執(zhí)行其他的任務(wù)。
如果在你的系統(tǒng)中，所有的 service 調(diào)用都使用的是通用協(xié)議棧（比如 HTTP 協(xié)議）， 那么 AppDynamics 將非常***的分析出你的系統(tǒng)的服務(wù)層次，但是如果你的系統(tǒng)使用了一個(gè)非通用協(xié)議棧和后端系統(tǒng)進(jìn)行通信，AppDynamics 就無(wú)能為力了。舉例來(lái)說(shuō)，目前我在一個(gè)保險(xiǎn)公司工作，這個(gè)保險(xiǎn)公司使用一個(gè) AS/400 機(jī)器提供詢價(jià)服務(wù)。在我們的系統(tǒng)中，我們使用了一個(gè)私有庫(kù)來(lái)和 AS/400 通訊，這個(gè)庫(kù)使用了一個(gè)私有的基于 socket 的通訊協(xié)議鏈接到 AS/400 上。在這種情況下，很明顯 AppDynamics 不可能知道系統(tǒng)使用了基于 socket 的通訊協(xié)議，也不可能知道這 個(gè)socket 通訊協(xié)議是如何工作的。因此，我們需要告訴 AppDynamics 是哪個(gè)方法實(shí)現(xiàn)了和 AS/400 之間的通訊，并且標(biāo)記這個(gè)方法為定制化的后端資源。這樣一來(lái)，AppDynamics 就會(huì)將這個(gè)方法識(shí)別成一個(gè)新的服務(wù)層次，接下來(lái) AppDynamics 就可以對(duì)這個(gè)新的服務(wù)層次進(jìn)行調(diào)用計(jì)數(shù)，并計(jì)算它的平均響應(yīng)時(shí)間了。
在大部分情況下，你可以使用 AppDynamics 的內(nèi)置功能來(lái)分析系統(tǒng)的服務(wù)層次，但是如果你有特定的要求，AppDynamics 也提供了 Node.js API，讓你自己定義系統(tǒng)的服務(wù)層次。
5. 獲取上下文信息
但性能問(wèn)題發(fā)生的時(shí)候，有時(shí)候問(wèn)題只發(fā)生在某個(gè)瀏覽器或者移動(dòng)設(shè)備上，有時(shí)候只發(fā)生在客戶端發(fā)送了特定的請(qǐng)求內(nèi)容。在這種情況下，由于問(wèn)題并不總是能夠重現(xiàn)，那么我們?cè)趺磥?lái)定位這些問(wèn)題呢？
答案就是在創(chuàng)建快照的時(shí)候，同時(shí)獲得上下文信息。你可以通過(guò)查看上下文信息，看來(lái)發(fā)現(xiàn)一些共性。需要捕獲上下文信息可能有以下這些：
HTTP 請(qǐng)求頭信息，比如瀏覽器類型（user-agent ），cookies 和 referrer
HTTP GET 請(qǐng)求發(fā)送的參數(shù)
被調(diào)用方法的參數(shù)
應(yīng)用中定義的變量以及變量的值
我們下面就舉一些例子來(lái)說(shuō)明對(duì)于一個(gè)性能不好的 Node.js 事務(wù)，你將如何應(yīng)用上面說(shuō)的這些上下文信息來(lái)查找和發(fā)現(xiàn)問(wèn)題。比如，如果你捕獲了 User-Agent HTTP 請(qǐng)求頭信息，那么你就可以知道用戶是在哪個(gè)瀏覽器上執(zhí)行商業(yè)事務(wù)。如果你提供的 HTTP 服務(wù)支持 GET 方法，那么你可能想通過(guò)檢查Query String 里面某個(gè)或者多個(gè)變量的值來(lái)知道用戶想查詢什么內(nèi)容。再進(jìn)一步，如果你知道應(yīng)用的代碼是如何工作，你可能就想知道一個(gè)具體參數(shù)的值。
你可以通過(guò)配置讓 AppDynamics 獲取上下文信息并且加入到快照中，可以被捕獲的上下文信息在上一節(jié)中已經(jīng)詳細(xì)介紹了。下面我們簡(jiǎn)單的介紹一下 AppDynamics 獲取上下文信息的過(guò)程：
AppDynamics 發(fā)現(xiàn)了一個(gè)運(yùn)行緩慢的業(yè)務(wù)事務(wù)
于是 AppDynamics 開(kāi)始創(chuàng)建一個(gè)快照
在創(chuàng)建快照的過(guò)程中，AppDynamics 根據(jù)你配置的信息，獲取相應(yīng)的上下文信息并放入快照中
結(jié)果就是當(dāng)你找到一個(gè)可以反映你試圖解決的問(wèn)題的快照的時(shí)候，你可以在 AppDynamics 為你捕獲的上下文信息中查看是否有有用的信息。
當(dāng)你使用上下文信息捕獲功能的時(shí)候，因?yàn)?AppDynamics 使用侵入式代碼來(lái)獲取方法的參數(shù)值，這將造成原始代碼運(yùn)行效率有一些下降。因此，只在確實(shí)需要的地方使用這個(gè)功能。
結(jié)束語(yǔ)
應(yīng)用性能管理的難處在于它需要在獲取盡量少的數(shù)據(jù)的情況下，能夠讓開(kāi)發(fā)人員分析出導(dǎo)致性能瓶頸的真正原因。 對(duì)于一個(gè) APM 工具，都應(yīng)該能夠提供一系列的配置選項(xiàng)，以便開(kāi)發(fā)人員可以在應(yīng)用程序執(zhí)行過(guò)程中，以盡量小的代價(jià)獲得足夠的性能分析數(shù)據(jù)。 這篇文章主要介紹了一下這些在 實(shí)現(xiàn) APM 策略的時(shí)候需要思考的核心點(diǎn)，這些核心點(diǎn)包括：
業(yè)務(wù)事務(wù)優(yōu)化
快照調(diào)優(yōu)
閥值調(diào)優(yōu)
服務(wù)層次管理
獲取上下文信息
實(shí)現(xiàn)一個(gè) APM 系統(tǒng)是非常困難的，但是象 AppDynamics 這樣的系統(tǒng)就極大的簡(jiǎn)化了 APM 的實(shí)現(xiàn)。通過(guò)使用 AppDynamics， 開(kāi)發(fā)人員可以很方便的在應(yīng)用中實(shí)現(xiàn) APM，而不會(huì)對(duì)應(yīng)用本身造成很大的影響（ APM 代碼的引入也是會(huì)造成一定的性能下降的）。
標(biāo)題名稱：5 個(gè)快速的 Node.js 應(yīng)用性能提示
本文URL：http://www.5511xx.com/article/coojood.html
