【51CTO.com快譯】在任何現(xiàn)代化軟件組織的日常工作中，性能工程(Performance engineering)和壓力測(cè)試(load testing)都是非常關(guān)鍵的組成部分。實(shí)際上，許多公司都會(huì)在此類團(tuán)隊(duì)的建設(shè)上日益增加投入。而那些缺乏此類流程的公司，也正在朝著該方向迅速改進(jìn)中。

從理論上說(shuō)：在關(guān)鍵性能指標(biāo)(KPI，請(qǐng)參見(jiàn)：https://kpi.org/KPI-Basics)的驅(qū)動(dòng)下，軟件應(yīng)用領(lǐng)域的性能工程和壓力測(cè)試具有如下三個(gè)主要目標(biāo)：

1. 驗(yàn)證應(yīng)用程序的當(dāng)前負(fù)載容量。

2. 識(shí)別應(yīng)用代碼、軟件配置、以及硬件資源上的瓶頸限制。

3. 提高應(yīng)用程序的可伸縮性，以滿足目標(biāo)負(fù)載能力。

具體來(lái)說(shuō)，典型的壓力測(cè)試會(huì)涉及如下六個(gè)方面：

目前，雖然業(yè)界有著大量的相關(guān)測(cè)試工具，它們可以通過(guò)生成并非用戶的訪問(wèn)負(fù)載，來(lái)進(jìn)行性能測(cè)試，但是New Relic平臺(tái)，特別是New Relic APM(https://newrelic.com/products/application-monitoring)、New Relic Infrastructure(https://newrelic.com/products/infrastructure)和New Relic Browser(https://newrelic.com/products/browser-monitoring)都提供了較為深入的監(jiān)控與服務(wù)，以及各種關(guān)鍵性的洞見(jiàn)。New Relic能夠分析瀏覽器的響應(yīng)時(shí)間、用戶的會(huì)話數(shù)、應(yīng)用程序的運(yùn)行速度、以及后端資源的利用率。根據(jù)New Relic所創(chuàng)建的壓力測(cè)試環(huán)境，測(cè)試團(tuán)隊(duì)能夠獲悉有關(guān)應(yīng)用性能的端到端“全景視圖”。

本文將分為3部分、12個(gè)步驟，向您介紹在性能工程中，如何使用New Relic開展有序的壓力測(cè)試，并進(jìn)行規(guī)范性的根本原因分析。

第1部分：設(shè)置基線并確定當(dāng)前容量?

我們的首要任務(wù)就是先構(gòu)造壓力測(cè)試，然后緩慢增加負(fù)載，直至應(yīng)用程序出現(xiàn)瓶頸。

1.我們從最小用戶數(shù)的負(fù)載開始(例如：5個(gè)用戶的并發(fā)量)，執(zhí)行至少持續(xù)一小時(shí)的壓力測(cè)試。我們將這種低負(fù)載測(cè)試的結(jié)果作為一個(gè)基線。

如果針對(duì)基線壓力測(cè)試的結(jié)果，已經(jīng)能夠出現(xiàn)并發(fā)的事務(wù)超出了服務(wù)級(jí)別協(xié)議(SLA)，那么我們就沒(méi)有理由再進(jìn)行下一步的可伸縮性測(cè)試了。而如果一切正常，我們則繼續(xù)下一步。

2.通過(guò)基線壓力測(cè)試的結(jié)果，您可以為應(yīng)用設(shè)置可接受的Apdex分?jǐn)?shù)(https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measure-user-satisfaction)。該Apdex是目標(biāo)應(yīng)用程序平均響應(yīng)時(shí)間的標(biāo)準(zhǔn)。您需要為那些在執(zhí)行時(shí)間上超過(guò)整體SLA的特定事務(wù)，創(chuàng)建關(guān)鍵事務(wù)(https://docs.newrelic.com/docs/apm/transactions/key-transactions/introduction-key-transactions)。例如，對(duì)于典型的Web應(yīng)用而言，其Browser Apdex值應(yīng)當(dāng)為0.3秒。而Java應(yīng)用程序的APM Apdex值則可能為0.5秒。如果您的應(yīng)用程序有一個(gè)微服務(wù)集合，并通過(guò)API來(lái)處理事務(wù)，那么每個(gè)服務(wù)的Apdex則可能是0.2秒。因此，我們的宗旨是為每個(gè)執(zhí)行事務(wù)的服務(wù)，設(shè)置適當(dāng)?shù)腁dex值。

3.設(shè)計(jì)并執(zhí)行壓力測(cè)試，然后有條不紊地增加用戶數(shù)量。請(qǐng)為每一個(gè)應(yīng)用程序設(shè)計(jì)不同的吞吐量和用戶負(fù)載目標(biāo)。例如，您可以使用5個(gè)并發(fā)用戶數(shù)來(lái)觸發(fā)壓力測(cè)試，接著每隔15秒鐘再添加5個(gè)用戶。隨著用戶數(shù)量的增加，壓力測(cè)試將慢慢接近性能的臨界點(diǎn)，這將使您能夠了解到目標(biāo)應(yīng)用程序所能夠處理負(fù)載的極限。

記?。簤毫y(cè)試應(yīng)當(dāng)被設(shè)計(jì)為有序進(jìn)行，而不要一股腦地將目標(biāo)工作負(fù)載拋給應(yīng)用程序，否則得到的結(jié)果不但混亂、且難以解釋。例如：如果您的目標(biāo)是達(dá)到5,000個(gè)并發(fā)用戶，那么您設(shè)計(jì)的壓力測(cè)試應(yīng)當(dāng)先錨定該目標(biāo)的一半。如果此應(yīng)用能夠成功地?cái)U(kuò)展到目標(biāo)負(fù)載的一半，那么您才可以繼續(xù)設(shè)計(jì)下一輪測(cè)試，以使負(fù)載加倍。同樣，如果您測(cè)試的是負(fù)載吞吐量，而不是用戶數(shù)與活動(dòng)會(huì)話，那么您仍然可以使用相同的方法穩(wěn)健地達(dá)到目標(biāo)所設(shè)定的每秒事務(wù)數(shù)。例如，如果您的API吞吐量目標(biāo)為每秒200個(gè)事務(wù)的話，那么您可以逐步將測(cè)試的壓力擴(kuò)展到每秒100個(gè)事務(wù)。

