利用趨勢和開放API數據加速性能分析

本文是關於如何建立性能工程實踐的係列文章的第三部分，該實踐可以從自動化管道中產生可操作的性能分析。

第1部分:使用Jenkins管道和Kubernetes進行連續負載測試

第2部分:連續性能測試中的3個殺手級反模式

第3部分:使用趨勢和開放API數據加速性能分析

第1部分和第2部分的主要要點:

• 一旦性能測試自動化是可靠的，它產生了一個關鍵的縱向視圖。
• 開放的基於api的性能數據改進了人工和基於管道的工作流。
• 性能數據必須易於使用並且特定於領域。

分布式係統很痛苦

反饋的即時性在行為心理學中起著至關重要的作用。在她1984年的書中，不要射殺狗，Karen Pryor詳細闡述了積極反饋的價值，如果應用得越早越好。相反，延遲反饋在改善情況方麵通常是無效的，而且很容易產生意想不到的、脫離上下文的不利影響。

類似地，構建分布式係統的軟件團隊在方麵遭受“信號延遲”反饋回路關於他們部署的軟件和基礎設施的複雜行為。通常，非功能性(或者，我現在稱之為“整體”)需求被忽略的原因是:

• 迫切要求更高的速度
• 創建和維護適合於驗證這些需求的環境的成本和時間

• 普遍缺乏專業知識

一個心理幽靈仍在為團隊提供懷疑和理由，以忽視他們最終將麵臨的問題:延遲的痛苦。一個基於雲的微服務的例子——後期性能工程。將性能標準排除在計劃過程之外，隻在項目結束時運行大爆炸負載測試，會讓團隊陷入困境。一些重要的問題，如跨區域延遲、錯誤配置的超時和斷路器配置、由於非最優查詢而導致的負載膨脹，以及對存儲子係統的不了解，經常讓開發/運維團隊忙於解決架構問題。

把痛苦提前

在我們的許多領域經驗中，較少遭受此類痛苦情況的客戶內化了使性能工程成為其團隊文化的一部分的重要性。無論是通過為產品組提供專門的專業知識，縮小批處理規模(因此在持續交付中更容易隔離故障)，還是將傳統的整體測試概念分解為在開發/發布周期之間匹配時鍾速度的活動，都存在一個共同的主題:自動化可以自動化的東西，並經常驗證。

對於現代性能工程，目標是產生與係統如何執行相關的常規信息流，以便當性能意外下降時，能夠快速識別和解決。這通常意味著負載測試在多個環境中使用持續集成協調器(如Jenkins、Gitlab或CircleCI)在不同的容量下運行。要運行哪些測試的選擇取決於被測係統(SUT)中的風險因素、測試設計/執行的時間需求以及代碼和環境配置更改頻率。

有時自動化性能測試並不簡單，特別是如果這是您的第一次。Tricentis NeoLoad與各種規模和精明的組織合作。盡管每個組織對於在哪裏應用快速反饋循環都有不同的目標和興趣，但共同的結果包括通過實時性能測試結果和曆史趨勢來提高可觀察性。

一次性能自動化可靠且易於關注，團隊更願意將性能結果擴展為自動化的去/不去決策過程，從而進一步減少不必要的手工工作。對於係統如何隨著時間的推移執行，以及如何在項目組合中滿足性能標準，擁有更大的自由度有助於消除後期的痛苦，加強早期和經常的性能驗證的價值。

示例:API性能的縱向視圖

隨著API團隊改進項目代碼以添加端點、調整現有後端查詢和更改部署配置，在非生產環境中的低級負載測試在性能不滿足sla時提供早期預警指示器。主要數據點API性能測試是:

• 總體測試通過/失敗

• Request-per-second (RPS)
• 吞吐量(Mbps)
• SLA失敗

下麵是NeoLoad Web中的一個示例，它顯示了夜間負載測試的結果，其中關鍵API端點和工作流提供了隨時間變化的性能視圖:

此外，這些測試結果中的每一個都有特定的sla，進一步闡明哪些達到了預期，哪些沒有達到預期。

重要的是，所有這些數據都可以通過帶有NeoLoad Web的RESTful API獲得。對係統數據的安全和開放訪問是任何在現代IT環境中工作良好的產品的關鍵功能。除了信息透明之外，開放api還允許團隊在標準接口的安全網中優化流程的工作方式。

無論是自己部署，還是使用我們基於saas的托管版本，您的性能測試數據都可以聚合並整合到所需的任何特定細節中，以便開始構建適合連續管道的自動放行/不放行決策流程。NeoLoad結果可以歸結為幾個常見的結構:

通過自動化的放行/不放行性能提高管道吞吐量

缺乏最小可行驗證和驗證檢查階段的自動化管道並不能說明全部情況。它們看起來是綠色的，但卻把可靠軟件交付的關鍵細節留到了生產後期處理，因為幾乎不可能追溯到促成因素。

