perf-skills 3.0.0 → 4.0.0

package/.claude-plugin/marketplace.json

@@ -5,15 +5,15 @@
     "email": "contact@qainsights.com"
   },
   "metadata": {
-    "description": "Expert AI skill for performance testing - covers the full lifecycle using JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, and OctoPerf.",
-    "version": "1.0.4"
+    "description": "Expert AI skill for performance testing - covers the full lifecycle using JMeter, k6, Gatling, Locust, Artillery, NeoLoad, LoadRunner, OctoPerf, plus LLM inference benchmarking and SLO/capacity planning.",
+    "version": "4.0.0"
   },
   "plugins": [
     {
       "name": "perf",
       "source": "./",
-      "description": "Expert guidance for performance testing: planning, scripting, executing, and analyzing load/stress/soak/spike tests across 7 tools and 10 topic areas.",
-      "version": "1.0.4",
+      "description": "Expert guidance for performance testing: planning, scripting, executing, and analyzing load/stress/soak/spike tests across 8 tools, 13 topic areas, LLM inference benchmarking, and SLO/capacity planning.",
+      "version": "4.0.0",
       "author": {
         "name": "NaveenKumar Namachivayam",
         "email": "contact@qainsights.com"
@@ -28,6 +28,7 @@
         "k6",
         "gatling",
         "locust",
+        "artillery",
         "neoload",
         "loadrunner",
         "octoperf",
@@ -38,6 +39,10 @@
         "websocket",
         "observability",
         "ci-cd",
+        "llm-inference",
+        "vllm",
+        "slo",
+        "capacity-planning",
         "performance-testing-best-practices",
         "performance-testing-strategies",
         "black-friday-performance-testing",
@@ -68,12 +73,15 @@
         "k6",
         "gatling",
         "locust",
+        "artillery",
         "neoload",
         "loadrunner",
         "octoperf",
         "performance-engineering",
-        "load-testing-automation",
-        "performance-testing-automation",
+        "llm-inference",
+        "vllm",
+        "slo",
+        "capacity-planning",
         "performance-testing-best-practices",
         "performance-testing-strategies"
       ]

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "perf",
-  "description": "Expert guidance for performance testing: planning, scripting, executing, and analyzing load/stress/soak/spike tests using JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, OctoPerf.",
-  "version": "1.0.4",
+  "description": "Expert guidance for performance testing: planning, scripting, executing, and analyzing load/stress/soak/spike tests using JMeter, k6, Gatling, Locust, Artillery, NeoLoad, LoadRunner, OctoPerf, plus LLM inference benchmarking and SLO/capacity planning.",
+  "version": "4.0.0",
   "skills": "./skills/"
 }

package/README.md

@@ -30,9 +30,10 @@
 
 | Category | Supported Technologies |
 | :--- | :--- |
-| **Open Source** | Apache JMeter, k6 (Grafana Labs), Gatling, Locust |
+| **Open Source** | Apache JMeter, k6 (Grafana Labs), Gatling, Locust, Artillery |
 | **Commercial/SaaS** | NeoLoad (Tricentis), LoadRunner (OpenText), OctoPerf |
 | **Protocols** | HTTP/REST, gRPC, GraphQL, WebSocket, SSE, JDBC, SOAP, Kafka/MQ, Citrix, SAP |
+| **AI/ML** | LLM inference benchmarking (vLLM, TRT-LLM, SGLang), SLO/capacity planning |
 
 ---
 
@@ -60,6 +61,7 @@ A major highlight of this library is the **Dynamic Value Correlation** engine ([
 | AI Assistant | Integration Method |
 | :--- | :--- |
 | **Claude Code** | Native Plugin or `CLAUDE.md` context referencing |
+| **Qwen Code** | Native Skill (`/perf`) or `QWEN.md` context referencing |
 | **Windsurf (Cascade)** | Local Skill configuration |
 | **Cursor** | Custom rules `.cursor/rules/` or index via `@Docs` |
 | **Cline / Roo Code** | Workspace instructions / custom rules |
@@ -92,6 +94,24 @@ To update to the latest version:
 
 ---
 
+### Qwen Code Skill
+
+Install as a user-level skill so `/perf` is available in every project:
+```bash
+qwen skills add QAInsights/perf-skills
+```
+
+Or for a single project, copy the skill directory and reference it in `QWEN.md`:
+```bash
+cp -r perf-skills/skills/perf ./perf
+```
+```markdown
+<!-- QWEN.md -->
+For performance testing questions, read `perf/SKILL.md` for routing, then load the relevant reference files from `perf/references/`.
+```
+
+---
+
 ### Install as local Skills (npx)
 
 If you are using a tool that supports `npx skills`, add it directly:
@@ -191,7 +211,7 @@ perf-skills/
             │   ├── k6.md                 # k6 JS/TS scripting, thresholds, VU options
             │   ├── gatling.md            # Gatling Scala/Java DSL & feeders
             │   ├── locust.md             # Locust Python scripting & FastHttpUser
-│   ├── artillery.md          # Artillery YAML/JS/TS scripting, phases, ensure SLOs, cloud
+            │   ├── artillery.md          # Artillery YAML/JS/TS scripting, phases, ensure SLOs, cloud
             │   ├── neoload.md            # NeoLoad GUI configs & API execution
             │   ├── loadrunner.md         # LoadRunner VuGen C scripting
             │   └── octoperf.md           # OctoPerf JMeter-based cloud execution

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "perf-skills",
-  "version": "3.0.0",
-  "description": "Expert AI skill for performance testing - covers JMeter, k6, Gatling, Locust, NeoLoad, LoadRunner, OctoPerf across the full lifecycle",
+  "version": "4.0.0",
+  "description": "Expert AI skill for performance testing - covers JMeter, k6, Gatling, Locust, Artillery, NeoLoad, LoadRunner, OctoPerf, LLM inference benchmarking, and SLO/capacity planning across the full lifecycle",
   "main": "skills/perf/SKILL.md",
   "files": [
     "skills/",
@@ -14,6 +14,7 @@
     "k6",
     "gatling",
     "locust",
+    "artillery",
     "neoload",
     "loadrunner",
     "octoperf",
@@ -24,6 +25,10 @@
     "websocket",
     "observability",
     "ci-cd",
+    "llm-inference",
+    "vllm",
+    "slo",
+    "capacity-planning",
     "claude-skills",
     "ai-assistant"
   ],

package/skills/perf/SKILL.md

@@ -93,12 +93,12 @@ Use this to recommend the right tool when the user hasn't decided yet.
 
 | Criteria             | JMeter              | k6                    | Gatling              | Locust         | Artillery        | NeoLoad          | LoadRunner              | OctoPerf              |
 |----------------------|---------------------|-----------------------|----------------------|----------------|------------------|-------------------------|-----------------------|
-| **Language**         | GUI/XML + Groovy    | JavaScript/TypeScript | Scala/Java           | Python         | GUI + NeoLoad DSL| VuGen C-like            | Web UI (JMeter-based) |
-| **Open source**      | ✅                  | ✅                    | ✅                   | ✅             | ❌               | ❌                      | ❌ (SaaS)             |
-| **Protocol support** | HTTP, JDBC, JMS, MQTT, FTP, gRPC | HTTP, gRPC, WS | HTTP, JMS, gRPC | HTTP, gRPC | HTTP, gRPC, WS, SAP | HTTP, Citrix, SAP, Flex | HTTP (JMeter-backed) |
-| **Developer-friendly** | Medium            | High                  | High                 | High           | Low              | Low                     | Medium                |
-| **Enterprise support** | Community + BlazeMeter | Grafana Cloud    | Gatling Enterprise   | Limited        | Artillery Cloud | ✅               | ✅                      | ✅                    |
-| **CI/CD integration** | Good (Maven/Gradle) | Excellent            | Excellent            | Good           | Good             | Moderate                | Good                  |
+| **Language**         | GUI/XML + Groovy    | JavaScript/TypeScript | Scala/Java           | Python         | YAML / JS / TS   | GUI + NeoLoad DSL       | VuGen C-like          | Web UI (JMeter-based) |
+| **Open source**      | ✅                  | ✅                    | ✅                   | ✅             | ✅ (core)        | ❌                      | ❌                    | ❌ (SaaS)             |
+| **Protocol support** | HTTP, JDBC, JMS, MQTT, FTP, gRPC | HTTP, gRPC, WS | HTTP, JMS, gRPC | HTTP, gRPC | HTTP, gRPC, WS, Socket.IO | HTTP, SAP, Citrix, Flex | HTTP, SAP, Citrix, many | HTTP (JMeter-backed) |
+| **Developer-friendly** | Medium            | High                  | High                 | High           | Medium           | Low                     | Low                   | Medium                |
+| **Enterprise support** | Community + BlazeMeter | Grafana Cloud    | Gatling Enterprise   | Limited        | Artillery Cloud  | ✅                      | ✅                    | ✅                    |
+| **CI/CD integration** | Good (Maven/Gradle) | Excellent            | Excellent            | Good           | Good             | Moderate                | Good                  | Good                  |
 | **Cloud execution**  | BlazeMeter, OctoPerf | Grafana Cloud        | Gatling Enterprise   | Self-managed   | Artillery Cloud (Lambda/Fargate) | NeoLoad Cloud    | AWS/on-prem             | OctoPerf Cloud        |
 | **Best for**         | Legacy systems, JDBC, protocols | Modern APIs, TypeScript devs | High-throughput HTTP | Python teams, flexible | Node teams, YAML tests, cloud scale | SAP/Citrix enterprise | Mainframe, legacy enterprise | JMeter teams needing cloud UI |
 
@@ -223,13 +223,13 @@ the specific mapping rather than a generic explanation.
 | User entrypoint  | Thread Group            | `default()` function    | `scenario()`             | task methods             | `flow` in scenario       | `Action()`          |
 | Concurrency ctrl | Thread Group settings   | executor                | `inject()`               | `spawn_rate`             | `maxVusers` / `arrivalRate` | Vuser Group         |
 | Think time       | Constant/Uniform Timer  | `sleep()`               | `pause()`                | `time.sleep()`           | `think`                  | `lr_think_time()`   |
-| Inline assertion | Response Assertion      | `check()`               | `.check()`               | `catch_response`         | `lr_eval_string()`  |
+| Inline assertion | Response Assertion      | `check()`               | `.check()`               | `catch_response`         | `afterResponse` hooks    | `lr_eval_string()`  |
 | SLA enforcement  | Duration Assertion      | `thresholds`            | Assertions (Enterprise)  | custom + exit code       | `ensure` plugin          | SLA definition      |
 | Correlation      | Regex / CSS Extractor   | `res.json()` / regex    | `.check()` + `saveAs()`  | `response.text` + regex  | `capture` (json/xpath/regexp/header) | `web_reg_save_param`|
 | Data feed        | CSV Data Set Config     | `SharedArray`           | `feeder`                 | CSV reader               | `payload` / `variables`  | `lr_paramarr()`     |
 | Grouping         | Transaction Controller  | `group()`               | `group()`                | task sets                | `name` on scenario       | Transaction         |
-| Distributed      | Controller + Agents     | k6 cloud / k6 operator  | Gatling Enterprise       | master + workers         | Load Generator      |
-| Results output   | .jtl (CSV/XML)          | JSON / InfluxDB / cloud | simulation.log           | CSV / Locust web UI      | .lrr file           |
+| Distributed      | Controller + Agents     | k6 cloud / k6 operator  | Gatling Enterprise       | master + workers         | Lambda / Fargate workers | Load Generator      |
+| Results output   | .jtl (CSV/XML)          | JSON / InfluxDB / cloud | simulation.log           | CSV / Locust web UI      | JSON / HTML report       | .lrr file           |
 
 ---
 
@@ -344,4 +344,4 @@ prescribing a solution:
 - Where will tests **run from** (local, CI, cloud)?
 - What **environment** is being tested (dev, staging, prod)?
 - Is there an **APM tool** in place (Datadog, Dynatrace, Grafana,
-  New Relic)??)??
+  New Relic)?

package/skills/perf/evals/evals.json

@@ -144,6 +144,86 @@
           "text": "Notes that values are baselines and should be adjusted to actual SLA requirements"
         }
       ]
