# Performance Test Instructions

## Purpose
Validate that the master-controlled availability gate does not introduce meaningful request latency on the slave, per NFR-PERF-01/PERF-02 (`aidlc-docs/features/master-cms-module/construction/slave-availability-extension/nfr-requirements/nfr-requirements.md`).

## Performance Requirements
No explicit throughput/latency SLA was defined during NFR Requirements for this feature. The design goal instead is architectural:
- **PERF-01**: The slave's master-gate check reads a `volatile` static in-memory field — zero async overhead, zero DB call per request.
- **PERF-02**: Only the local availability gate touches the DB, unchanged from pre-existing behavior (1s cache per `AvailabilityOptions.StatusCacheSeconds`).

## Setup Performance Test Environment

### 1. Prepare Test Environment
```bash
dotnet run --project src/SlpModularCms.Api --urls http://localhost:5002 --environment Production
```

### 2. Configure Test Parameters
- **Test Duration**: 60 seconds
- **Virtual Users**: 50 concurrent
- **Target endpoint**: Any slave CMS route protected by `AvailabilityMiddleware`

## Run Performance Tests

### 1. Baseline (master-gate disabled / no `MasterRegistration` configured)
```bash
k6 run --vus 50 --duration 60s baseline-script.js
```

### 2. With Master-Gate Enabled (registered slave, `_masterIsAvailable = true`)
```bash
k6 run --vus 50 --duration 60s gated-script.js
```

### 3. Analyze Performance Results
- **Expected**: p95 latency delta between baseline and gated runs should be negligible (sub-millisecond), since the gate check is a single `volatile` field read with no I/O.
- **Bottlenecks**: If a measurable delta appears, verify no accidental DB or network call was introduced into `AvailabilityMiddleware`'s master-gate branch.

## Performance Optimization
Not applicable at this time — no bottleneck identified in code review or NFR design. Revisit only if production monitoring shows gate-related latency.