如果你不能把一些東西放進管道中，這是一個很好的機會去問，“為什麼這個不合適?”並不是所有可以想象到的事情都可以自動化，但這不是不努力的借口。自動化的工作將使勞動最小化。如果它被證明是非常困難的，嚐試一些方法，記錄過程，盡可能自動化，然後帶著新的想法回來。當你開始將性能測試整合到自動化管道中，你會學到:

• 你的應用/服務的哪些方麵有明顯且可重複的錯誤

• 哪些測試值得運行(提供價值)，哪些不值得
• 哪些係統不必要地複雜並導致反模式和不穩定
• 哪些支持性環境(包括數據)是不穩定/不可靠的
• 哪些貢獻者展現了批判性思維，哪些貢獻者寫了更多的代碼

案例研究:麵向DevOps客戶的基於管道的自動執行/不執行

我們與Panera Bread的性能和自動化團隊合作，在Jenkins管道中構建了一個自定義的放行/不放行流程，以滿足他們的特定要求，其中一些包括:

• 生成人類可讀、可歸檔的性能比較報告，突出顯示超出預定範圍(+/- 5%或10%)的百分比變化:

• 特定的測試工作流事務(例如，登錄、添加到購物車、結帳等)
• 係統指示器(JVM垃圾收集計數、線程池大小等)
• 特定API請求

• 以Jenkins易於使用的格式輸出基於上述約束的違規列表

• JSON比較數據，如果存在任何違規，則指示放行/不放行
• 自定義範圍和違規規則用Node.js編寫(為了技能普及)

• 將項目的特定測試結果持久化為未來作業運行的基線的流程模式(直到在該項目上建立新的基準)

這項工作的目標是使產品團隊能夠使用自動化標誌輕鬆地將性能測試作為高級需求添加，然後基於Groovy庫/命名約定，定期運行現有的性能測試，並自動管理用於持續比較的基線，以突出頻繁的CI構建中意外的性能更改。

比較報告的通用代碼已打開Github．但是，它隻強調了一個示例，說明您可以使用一個透明的、在構建時考慮到可擴展性的企業性能測試平台來做什麼。由於Panera也有維護和自動滾動成功測試的自定義規則，作為特定條件下的新基線，我們為該過程提出了一個主要序列:

通過這種簡單的機製，他們能夠構建標準的Jenkins共享庫來簡化單個項目管道腳本中的物流。最終，他們將所有性能語義都集中到一個項目選擇加入標誌上。利用Tricentis NeoLoad在項目子目錄中的測試套件中，這些管道運行與基線相比的各種負載測試(使用任何越界的方差和違規來停止部署過程，通知工程師進行調查)。

客戶使用NeoLoad api的其他示例包括跨項目組合的通過/失敗熱圖，基於係統內和跨係統的一組關鍵事務的自定義趨勢，甚至是幫助開發團隊查看關鍵模塊如何執行的簡單自助門戶，如下所示:

使用sla減少性能數據中的認知衝擊

性能數據必須易於使用並且特定於領域。你需要看的數據、圖表和圖表越多，你就越有可能對基本指標脫敏。許多團隊正在從其他單片性能產品轉向Tricentis NeoLoad從他們的開發人員那裏聽說，一份來自某公司的負載測試結果的大而客觀的PDF報告負載測試工具他們不使用並不能幫助他們。通過挖掘統計數據來獲得有意義的見解不應該是產品團隊花費時間的事情。

在一些組織中，原始測試結果繼續通過“分析過程”進行傳輸，通常是通過半智能電子表格手動導出/導入步驟，需要將圖表複製/粘貼到最終的幻燈片中(不容易由機器讀取)。盡管有時這個過程的元素是必要的，特別是當出現重複的異常時(在大多數自動化的過程中)，但每次為每個新構建都這樣做簡直是瘋狂。

更好的方法是將流程分開(就像任何優秀的工程師所做的那樣)，確定哪些部分最容易自動化，哪些部分花費最多時間，以及哪些部分阻礙了整個端到端流程的自動化。在此過程中，您將了解關鍵上下文在各個項目中的不同之處，如何盡早提取該上下文，以及如何讓人們知道該上下文中的性能偏離預期規範的時刻。

性能測試的一個重要部分是建立sla並將其注入到負載測試中。每個環境可能有不同的方差，因此有不同的sla，但是，NeoLoad可以很容易地將sla表示為代碼:

與偶爾受到性能異常值影響的功能測試不同，NeoLoad sla可以配置為每個間隔/測試計算，從而提供觸發時間的靈活性。

一旦這些sla與其他元素分層在一起，無論是來自圖形設計器還是yaml編寫的(在測試執行後)，它的通過/失敗，閾值數據將從NeoLoad api通過[/測試/ {testId} / sla /…)端點。

NeoLoad api的另一個很酷的功能是，它們包括圖形端點，這樣你就可以為自動通知(即Slack)生成有意義的圖像，並自定義圖形的數據:

生成PNG輸出…

當性能測試期間違反sla時，您可以快速地將過去複雜的分析過程轉換為更離散的自動通知給產品團隊。

這篇文章最初是於2019年發布，最近一次更新是在2021年7月。

一定要看看我們的白皮書連續性能測試的實用指南尋求實用的建議和幫助。