效能測試秘訣
若要評估上述所有變更的成效，應在上線之前，以及在未來對您的生產環境進行任何重大部署之前執行徹底的效能測試。 規劃負載測試時，請務必儘可能模擬實際消費者流量。
AEM/CIF/Adobe Commerce網站中資源最密集的區域是無法快取的區域，例如結帳程式和網站搜尋。 一般而言，靜態且因此可快取的頁面瀏覽(例如生產詳細資料頁面(PDP)和產品清單頁面(PLP))會構成電子商務網站的大部分流量，因此測試中的指令碼和案例應該反映這一點，以測量平台的限制。
讓單一指令碼執行負載測試，該指令碼會導覽整個網站，不需要等上任何兩個步驟之間的時間，並且每次都會完成結帳程式，因此無法可靠地指出平台的限制，因為這並非現實情境。
定義KPI應該是效能測試計畫中的第一個步驟：定義您可在初始測試期間測試，但在未來可再次測量的量度，並可在網站正式啟用後重複測量。 這可讓您追蹤網站效能在一段時間內的表現 — 啟動前和啟動後。 要定義的範例KPI可能是：
- 平均回應時間 — 到第一個位元組或最後一個位元組的時間
- 延遲
- 位元組/秒（輸送量）
- 錯誤率
- 每小時訂單數
- 每小時的頁面檢視次數
- 每小時不重複使用者（同時購物者）
Jmeter指南
開發AEM/CIF/Adobe Commerce負載測試時，應考慮下列Jmeter高階准則：
-
將指令碼分割為可設定的案例，例如，應涵蓋：
-
開啟首頁
-
開啟類別頁面(PLP)
-
檢視簡單產品(PDP) — 每個反複專案包含2個回圈
-
檢視可設定的產品 — 每個反複專案內有2個回圈
- 例如，將上述步驟設為流量的60%
-
產品搜尋
- 例如，將搜尋目錄設為流量的37%
-
購物車與結帳
- 例如，使用者完成購物車和結帳部分指令碼時，預設的業界標準電子商務網站轉換率約為3%
- 由於結帳流程未快取，且通常是資源密集的作業，因此若將完成訂單的人數與網站瀏覽器人數設定為不切實際的高值，將導致網站可處理的流量結果不可靠。
-
-
在每次測試執行前清除所有快取：
- 應該完全清除AEM Dispatcher快取
- Adobe Commerce的Fastly和內部快取應完全清除和清理 — 這可以透過Adobe Commerce管理員中的快取控制完成。
-
在Jmeter測試中包含斜坡期：沒有斜坡期設定表示流量沒有逐漸斜坡，網站沒有機會快取頁面的任何經常造訪的頁面和元件。 在實際情況中，所有尖峰流量完全同時抵達未完全快取的網站是不尋常的，因此Jmeter測試指令碼中應該包含斜坡期，以允許快取建立，就像在真正的電子商務網站上發生的情況一樣。
-
應該使用疊代內每個步驟之間的「等待時間」，實際上使用者不會
在歷程中立即跳至網站上的下一個頁面 — 使用者會有一段等待時間，等待使用者閱讀頁面並決定他們的下一個動作。 -
將對話串群組設定為無限回圈，但在設定的x時間（例如60分鐘）內，將會提供可重複的測試，其中位回應時間可與先前的測試執行相媲美。 這表示在設定提升期間之後，將會有同時執行的目標虛擬使用者數量，且在設定回圈時間中將繼續進行。
-
應該使用中位數時間，來改善/降低平均回應時間，而非平均回應時間。 如果
有幾個Edge結果比其他結果需要更長的時間，這會扭曲此平均結果，但我們感興趣的是大多數使用者的一般使用者回應時間，這更適合中位數測量。 -
預設不會在jmeter中收集內嵌資源（例如當實際使用者造訪頁面時下載的JS、CSS和其他資源）。 這可以啟用，但僅適用於您測試的網域 — 仍應排除外部資源呼叫(例如，我們不希望包含來自外部託管服務的回應時間，例如 google analytics程式碼)，因為我們無法控制它們。
-
應該啟用「HTTP快取管理員」，如此可讓Jmeter在歷程中快取頁面元素，做為
實際使用者的歷程會在他們使用自己的瀏覽器瀏覽網站時進行。 在使用者瀏覽網站的歷程中，使用者的瀏覽器只會下載一次相關的內嵌資源，然後這些資源就會由使用者的瀏覽器快取。 此外，如果同一位使用者在最初造訪後回到網站，則仍可能是這些資產被快取的快取。 -
監聽器應保留在實際負載測試執行中（例如「檢視結果樹狀結構」和「彙總報告」）。 在非GUI實際負載測試回合中包括此項，可能會影響Jmeter報告的效能結果，因為實際測試回合期間會使用資源來產生報告。 這些接聽程式已從測試指令碼中移除，並由JTL結果檔案取代，然後可以使用Jmeter的報表控制面板功能加以處理。
-
評估的目標回應時間，以便控制面板報表的「Apdex分數」可以作為一種快速方法，來測量測試執行之間變更對效能的影響。 Apdex分數是根據特定人數的人能在容許的時間記憶體取網站。 如果回應時間超過某個「令人沮喪」的量，就會降低分數。 可使用「apdex_satistified_threshold」和「apdex_tolerated_threshold」引數來設定時間。
-
設定要呈現給業務使用者的目標「每小時訂單數」量度，而非虛擬使用者計數。 「虛擬使用者」可能是一個複雜的主題，以瞭解測試在現實生活中所測量的內容。 透過計算網站轉換率、每小時訂單數、使用者在網站上逗留的平均時間，以及思考每次頁面載入之間的時間，業界標準計演算法可用於根據每小時訂單數呈現不同的載入測試案例。
-
最後，您的Jmeter測試伺服器應在地理位置上靠近大多數使用者流量來源和雲端基礎架構託管位置的伺服器上執行 — 希望兩者相同。