pressure-testing

What problem does it solve?

It removes guesswork from high-concurrency validation by standardizing how to run, precheck, measure, and report pressure tests across the repo’s Docker stack, messaging/queue components, and workflow/batch harnesses.

Core Features & Use Cases

• Pick the correct harness for the job: Use the repo’s tietiezhi batch harness for /api/generate/batch and its associated submit-plane, Redis/BullMQ/DB/PgBouncer, and upstream mocking; use the workflow harness for multi-user workflow execution, cloning, and node route validation.
• Run with guardrails and acceptance criteria: Apply a fixed 20-minute execution policy and unified capacity profile (--apply-config), enforce consistent time budgets across tracking components, and validate pass/fail based on platform vs infra/upstream blockers.
• Produce actionable capacity recommendations: Generate artifacts in the standard logs/测试服并发性能日志/<runId>/ locations and express results as the highest stable stage and a recommended production ceiling (typically 60%-70% of that stage).

Quick Start

Ask the agent to run the tietiezhi pressure test with the standard precheck, Docker compose stack, smoke stage, and then the main concurrency matrix using the repo-supported commands and report format.