4.在應(yīng)用程序的APM概覽頁(yè)面中，您可以通過(guò)更改視圖，來(lái)查看“Web事務(wù)分位數(shù)(Web transactions percentiles)”。由于其中95%的記錄都會(huì)比中位或平均值更加敏銳與精細(xì)，因此您可以將主要精力集中在這95%的記錄行上。

通過(guò)觀察，您可以找到目標(biāo)應(yīng)用在壓力測(cè)試下開始出現(xiàn)服務(wù)質(zhì)量下降的時(shí)間點(diǎn)，然后突出顯示并放大該時(shí)間范圍與跨度，以便您能夠執(zhí)行更為深入的分析。例如，您可以深入挖掘各種事務(wù)性、分布式的軌跡、以及相關(guān)的錯(cuò)誤，或是從APM模式切換到Browser模式，以便從前端轉(zhuǎn)為后端分析。New Relic能夠持續(xù)地自動(dòng)聚焦該時(shí)間范圍內(nèi)的各類信息。

記?。涸摐y(cè)試部分的主要目標(biāo)是首次識(shí)別瓶頸，因此您不需擔(dān)心在首次拐點(diǎn)之后的圖表走勢(shì)。任何跨過(guò)該點(diǎn)的狀態(tài)，都只是某個(gè)根本原因的后續(xù)癥狀而已。

第2部分：隔離首個(gè)瓶頸

針對(duì)上述發(fā)現(xiàn)的性能下降情況，您可以根據(jù)應(yīng)用的實(shí)際情況，執(zhí)行如下步驟5到9(可以不一定按照該順序)以進(jìn)行問(wèn)題排查。例如，您可以從使用New Relic Browser去分析響應(yīng)的時(shí)間開始，順藤摸瓜，直到發(fā)現(xiàn)APM中的代碼缺陷(也就是所謂的自上而下的方法)。當(dāng)然，您也可以從New Relic Infrastructure開始，以識(shí)別那些導(dǎo)致瀏覽器響應(yīng)耗時(shí)的資源限制(也就是所謂的自下而上的方法)。