+    },
+    {
+      "id": 8,
+      "prompt": "My Artillery test reports great metrics but my CI pipeline always passes even when p95 latency is 5 seconds. How do I make the test fail in CI?",
+      "expected_output": "Identifies missing ensure block as the cause. Without ensure, Artillery always exits 0. Provides an ensure.thresholds example with p95 and error rate conditions.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "ensure-block-cause",
+          "text": "Identifies that without an ensure block, Artillery always exits 0 regardless of metrics"
+        },
+        {
+          "id": "ensure-example",
+          "text": "Provides a concrete ensure.thresholds or ensure.conditions YAML example"
+        },
+        {
+          "id": "exit-code",
+          "text": "Explains that ensure causes a non-zero exit code when thresholds are breached, enabling CI gating"
+        }
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "I set arrivalRate to 100 in Artillery expecting 100 concurrent users, but my backend is getting overwhelmed with way more than 100 simultaneous requests. What's happening?",
+      "expected_output": "Explains that arrivalRate is new users per second (open model), not concurrency. On a slow backend, VUs pile up unbounded. Recommends maxVusers to cap concurrency or arrivalCount for a fixed total.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "open-model-explanation",
+          "text": "Explains that arrivalRate means new users per second (open model), not concurrent users"
+        },
+        {
+          "id": "pileup-risk",
+          "text": "Explains that on a slow backend, pending VUs accumulate unboundedly"
+        },
+        {
+          "id": "maxvusers-fix",
+          "text": "Recommends maxVusers to cap real concurrency, or arrivalCount for a fixed total number of users"
+        }
+      ]
+    },
+    {
+      "id": 10,
+      "prompt": "We're benchmarking our vLLM endpoint for a chat application. What metrics should we measure and what tools should we use?",
+      "expected_output": "Recommends TTFT, TPOT/ITL, tokens per second, and goodput as key metrics. Suggests vLLM bench, GenAI-Perf, GuideLLM, or llmperf as benchmarking tools. Distinguishes streaming vs non-streaming measurement.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "ttft-tpot-metrics",
+          "text": "Names TTFT (time to first token) and TPOT or ITL (inter-token latency) as key streaming metrics"
+        },
+        {
+          "id": "benchmarking-tools",
+          "text": "Recommends at least one specific LLM benchmarking tool such as vLLM bench, GenAI-Perf, GuideLLM, or llmperf"
+        },
+        {
+          "id": "goodput-or-throughput",
+          "text": "Mentions goodput or tokens per second as a throughput metric distinct from raw request latency"
+        }
+      ]
+    },
+    {
+      "id": 11,
+      "prompt": "How do I set up SLO-based CI gating for my k6 load tests? I want the build to fail if we burn more than 2% of our error budget.",
+      "expected_output": "Explains error budget concept (100% - SLO target). Shows how to translate an error budget into k6 thresholds. Recommends tracking burn rate over the test window.",
+      "files": [],
+      "assertions": [
+        {
+          "id": "error-budget-concept",
+          "text": "Explains error budget as 100% minus the SLO target (e.g., 99.9% SLO = 0.1% budget)"
+        },
+        {
+          "id": "k6-threshold-mapping",
+          "text": "Shows how to express the error budget as concrete k6 thresholds"
+        },
+        {
+          "id": "burn-rate",
+          "text": "Mentions burn rate or multi-window alerting as a way to avoid false positives from short test runs"
+        }
+      ]
     }
   ]
 }

