pressure-testing

Run standardized VisionFlow pressure tests to determine concurrency capacity and platform stability.

Updated May 11, 2026
One-click install
npx skills add https://github.com/IsKenKenYa/Commory --skill pressure-testing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pressure-testing
Source: https://github.com/IsKenKenYa/Commory/tree/main/.agents/skills/pressure-testing
Command: npx skills add https://github.com/IsKenKenYa/Commory --skill pressure-testing

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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.

Frequently Asked Questions about pressure-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a standardized load test for Docker Compose and PostgreSQL concurrency capacity?

Standardized load testing applies a unified capacity profile via `--apply-config` to validate concurrency capacity across Docker Compose, PostgreSQL, and PgBouncer, producing a report distinguishing platform failures from upstream blockers.

What is the best way to stress test Redis BullMQ workflow stability under high concurrency?

Workflow stress testing uses a dedicated harness to validate multi-user workflow execution, cloning, and node routes while enforcing a 20-minute execution policy and stop-on-fail behavior to ensure platform stability under heavy load.

Can I use this pressure testing approach for batch generation endpoints and API mocking?

Yes, the tietiezhi batch harness targets `/api/generate/batch` by validating the submit-plane, Redis/BullMQ, DB, and PgBouncer components while mocking upstream services to isolate platform-specific capacity limits.

How do I determine the recommended production concurrency ceiling from a capacity report?

Capacity reports identify the highest stable concurrency stage during the test matrix and calculate the recommended production ceiling, typically set at 60%-70% of that maximum stable stage to ensure safe platform operation.

Does the load testing harness enforce safety limits to prevent infrastructure damage?

Yes, the pressure testing harness enforces precheck reachability, scoped OSS cleanup, a fixed 20-minute execution policy, and stop-on-fail behavior to prevent uncontrolled infrastructure strain during high-load validation.

Where are concurrency performance logs and capacity testing artifacts stored?

Capacity testing artifacts are generated in the standard `logs/测试服并发性能日志/<runId>/` directory locations, capturing the full concurrency matrix results and stability reports for each specific test run.