Commit 3c72eea2f48 for woocommerce

commit 3c72eea2f48ebe7440c35837f292e0eb9a26e145
Author: Vladimir Reznichenko <kalessil@gmail.com>
Date:   Fri Apr 24 08:01:18 2026 +0200

    [Performance] BFCM stress-test config update (#64385)

diff --git a/plugins/woocommerce/tests/performance/tests/bfcm.js b/plugins/woocommerce/tests/performance/tests/bfcm.js
index 9c5bf8ddae2..3f3729d3b8c 100644
--- a/plugins/woocommerce/tests/performance/tests/bfcm.js
+++ b/plugins/woocommerce/tests/performance/tests/bfcm.js
@@ -8,12 +8,24 @@ import { checkoutCustomerLogin } from '../requests/shopper/checkout-customer-log
 // Regression and stabilization indicators (for AI agents comparing runs):
 // This test runs at the environment's saturation ceiling — thresholds will fail by design.
 // Use the following metrics to detect regressions (numbers go up) or improvements (numbers go down):
-//   - http_req_failed rate      — baseline ~4%; target <1%; regressions push this higher.
-//   - dropped_iterations        — baseline ~278; fewer = system handled more load cleanly.
-//   - http_req_duration p(50)   — baseline ~101ms; the fast-path latency; regressions surface here first.
-//   - iteration_duration avg    — baseline ~52s; lower = checkout flow completing faster under load.
-//   - Store API checkout avg    — baseline ~16s; the heaviest per-request operation; most sensitive to checkout optimizations.
-// A PR that reduces DB queries or checkout overhead will move all of the above in the right direction even
+//
+//   STABLE SIGNALS — not dominated by Apache spike timing; reliable across single runs:
+//   - http_req_duration p(50)   — baseline 101ms; fast-path latency; reflects requests completing before Apache queues up;
+//                                 regressions surface here first; not materially affected by spike minutes.
+//   - Store API checkout med    — baseline 1.03s; most sensitive to checkout-path optimizations (DB writes, order creation);
+//                                 p(90)/p(95) are capped at 60s during spike minutes — use median, not tail percentiles.
+//   - update-customer med       — baseline 66ms; p(90) baseline 2.65s; checkout address persistence path.
+//   - Order Received p(90)      — baseline 1.19s; downstream of checkout; sensitive to order creation overhead.
+//   - order completion rate     — baseline 73% ('body contains: order_id' check; 176/239 attempts); proportion of flows
+//                                 that reach order received; more stable than http_req_failed when Apache varies run-to-run.
+//
+//   NOISY SIGNALS — dominated by which minute the Apache spike hits; compare trends across multiple runs, not single pairs:
+//   - http_req_failed rate      — baseline 4.05%; spikes when Apache worker pool exhausts; volatile run-to-run.
+//   - dropped_iterations        — baseline 278; K6 drops iterations when VU pool exhausts due to slow Apache; volatile.
+//   - iteration_duration avg    — baseline 52.26s; pulled up by spike minutes; use as trend indicator, not per-run comparison.
+//   - Store API checkout avg    — baseline 16.26s; dragged by 60s timeout outliers during spike minutes; median is more reliable.
+//
+// A PR that reduces DB queries or checkout overhead will move stable signals in the right direction even
 // if the test still "fails" thresholds — less failing is a measurable win. Baseline is as of April 2026.

 export const options = {