package/skills/perf/evals/trigger-eval.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "perf",
+  "description": "Queries that SHOULD trigger the perf skill",
+  "trigger": [
+    "Help me write a k6 load test for our REST API",
+    "My JMeter test crashes with OutOfMemoryError in CI",
+    "What tool should I use for load testing a gRPC service?",
+    "How do I correlate JSESSIONID in JMeter?",
+    "Set up a distributed Locust run in GitLab CI",
+    "Our p95 latency spikes during database writes",
+    "What TTFT can our vLLM endpoint sustain at 200 concurrent users?",
+    "How many replicas do we need for our SLO?",
+    "Write an Artillery test with ensure thresholds for our checkout API",
+    "Compare k6 vs Gatling for high-throughput HTTP testing",
+    "My Locust test shows zero failures but the server logs have 500 errors",
+    "How do I parameterize test data in Gatling?",
+    "Set up k6 thresholds for CI gating in GitHub Actions",
+    "What is a good p95 target for a payment endpoint?",
+    "Help me design a soak test to find memory leaks",
+    "How do I benchmark tokens per second on our LLM inference server?",
+    "My Artillery arrivalRate is overwhelming the backend",
+    "Explain Little's Law and how it applies to load testing",
+    "How do I test WebSocket performance?",
+    "Set up error budget alerts for our 99.9% SLO"
+  ],
+  "no_trigger": [
+    "Help me write a unit test for my Python function",
+    "What is the difference between SQL and NoSQL databases?",
+    "How do I set up a React component?",
+    "Explain how Docker containers work",
+    "Write a REST API endpoint in Express.js",
+    "How do I configure ESLint for my project?",
+    "What is the best way to learn machine learning?",
+    "Help me debug a CSS layout issue",
+    "How do I set up a Kubernetes cluster?",
+    "Write a GitHub Actions workflow for deploying my app"
+  ]
+}

