performance-test-gatling

Performance Testing (Gatling) (Chinese Version)

English version: See the corresponding English skill.

When to Use

You need to land performance test results into the Gatling structure.
The project is already using Gatling, or you want the output to directly fit Gatling.

Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
Only supplement project context that truly affects the results: scope, environment, constraints, risks, dependencies, expected deliverables.
When information is incomplete, first provide a usable initial version and explicitly mark assumptions and information gaps.
Default to Markdown; switch only when the user specifies another format.

First read the project's Gatling/plugin/JDK and Java/Scala/Kotlin DSL versions, and follow the existing layout; choose the injection and assertion APIs of the same DSL, and do not mix them. Verify generated assets first with the project build's offline test-compile; if dependencies are not cached, mark BLOCKED rather than compiled successfully.
The open model controls the user arrival rate, and it corresponds one-to-one with the target RPS only when there is a single request per user and no additional loops/retries; the closed model controls concurrency, and RPS must be verified from the actual request count/time window.
Recalculate the feeder's total consumption count based on the number of feeds per user/per loop; queue exhaustion must be a visible failure, circular is used only when the project allows duplicate data, and identity/business keys must not conflict.
Thresholds come from the project and use a version-supported assertion API; when thresholds are missing, output an unconfigured skeleton rather than inserting custom 500ms/1% values; record evidence separately for compilation, load achievement, and SLO pass.

Prioritize by risk/business impact; do not spread effort evenly.
Write "confirmed facts" and "current assumptions" separately; when there is no SLA/no traffic, mark all numbers as "assumptions" and provide a list of items to confirm.
Do not fabricate interfaces, fields, environments, or root cause details not provided by the user; use only placeholders/environment variables for secrets, and never use real tokens.
Results must be actionable: scenarios specific, prioritized, and able to guide the next step.
By default, select only the 1-2 most critical types of performance scenarios; do not by default do all of baseline/load/stress/spike/stability.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md for the desensitized input, item-by-item expectations, and recalculation basis.
Before producing output, you must read and follow prompts/performance-test-gatling.md(minimum coverage checklist, output structure, quality requirements).
When you need to apply an existing template: read the matching template in output-templates/ , and do not invent a conflicting structure.
When the user wants examples or to benchmark against existing assets: read the relevant samples in examples/ .
When you need in-depth materials such as framework specifications, troubleshooting, or report schema: read only the files in references/ that are relevant to the current problem; do not read the entire directory.
When you need format conversion or auxiliary validation: prefer using the existing scripts in scripts/ rather than rewriting them.
When you need to evaluate/regress this skill: use evals/, and validate and run it with skill-up.

Followed the output structure of the main prompt
Minimum coverage concerns: target scenario, load model, data or feeder requirements, ramp-up method, thresholds, environment and monitoring, key bottlenecks, result reporting requirements... (details are subject to the main prompt)
Covered the minimum checklist, or indicated why items were omitted
High-risk items have clear priorities
Did not fabricate details the user did not provide
Assumptions and information gaps are indicated

When neither the scope nor the context is clear, do not pretend it is already fully usable.
Do not write all items as equally important.
Do not skip assumptions and information gaps.
Do not output large blocks of vague theory unrelated to the current toolchain.
When validating DSL/JMX assets and data consumption boundaries, read evals/fixtures/java-dsl/README.md; the examples are only for local calibration, and acceptance must not be declared when project thresholds are not provided.