Merge pull request #535 from MDA2AV/gatewayz

add tests, gateway h3, production stack

Author: MDA2AV

scripts/benchmark.sh

@@ -205,7 +205,7 @@ run_one() {
     # best_rps starts at -1 so that the *first* measurement always wins,
     # even if its rps is 0 (ws-echo, zero-traffic regressions). Without this,
     # BEST_M would carry stale metrics from a previous profile.
-    local best_rps=-1 best_output="" best_cpu="0%" best_mem="0MiB"
+    local best_rps=-1 best_output="" best_cpu="0%" best_mem="0MiB" best_breakdown=""
     BEST_M=()
     local run
 
@@ -241,6 +241,7 @@ run_one() {
             best_output="$output"
             best_cpu="$STATS_AVG_CPU"
             best_mem="$STATS_PEAK_MEM"
+            best_breakdown="$STATS_BREAKDOWN"
             BEST_M=()
             for k in "${!m[@]}"; do BEST_M[$k]="${m[$k]}"; done
         fi
@@ -279,6 +280,12 @@ save_result() {
     local dir="$RESULTS_DIR/$profile/$CONNS"
     mkdir -p "$dir"
 
+    local cpu_extra=""
+    if [ -n "$best_breakdown" ]; then
+        cpu_extra=",
+  \"cpu_breakdown\": \"$best_breakdown\""
+    fi
+
     local tpl_extra=""
     if [ "$profile" = "api-4" ] || [ "$profile" = "api-16" ]; then
         tpl_extra=",
@@ -299,6 +306,17 @@ save_result() {
   \"tpl_baseline\": $(( total * 4 / 20 )),
   \"tpl_json\": $(( total * 7 / 20 )),
   \"tpl_async_db\": $(( total * 3 / 20 ))"
+    elif [ "$profile" = "production-stack" ] \
+         && [ "${BEST_M[status_2xx]:-0}" -gt 0 ] 2>/dev/null; then
+        # Production-stack mix from reads file (20K URIs):
+        # 6000 static (30%) / 2000 baseline (10%) / 10000 items (50%) / 2000 me (10%).
+        # Writes (POST /api/items) add to items but are small (~5% of traffic).
+        local total=${BEST_M[status_2xx]}
+        tpl_extra=",
+  \"tpl_static\": $(( total * 30 / 100 )),
+  \"tpl_baseline\": $(( total * 10 / 100 )),
+  \"tpl_items\": $(( total * 50 / 100 )),
+  \"tpl_me\": $(( total * 10 / 100 ))"
     fi
 
     cat > "$dir/${FRAMEWORK}.json" <<EOF
@@ -319,7 +337,7 @@ save_result() {
   "status_2xx": ${BEST_M[status_2xx]:-0},
   "status_3xx": ${BEST_M[status_3xx]:-0},
   "status_4xx": ${BEST_M[status_4xx]:-0},
-  "status_5xx": ${BEST_M[status_5xx]:-0}${tpl_extra}
+  "status_5xx": ${BEST_M[status_5xx]:-0}${tpl_extra}${cpu_extra}
 }
 EOF
     info "saved results/$profile/$CONNS/${FRAMEWORK}.json"

site/content/_index.md

@@ -155,13 +155,23 @@ html.dark .test-card-endpoint { color: #64748b; }
 </div>
 
 <div class="tests-proto">
-<span class="tests-proto-label tests-proto-h2">H/2 Gateway</span>
+<span class="tests-proto-label tests-proto-h2">Gateway</span>
 <div class="tests-grid">
-  <a class="test-card" href="docs/test-profiles/h2-gateway/gateway-64">
-    <div class="test-card-title">Gateway-64</div>
-    <div class="test-card-desc">Reverse proxy + application server — mixed static, JSON, and async-db workload over HTTP/2 with TLS. 64 CPUs split between proxy and server.</div>
+  <a class="test-card" href="docs/test-profiles/gateway/gateway-h2">
+    <div class="test-card-title">Gateway H2</div>
+    <div class="test-card-desc">Two-service proxy + server stack over HTTP/2 + TLS. Mixed workload: static, JSON, baseline, async-db.</div>
     <div class="test-card-endpoint">proxy:8443 → server (h2)</div>
   </a>
+  <a class="test-card" href="docs/test-profiles/gateway/gateway-h3">
+    <div class="test-card-title">Gateway H3</div>
+    <div class="test-card-desc">Same two-service stack as Gateway H2 but with HTTP/3 + QUIC at the edge.</div>
+    <div class="test-card-endpoint">proxy:8443 → server (h3/quic)</div>
+  </a>
+  <a class="test-card" href="docs/test-profiles/gateway/production-stack">
+    <div class="test-card-title">Production Stack H2</div>
+    <div class="test-card-desc">Four-service CRUD API: edge + Redis + JWT auth sidecar + server. 10K-item cache-aside, concurrent reads + writes.</div>
+    <div class="test-card-endpoint">edge:8443 → authsvc → server → redis/postgres</div>
+  </a>
 </div>
 </div>
 

site/content/docs/add-framework/meta-json.md

@@ -88,4 +88,4 @@ The `gateway-64` profile tests your framework as part of a complete deployment s
 - The proxy, caching layer, and internal protocol choices are all part of the benchmark
 - Static files can be served directly by the proxy (e.g., Nginx) instead of the application server
 
-See the [Gateway-64 implementation guide](/docs/test-profiles/h2-gateway/gateway-64/implementation) for detailed documentation, three complete compose examples (two-tier, three-tier, and single-tier), CPU topology rules, and proxy configuration options.
+See the [Gateway-64 implementation guide](/docs/test-profiles/gateway/gateway-h2/implementation) for detailed documentation, three complete compose examples (two-tier, three-tier, and single-tier), CPU topology rules, and proxy configuration options.

site/content/docs/scoring/composite-score.md

@@ -72,23 +72,13 @@ Not all profiles count toward the composite score. Profiles marked as **scored**
 | Baseline | Yes | Query parsing over QUIC (UDP) with TLS 1.3 |
 | Static | Yes | 20 static files served over QUIC (UDP) with TLS 1.3 |
 
-### H/2 Gateway
+### Gateway
 
 | Profile | Scored | Workload |
 |---|---|---|
-| Gateway-64 | Yes | Two-service proxy + server stack (static / JSON / async-db / baseline mix) over HTTP/2 + TLS, 64-CPU budget split freely between proxy and server |
-
-### H/3 Gateway
-
-| Profile | Scored | Workload |
-|---|---|---|
-| Gateway-H3 | Yes | Same two-service stack as Gateway-64 but with HTTP/3 + QUIC at the edge, measuring h3 proxy termination efficiency at realistic connection counts |
-
-### Production Stack
-
-| Profile | Scored | Workload |
-|---|---|---|
-| Production Stack | Yes | Four-service CRUD API deployment (edge + Redis cache + JWT auth sidecar + framework server) with 10K-item working set. JWT HMAC-SHA256 verified on every `/api/*` request (no caching). Framework implements cache-aside with ≤1s TTL (cache strategy is the framework's choice). Concurrent reads + writes via split h2load. |
+| Gateway H2 | Yes | Two-service proxy + server stack over HTTP/2 + TLS, mixed workload (static 30%, JSON 35%, baseline 20%, async-db 15%), 64-CPU budget |
+| Gateway H3 | Yes | Same two-service stack over HTTP/3 + QUIC at the edge |
+| Production Stack H2 | Yes | Four-service CRUD API (edge + Redis + JWT auth + server) with 10K-item cache-aside, JWT verified every request, concurrent reads + writes |
 
 ### gRPC
 

site/content/docs/test-profiles/_index.md

@@ -33,7 +33,7 @@ Data files are **mounted automatically** by the benchmark runner — your Docker
 {{< cards >}}
   {{< card link="h1" title="H/1.1" subtitle="Isolated single-endpoint benchmarks and multi-endpoint workload mixes over plain TCP." icon="lightning-bolt" >}}
   {{< card link="h2" title="H/2" subtitle="Baseline and static file benchmarks over encrypted TLS connections with stream multiplexing." icon="globe-alt" >}}
-  {{< card link="h2-gateway" title="H/2 Gateway" subtitle="Reverse proxy + application server benchmarks over HTTP/2 with TLS. Tests full-stack deployment performance." icon="server" >}}
+  {{< card link="gateway" title="Gateway" subtitle="Multi-service deployments: proxy + server (H2/H3) and full CRUD production stack with JWT auth + cache-aside." icon="server" >}}
   {{< card link="h3" title="H/3" subtitle="Baseline and static file benchmarks over QUIC for frameworks with native H/3 support." icon="globe-alt" >}}
   {{< card link="grpc" title="gRPC" subtitle="Unary RPC throughput over cleartext HTTP/2 using Protocol Buffers serialization." icon="globe-alt" >}}
   {{< card link="ws" title="WebSocket" subtitle="WebSocket echo throughput measuring frame processing performance." icon="globe-alt" >}}

site/content/docs/test-profiles/gateway/_index.md

@@ -0,0 +1,14 @@
+---
+weight: 3
+title: Gateway
+---
+
+Gateway test profiles benchmark multi-service deployments — proxy + server, with optional auth sidecars, caches, and databases. Unlike isolated tests that measure a single framework container, gateway tests measure the **end-to-end throughput of the entire stack** as a unit.
+
+All gateway tests use Docker Compose for orchestration, pin services to specific CPU cores via `cpuset`, and give entries full control over their architecture within a fixed 64-CPU budget.
+
+{{< cards >}}
+  {{< card link="gateway-h2" title="Gateway H2" subtitle="Two-service proxy + server stack over HTTP/2 + TLS. Mixed workload: static 30%, JSON 35%, baseline 20%, async-db 15%." icon="server" >}}
+  {{< card link="gateway-h3" title="Gateway H3" subtitle="Same two-service stack as Gateway H2 but with HTTP/3 + QUIC at the edge." icon="lightning-bolt" >}}
+  {{< card link="production-stack" title="Production Stack H2" subtitle="Four-service CRUD API: edge + Redis + JWT auth sidecar + server. 10K-item cache-aside, JWT verified every request, concurrent reads + writes." icon="shield-check" >}}
+{{< /cards >}}

site/content/docs/test-profiles/gateway/gateway-h2/_index.md

@@ -0,0 +1,10 @@
+---
+title: Gateway H2
+---
+
+Two-service proxy + server stack over HTTP/2 + TLS. Proxy serves static files directly from disk, forwards dynamic endpoints (baseline, JSON, async-db) to the application server. 64 CPUs split freely between the two services.
+
+{{< cards >}}
+  {{< card link="implementation" title="Implementation Guidelines" subtitle="Compose file layout, endpoint responsibilities, proxy-to-server protocol, CPU allocation." icon="code" >}}
+  {{< card link="validation" title="Validation" subtitle="Checks executed by validate.sh against the running compose stack." icon="check-circle" >}}
+{{< /cards >}}