package/skills/perf/references/tools/loadrunner.md

@@ -112,5 +112,29 @@ web_add_header("Authorization", "Bearer {AuthToken}");
 - Use **Correlation graphs** to overlay server metrics (CPU, memory) from SiteScope/Diagnostics.
 - Export to Excel or integrate with LoadRunner Cloud for trend analysis across runs.
 
+---
+
+## LoadRunner-Specific Tips
+
+- **Register correlations before the request** - `web_reg_save_param_regexp` must appear
+  *before* the `web_url`/`web_submit_form` that returns the dynamic value. Placing it after
+  silently captures nothing.
+- **Use `lr_eval_string()` for debugging** - log parameter values during replay
+  (`lr_log_message("Token={AuthToken}")`) to verify correlation is working before scaling VUs.
+- **Avoid `lr_think_time(0)` in Action** - zero think time generates maximum RPS per VU,
+  which never reflects real user behavior. Use `lr_think_time(3)` or `lr_user_think_time()`
+  with a runtime distribution.
+- **Parameterize with data tables, not hardcoded values** - use `lr_paramarr_idx()` or
+  Parameter List in VuGen to feed unique credentials per VU. Hardcoded users cause
+  session collisions and cache-hot results.
+- **Set JVM heap for Load Generators** - default LG memory is often too low for 500+ VUs.
+  Increase via `mdrv -heap_size` or the LG configuration panel.
+- **Use Goal-Oriented scenarios for capacity tests** - instead of guessing VU counts,
+  let Controller auto-adjust to hit a target RPS or response time. This finds the
+  saturation point without manual iteration.
+- **Disable extended logging in CI** - `lr_set_debug_message` and extended logs add
+  20-40% overhead. Use standard logging or disable entirely for large runs.
+
 > For anti-patterns, assertions, think time, and parameterization principles, see **Key Principles** in `SKILL.md`.
 > For CI/CD integration details, see `../topics/test-execution.md`.
