performance-workload-modeling

Performance Workload Modeling (Chinese Version)

When to Use

You need to turn production traffic and business behavior into a reproducible performance test workload model.
You need to conduct a risk review of an existing plan, result, or evidence, and form actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow prompts/performance-workload-modeling.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First conduct an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained initial version, and state which conclusions cannot yet hold.

When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized inputs, item-by-item expectations, and recalculation basis.
Each execution must read prompts/performance-workload-modeling.md; it is the complete execution specification of this Skill.
When evaluating or regressing this Skill, read evals/eval.yaml and the matching evals/cases/ test cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Write each input as value, unit, time zone/window, source, and coverage: requests/transactions/sessions/users cannot be interchanged; convert from the transaction mix and requests per transaction, and note retries and background traffic.
Daily request volume can only recalculate the all-day average; peak requires the peak-hour traffic proportion and window width. If the window is missing, keep a conditional formula/range, and do not define the peak-hour length or peak multiplier yourself.
Clarify open arrival rate or closed concurrency; Little's Law can only be used as L=λW in a stable window with consistent units, and online users or daily active users cannot be directly treated as concurrency.
Provide candidate curves, session length/think time sources, and a validation plan; validate with measured arrival/completion volume and mix, and unconfirmed values cannot be used as production capacity conclusions.

Do not directly treat the number of online users as the concurrency number
Distinguish open and closed models
Use adjustable ranges when production data is missing
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide a verification method.
Priority must state the basis in terms of business impact, likelihood of occurrence, or detectability.

Covered: transaction model, arrival rate, concurrency, think time, peak burst, data distribution, cache warm-up, dependency constraints.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without stating input conditions, expected results, or evidence.
Marking everything as high priority, which eliminates the value of prioritization.
Replacing domain judgment with tool names or generic theory.
Rejecting outright when input is incomplete, or conversely pretending the conclusion is already certain.

Start with the paths most likely to cause business loss, security issues, or release blockers.
Reduce uncertainty with the smallest verifiable experiment, and record the conditions for reproduction.
Make the output directly executable and reviewable by another engineer.