Engarde DDoS - Basic Training

Learn DDoS and stress testing fundamentals, platform navigation, and how to run your first controlled simulation.

DDoS and stress testing fundamentals

This module starts by clarifying the difference between the two approaches: stress testing measures system behavior under heavy but expected user load, while DDoS simulation evaluates resilience under attack-like traffic in a controlled environment.

• Traffic intent: Stress testing focuses on capacity limits; DDoS simulation focuses on availability and defensive behavior.
• Success criteria: Not only generating volume, but tracking response time, error rate, and service continuity together.
• Safe execution: Run only on authorized targets, start at low intensity, and scale gradually.

Quick example: Run a stress test first to observe behavior under normal peak load, then run a DDoS simulation to see service continuity under defensive pressure. This helps separate capacity limitations from protection-layer behavior.

The rest of the training builds on this foundation to read metrics in the UI, run your first simulation, and interpret the resulting report.

Platform and metric reading

At basic level, your goal is to interpret dashboard metrics together, not in isolation. You should learn to evaluate how latency and error behavior changes while traffic volume increases in the same time window.

• RPS / request volume: Does generated traffic represent the expected load profile?
• Response time: Do average and peak values increase in a controlled way as load grows?
• Error rate: Does it stay stable or start increasing after a specific threshold?
• Service continuity: Are spikes temporary fluctuations or signs of sustained degradation?

Fast reading order: Check RPS trend first, then latency curve in the same time window, and finally error rate and status-code distribution. This sequence reduces false interpretations.

Running the first simulation

Treat your first run as a discovery baseline. The objective is not to push maximum traffic immediately, but to establish a safe reference point for later scaling.

1. Verify target authorization and test window.
2. Start with low intensity and short duration.
3. Monitor metrics live and stop safely if abnormal behavior appears.
4. Increase only one parameter in the next run to keep comparisons meaningful.

Starter profile: 1-2 minute run, low intensity, single target, and limited parameter set. After the first run, scale iteratively by changing only one variable (for example, intensity).

Basic report interpretation

When reviewing results, focus on trends rather than single values. For example, if RPS rises while error rate stays low, resilience may be acceptable; if latency jumps sharply, this may indicate capacity or protection bottlenecks.

• Start with run summary: duration, traffic volume, success/error distribution.
• Then inspect performance: latency curves and threshold breakpoints.
• End with action: define one clear change for the next run.

Common pitfall: Assuming overall improvement from one metric only. For example, lower average latency with rising error rate is not a real improvement; always evaluate metrics together.

Back to Training