+> For correlation strategies across tools, see `../topics/correlation.md`.

package/skills/perf/references/tools/neoload.md

@@ -57,5 +57,59 @@ curl -X POST "https://neoload-api.tricentis.com/v3/tests/{testId}/start" \
 - Integrate with **Dynatrace/AppDynamics** via built-in APM connectors.
 - Use **as-code YAML definitions** (NeoLoad as Code) for version-controlled test configs.
 
+---
+
+## NeoLoad as Code (YAML)
+
+Version-control your test definitions instead of relying on the GUI `.nlp` file:
+
+```yaml
+# neoload-project.yml
+name: Checkout-Load-Test
+ populations:
+  - name: Checkout_Users
+    user_paths:
+      - name: Checkout_Flow
+        distribution: 70%
+      - name: Browse_Flow
+        distribution: 30%
+
+scenarios:
+  - name: Regression_Load
+    populations:
+      - name: Checkout_Users
+        load_policy:
+          steps:
+            - type: ramp
+              from: 0
+              to: 200
+              duration: 120s
+            - type: constant
+              value: 200
+              duration: 600s
+            - type: ramp
+              from: 200
+              to: 0
+              duration: 60s
+
+sla_profiles:
+  - name: Checkout_SLA
+    thresholds:
+      - per_transaction: Checkout
+        avg_response_time:
+          warn: 500ms
+          fail: 1000ms
+        error_rate:
+          warn: 1%
+          fail: 5%
+```
+
+```bash
+# Validate and run from CLI
+neoload-cli validate neoload-project.yml
+neoload-cli run --scenario Regression_Load
+```
+
 > For anti-patterns, assertions, think time, and parameterization principles, see **Key Principles** in `SKILL.md`.
 > For CI/CD integration details, see `../topics/test-execution.md`.
+> For SLO threshold design, see `../topics/slo-capacity.md`.

package/skills/perf/references/topics/correlation.md

@@ -404,3 +404,7 @@ If you need help configuring correlation, copy and paste the following prompt te
 3. Write the exact extraction syntax for the target tool.
 4. Show the exact injection syntax (including variable syntax, e.g., `${varName}`, `#{varName}`, `{varName}`).
 5. Explain how to debug and verify that the correlation succeeded.
+
+---
+
+> **See also:** Tool-specific extractor syntax in `../tools/jmeter.md`, `../tools/k6.md`, `../tools/gatling.md`, `../tools/locust.md`, `../tools/loadrunner.md`, `../tools/artillery.md`. Script-level correlation patterns in `script-generation.md`.

package/skills/perf/references/topics/database-testing.md