5.利用在步驟4中所收集的信息，采用服務(wù)映射(service maps，https://docs.newrelic.com/docs/understand-dependencies/understand-system-dependencies/service-maps/introduction-service-maps)來(lái)識(shí)別到底是哪個(gè)應(yīng)用事務(wù)的哪些內(nèi)、外部服務(wù)水平出現(xiàn)了下降，并導(dǎo)致了總體響應(yīng)時(shí)間的增加。

如果您發(fā)現(xiàn)有多個(gè)事務(wù)存在著服務(wù)水平的下降趨勢(shì)，那么這通常表明有某些資源已經(jīng)接近到了它們的飽和點(diǎn)。

事務(wù)分析

6.使用New Relic APM來(lái)逐步隔離各種代碼的缺陷、或是錯(cuò)誤的條件。使用事務(wù)跟蹤(transaction traces，https://docs.newrelic.com/docs/apm/transactions/transaction-traces/introduction-transaction-traces)的方法，來(lái)隔離服務(wù)降級(jí)、或是拋出錯(cuò)誤的確切代碼。

7.使用Infrastructure的主機(jī)集成(on-host integrations，https://docs.newrelic.com/docs/integrations/host-integrations/getting-started/introduction-host-integrations)，來(lái)識(shí)別基礎(chǔ)架構(gòu)中諸如Web服務(wù)器、JVM或數(shù)據(jù)庫(kù)等方面的限制。

8.使用Infrastructure來(lái)檢查應(yīng)用部署所涉及到的每一臺(tái)主機(jī)和服務(wù)器，以查看是否有硬件資源(CPU、內(nèi)存、以及網(wǎng)絡(luò)等)被濫用的情況。

硬件資源不一定是在完全飽和時(shí)，才能導(dǎo)致響應(yīng)時(shí)間的延長(zhǎng)。有時(shí)候，達(dá)到70%的飽和度時(shí)，其性能就會(huì)受到影響。如果您在壓力測(cè)試中發(fā)現(xiàn)瓶頸并非源自硬件資源，那么就請(qǐng)檢查服務(wù)器的軟件資源，其中包括：連接池、數(shù)據(jù)源連接數(shù)、及其TCP堆棧等方面。因?yàn)楫?dāng)軟件資源飽和時(shí)，它們同樣會(huì)在基礎(chǔ)架構(gòu)中出現(xiàn)“排隊(duì)”的狀況。

9.使用Browser來(lái)確定響應(yīng)時(shí)間的增加是否來(lái)自應(yīng)用的前端。例如，當(dāng)您的站點(diǎn)需要呈現(xiàn)某些HTML類資產(chǎn)時(shí)，那些向第三方遠(yuǎn)程服務(wù)器發(fā)送的Ajax請(qǐng)求數(shù)，就有可能會(huì)導(dǎo)致整體速度的下降。

第3部分：優(yōu)化以緩解瓶頸問(wèn)題

在確定了瓶頸的原因之后，您需要通過(guò)實(shí)施變更，來(lái)應(yīng)對(duì)新的壓力測(cè)試。

10.對(duì)于應(yīng)用程序的任何變更，您都需要設(shè)置New Relic的部署標(biāo)記(deployment marker，https://docs.newrelic.com/docs/apm/new-relic-apm/maintenance/record-deployments)來(lái)予以記錄。您可以使用諸如：“向VM增加了2顆CPU”之類詳細(xì)信息，來(lái)標(biāo)記針對(duì)某次變更的部署。

記?。阂淮蝺H修改一個(gè)變量。如果您一次性地修改了兩個(gè)、或更多的內(nèi)容(例如，增加了多個(gè)硬件資源、并讓JVM堆棧的大小翻倍了)，那么您將無(wú)從知曉到底是哪個(gè)變量，如何影響了應(yīng)用程序的總體負(fù)載性能。

11.重新運(yùn)行壓力測(cè)試并分析新的結(jié)果，以判斷性能是否有所改觀。如果沒(méi)有任何差異的話，那就意味著您并未找到真正的瓶頸。請(qǐng)保留或還原先前的變更，并按需重復(fù)前面的測(cè)試步驟。

12.持續(xù)進(jìn)行壓力測(cè)試，直至真正消除了瓶頸，并滿足了既定的各項(xiàng)負(fù)載需求。

使性能工程成為一個(gè)迭代的過(guò)程

客觀地說(shuō)，壓力測(cè)試和性能工程是“永無(wú)止境”的。由于從應(yīng)用程序的工作負(fù)載、到功能服務(wù)、再到體系架構(gòu)中的幾乎每個(gè)組件，我們都需要對(duì)它們進(jìn)行持續(xù)的開發(fā)與部署，因此就算是某個(gè)新增的簡(jiǎn)單變更，也可能會(huì)對(duì)前期的性能測(cè)試結(jié)果帶來(lái)干擾。所以說(shuō)，性能測(cè)試應(yīng)當(dāng)隨著應(yīng)用程序的迭代而繼續(xù)。

其他的壓力測(cè)試和性能分析資源

下面是一些您可能在壓力測(cè)試和性能分析中用得上的，其他類型的New Relic工具：

• 服務(wù)映射(https://docs.newrelic.com/docs/understand-dependencies/understand-system-dependencies/service-maps/introduction-service-maps)：在應(yīng)用程序的部署過(guò)程中，可用于識(shí)別服務(wù)之間的連接、以及上/下游的依賴關(guān)系。
• 分布式跟蹤(https://docs.newrelic.com/docs/apm/distributed-tracing/getting-started/introduction-distributed-tracing)：方便用戶清楚地獲悉應(yīng)用程序中不同事務(wù)的橫向服務(wù)。
• 儀表板(https://docs.newrelic.com/docs/dashboards/new-relic-one-dashboards/get-started/introduction-new-relic-one-dashboards)：在壓力測(cè)試期間，通過(guò)靈活的交互方式，可視化地跟蹤那些用戶感興趣的KPI。

原文標(biāo)題：How to Use New Relic for Performance Engineering and Load Testing ，作者：Rebecca Clinard

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】