This is the only step where you use Postman’s real Performance feature — configure a calm Fixed App run, skim the other knobs, then watch the live graph.
Run a Fixed App performance test
A virtual user (VU) loops your collection’s requests for the test duration; all VUs run in parallel. You’ll configure a Fixed + App run (steady load from your desktop), peek at the other knobs so they don’t feel mysterious later, then hit Run and watch the metrics stream in.
1. Open Performance for your collection
- Select Coffee API Load Test in the sidebar.
- Open the Collection Runner: ⋯ → Run, or Run on the collection tab bar.
- Switch to the Performance tab (not Functional).
2. Configure a calm first run
Use these settings so your laptop isn’t the bottleneck and the graph stays readable:
| Setting | Choose | Why |
|---|---|---|
| Run method | App | Load comes from this machine (desktop only; all plans) |
| Load profile | Fixed | Steady VU count — easiest shape to read |
| Virtual users | 10 | Enough to see activity; easy on resources |
| Duration | 1 minute | Long enough for the chart to mean something |
| Environment | Performance | Resolves {{baseUrl}} |
Leave everything else at the defaults for this run.
3. Before you click Run — know the rest of the cockpit
You don’t need these today. Spend 20 seconds spotting them so the screen feels smaller:
| Control | What it’s for |
|---|---|
| Load profile (Ramp up / Spike / Peak) | Different traffic shapes — ramp, spike, then settle. Fixed is the training wheels. |
| Setup / teardown | Other collections that run once before / after the load (seed data, login, cleanup). |
| Data file / dataset | Give each VU different inputs instead of the same payload every loop. |
| Pass test if | Fail the run when a metric (p95, error %, …) misses a bar — same idea as CLI --pass-if later. |
| Mocks | Point load at a mock when you want consumer traffic without hitting a fragile backend. |
| Cloud (run method) | Postman generates load in the cloud (paid plans) — bigger scale, not your Wi‑Fi. |
Full detail: performance test configuration.
4. Run — lean into the live graph
- Click Run.
- For the first few seconds, ignore the density. Find three lines or chips: average response time, error %, and throughput (requests/second). Those are the same families of signals you used in the load lab.
- If the UI lets you show P95 (or P90/P99) on the summary graph, turn it on — that’s the “tail” metric from earlier. Avg can look calm while p95 tells a harsher story.
- Glance at CPU / memory for the machine generating load. If your machine is pegged, the API might be fine and the load generator is the bottleneck.
- Let the minute finish (or stop early if errors explode — that usually means
{{baseUrl}}isn’t resolving; check the Performance environment).
How to read the wow without drowning
- Moving lines = the test is working. You’re watching concurrency in real time.
- This Sample API at 10 VU usually stays healthy — a flat, boring chart is a successful first flight.
- You’re training pattern recognition: “Where would I look if this were my launch API?” not “melt the coffee API.”
Expected outcome: A finished (or intentionally stopped) Fixed App performance run where you can point to avg, error %, throughput (and p95 if shown) on the live summary.