@@ -212,3 +212,5 @@ WHERE NOT bl.granted;
 - [ ] Replication lag monitoring active (if using read replicas)
 - [ ] Connection pool metrics exposed and dashboarded
 - [ ] Cleanup script ready for test data removal post-test
+
+> **See also:** JDBC sampler setup in `../tools/jmeter.md`. Monitoring and dashboards in `observability.md`. Interpreting saturation and bottleneck signals in `results-analysis.md`.

package/skills/perf/references/topics/llm-inference.md

@@ -87,6 +87,54 @@ Purpose-built LLM benchmarkers surface token metrics natively. Prefer them over
 
 ---
 
+## Quick Start Commands
+
+```bash
+# vLLM bench serve - max throughput probe with ShareGPT data
+python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3-8B &
+python -m vllm bench serve \
+  --model meta-llama/Llama-3-8B \
+  --endpoint http://localhost:8000/v1/completions \
+  --dataset-name sharegpt \
+  --request-rate inf \
+  --max-concurrency 256 \
+  --num-prompts 500
+
+# vLLM bench serve - realistic arrival pattern
+python -m vllm bench serve \
+  --model meta-llama/Llama-3-8B \
+  --endpoint http://localhost:8000/v1/completions \
+  --dataset-name sharegpt \
+  --request-rate 10 \
+  --burstiness 1.0 \
+  --num-prompts 200
+
+# GuideLLM - production SLA study
+pip install guidedllm
+guidedllm evaluate \
+  --model meta-llama/Llama-3-8B \
+  --base-url http://localhost:8000/v1 \
+  --data emulated --rate 10 --duration 120
+
+# NVIDIA GenAI-Perf - multi-backend benchmark
+genai-perf profile \
+  --model meta-llama/Llama-3-8B \
+  --endpoint-type chat \
+  --url localhost:8000 \
+  --concurrency 64 \
+  --request-count 200
+
+# llmperf - quick latency/throughput check
+python token_benchmark_ray.py \
+  --model meta-llama/Llama-3-8B \
+  --mean-input-tokens 512 \
+  --mean-output-tokens 128 \
+  --num-concurrent-requests 32 \
+  --results-dir ./results
+```
+
+---
+
 ## Test Design & Methodology
 
 1. **Start from real traffic shapes.** Use ShareGPT or captured production traces for prompt/output length distributions. Synthetic `random` datasets are fine for stress but unrealistic for sizing.

package/skills/perf/references/topics/modern-architectures.md

@@ -312,3 +312,5 @@ Define performance budgets in CI to prevent regressions:
 - [ ] Concurrency limits and provisioned concurrency validated
 - [ ] Frontend Core Web Vitals measured under backend load
 - [ ] Performance budgets defined and enforced in CI
+
+> **See also:** CI/CD pipeline patterns in `test-execution.md`. Kubernetes and mesh monitoring in `observability.md`. SLO headroom for autoscaling decisions in `slo-capacity.md`.

package/skills/perf/references/topics/observability.md

@@ -199,3 +199,5 @@ Synthetic monitors catch regressions that slip through staging without requiring
 - [ ] Log aggregation active and searchable
 - [ ] Baseline metrics screenshot taken before test starts (for comparison)
 - [ ] Metrics retention configured to keep results for trend analysis
+
+> **See also:** k6 metric primitives in `../tools/k6.md`. JMeter Backend Listener in `../tools/jmeter.md`. Interpreting the metrics in `results-analysis.md`. SLO thresholds in `slo-capacity.md`.

package/skills/perf/references/topics/production-testing.md

@@ -212,3 +212,5 @@ If something breaks during a test:
 4. **Roll back if needed** - restore previous version, restart services.
 5. **Preserve evidence** - don't restart services without capturing logs and heap dumps.
 6. **Post-mortem** - document what broke, at what load, what the root cause was.
+
+> **See also:** CI/CD execution patterns in `test-execution.md`. Monitoring during production tests in `observability.md`. SLO and error budget framing in `slo-capacity.md`.

package/skills/perf/references/topics/protocol-testing.md

@@ -58,6 +58,36 @@ export default function () {
 - **Connection reuse**: Keep connections open across iterations; don't connect/close per request.
 - **Streaming throughput**: For server-streaming RPCs, measure messages-per-second, not just request latency.
 - **Deadline propagation**: Set gRPC deadlines in tests to match production timeouts.
+
+### Gatling gRPC Example
+
+```scala
+// Requires: gatling-grpc plugin (io.gatling:gatling-grpc)
+import io.gatling.core.Predef._
+import io.gatling.grpc.Predef._
+import io.grpc.ManagedChannelBuilder
+import scala.concurrent.duration._
+
+class GrpcSimulation extends Simulation {
+  val channel = ManagedChannelBuilder
+    .forAddress("grpc-server", 50051)
+    .usePlaintext()
+    .build()
+
+  val scn = scenario("gRPC Unary")
+    .exec(
+      grpc("SayHello")
+        .rpc(HelloServiceGrpc.METHOD_SAY_HELLO)
+        .payload(HelloRequest(greeting = "perf-test"))
+        .check(statusCode.is(StatusCode.OK))
+    )
+    .pause(1)
+
+  setUp(
+    scn.injectOpen(rampUsers(100).during(30.seconds))
+  ).protocols(grpc(channel))
+}
+```
 - **Load balancer awareness**: gRPC over HTTP/2 with persistent connections can cause uneven load across backends - test with client-side load balancing or L7 proxy.
 - **Protobuf payload size**: Binary encoding is smaller than JSON - adjust throughput expectations accordingly.
 
@@ -199,6 +229,39 @@ export default function () {
 3. **Measure server-side**: File descriptor count, memory per connection, event loop lag.
 4. **Test reconnection storms**: Kill server, observe client reconnection behavior and server recovery.
 
+### Gatling WebSocket Example
+
+```scala
+import io.gatling.core.Predef._
+import io.gatling.http.Predef._
+import scala.concurrent.duration._
+
+class WebSocketSimulation extends Simulation {
+  val httpProtocol = http.baseUrl("https://app.example.com")
+
+  val scn = scenario("WebSocket Chat")
+    .exec(
+      ws("Connect WS")
+        .connect("/ws/chat")
+        .header("Authorization", "Bearer #{token}")
+    )
+    .exec(
+      ws("Subscribe")
+        .sendText("""{"type":"subscribe","channel":"updates"}""")
+        .await(30.seconds)(
+          ws.checkTextMessage("subscribed")
+            .check(bodyJsonPath("$.type").is("subscribed"))
+        )
+    )
+    .pause(30)  // hold connection open
+    .exec(ws("Close").close)
+
+  setUp(
+    scn.injectOpen(rampUsers(500).during(60.seconds))
+  ).protocols(httpProtocol)
+}
+```
+
 ---
 
 ## Message Queue / Event Streaming Testing
@@ -272,3 +335,5 @@ export function teardown() {
 - [ ] Backpressure / flow control behavior validated
 - [ ] Error codes and retry behavior tested (gRPC status codes, AMQP nacks, etc.)
 - [ ] End-to-end latency measured (not just request latency)
+
+> **See also:** k6 scripting (all examples above) in `../tools/k6.md`. Gatling gRPC/WebSocket in `../tools/gatling.md`. JMeter JMS/plugins in `../tools/jmeter.md`. Workload design for streaming protocols in `workload-design.md`.

package/skills/perf/references/topics/results-analysis.md

@@ -242,3 +242,5 @@ Structure your report:
    - Error log samples
    - Environment configuration
 ```
+
+> **See also:** Metric collection and dashboards in `observability.md`. SLO interpretation and error budgets in `slo-capacity.md`. LLM-specific metrics (TTFT, TPOT, goodput) in `llm-inference.md`.

package/skills/perf/references/topics/script-generation.md

@@ -39,26 +39,17 @@ Record a HAR file from the browser → import into your tool → clean up and pa
 
 ---
 
-## Correlation Deep Dive
+## Correlation
 
 Correlation is extracting a dynamic value from a response and using it in a subsequent request. Missing correlation is the #1 cause of performance script failure.
 
-### Values that always need correlation
-- **Session tokens** (JSESSIONID, ASP.NET_SessionId)
-- **Auth tokens** (JWT, OAuth access_token, refresh_token)
-- **CSRF tokens** (`_token`, `authenticity_token`, `__RequestVerificationToken`)
-- **View state** (ASP.NET `__VIEWSTATE`, `__EVENTVALIDATION`)
-- **Resource IDs** (created order ID, cart ID, uploaded file ID)
-- **One-time codes** (OTP, nonce, challenge)
-- **Timestamps/signatures** used in request signing
-
-### Correlation debugging approach
-1. Run the script with 1 VU.
-2. Look for HTTP 4xx errors (especially 403 Forbidden, 422 Unprocessable Entity).
-3. Check the request body/headers - is a token missing or stale?
-4. Use the tool's debug output or proxy (Fiddler, Charles) to inspect live traffic.
-5. Identify where the value appears in a *previous* response.
-6. Add an extractor at that response, reference the variable in the failing request.
+> **Full reference:** see `correlation.md` for the complete correlation workflow, tool-specific extractor syntax, tech-stack rules (ASP.NET, Java, SAP, OAuth), brittle-vs-robust regex guidance, and the diagnostic playbook.
+
+### Quick checklist
+- Session tokens, CSRF tokens, OAuth codes, resource IDs, and one-time nonces must always be correlated.
+- Run with 1 VU first; 403/422 errors usually mean a missing or stale token.
+- Use a proxy (Fiddler, Charles, mitmproxy) to find where the value appears in a previous response.
+- Add the extractor at that response, reference the variable in the failing request.
 
 ---
 
@@ -219,3 +210,5 @@ Treat performance scripts as production code:
 - [ ] Single VU smoke test passes cleanly
 - [ ] Script loads test data from external source (CSV, API)
 - [ ] Environment-specific values in config/env vars
+
+> **See also:** Full correlation reference in `correlation.md`. Parameterization and data feeds in `test-data.md`. Tool-specific syntax in `../tools/k6.md`, `../tools/jmeter.md`, `../tools/gatling.md`, `../tools/locust.md`.

package/skills/perf/references/topics/test-data.md

@@ -194,3 +194,5 @@ const user = users[__VU - 1];  // VU 1 gets row 0, VU 2 gets row 1, etc.
 - [ ] CSV files available on all injector nodes (distributed tests)
 - [ ] Sensitive data masked/anonymized (not using real PII in test data)
 - [ ] Date/time sensitive records accounted for (e.g., expiry dates set far in future)
+
+> **See also:** Tool-specific parameterization syntax in `../tools/k6.md` (SharedArray), `../tools/jmeter.md` (CSV Data Set Config), `../tools/gatling.md` (feeders), `../tools/locust.md`. Distributing data to injectors in `test-execution.md`.

package/skills/perf/references/topics/test-execution.md

@@ -114,12 +114,37 @@ bzt tests/load-test.jmx \
 ```
 
 ### AWS (DIY Cloud Execution)
-```bash
-# Spin up EC2 injectors via Terraform, then run JMeter/k6
-# Use Auto Scaling Groups for burst capacity
-# Use S3 to store results, CloudWatch for metrics
 
-# Cost optimization: use Spot instances for injectors (price vs reliability tradeoff)
+```bash
+# 1. Launch injectors with AWS CLI (or Terraform)
+aws ec2 run-instances \
+  --image-id ami-0abcdef1234567890 \
+  --instance-type c5.2xlarge \
+  --count 4 \
+  --spot-price "0.15" \
+  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=load-injector}]'
+
+# 2. Install k6 on each injector (via user-data or SSM)
+aws ssm send-command \
+  --instance-ids i-0abc i-0def i-0ghi i-0jkl \
+  --document-name "AWS-RunShellScript" \
+  --parameters 'commands=["sudo apt-get install -y k6"]'
+
+# 3. Distribute the test script and run in parallel
+for ip in 10.0.1.{10..13}; do
+  scp script.js ec2-user@$ip:~/ && \
+  ssh ec2-user@$ip "k6 run --vus 250 --duration 10m script.js --out json=/tmp/results.json" &
+done
+wait
+
+# 4. Collect results to S3
+for ip in 10.0.1.{10..13}; do
+  scp ec2-user@$ip:/tmp/results.json ./results/$(echo $ip | tr '.' '-')-results.json
+done
+aws s3 cp ./results/ s3://my-load-test-bucket/runs/$(date +%Y%m%d)/ --recursive
+
+# Cost optimization: use Spot instances for injectors (60-90% cheaper).
+# Handle interruptions with a 2-min warning hook that flushes partial results.
 ```
 
 ---
@@ -279,3 +304,5 @@ Always monitor the injector resources alongside the SUT:
 - [ ] Smoke test (1 VU) passed before full run
 - [ ] Team notified of test window
 - [ ] Rollback plan in place (especially for production testing)
+
+> **See also:** Tool-specific CLI and distributed setup in `../tools/jmeter.md`, `../tools/k6.md`, `../tools/locust.md`, `../tools/gatling.md`, `../tools/artillery.md`. Monitoring during execution in `observability.md`. Production safety controls in `production-testing.md`.