Worked example: mixed traffic VarioTest

This example builds an e-commerce mix out of three single tests you already have, following the steps in Build a VarioTest. It ends with a variant pattern for comparing two API versions under the same composite load.

Problem: Real production traffic on a storefront is not one request pattern — it is browsing customers, checkout customers, and background jobs polling order status, all competing for the same database connections, caches, and thread pools at once. Testing each in isolation misses that interaction effect.

Test type: Load test — composite workload.

Prerequisites

• Three single tests, each already created and individually validated with a smoke test:
  • Catalogue browse — a browsing scenario.
  • Checkout — CRUD — an order-placement scenario.
  • Order status polling — background — a low-rate polling scenario.
• All three tests live in the same project.
• A MaxoPerf plan with the VarioTest entitlement.

Step 1 — size the mix

Decide the traffic split you want to model — for a typical storefront, browsing dominates, checkout is a smaller fraction, and background polling is smallest of all: roughly 60 : 30 : 10.

1. Open Catalogue browse → Configuration → set total virtual users to 600.
2. Open Checkout — CRUD → Configuration → set total virtual users to 300.
3. Open Order status polling — background → Configuration → set total virtual users to 100.
4. Save each configuration. Together these three totals (600 / 300 / 100 of 1000) express the 60 / 30 / 10 mix — VarioTest has no separate weight field, so the mix is set through each scenario’s own load profile, as covered in the scenario, weight, and variant model.

Step 2 — compose the VarioTest

1. Go to Tests and click New VarioTest.
2. Name it E-commerce — mixed workload and select the project containing the three tests above. Click Next.
3. In the Scenarios checklist, check Catalogue browse, then Checkout — CRUD, then Order status polling — background, in that order — the selection order becomes the run order. Click Review.
4. Confirm the ordered list and click Create VarioTest.

Step 3 — run and analyze

1. On the new VarioTest’s detail page, click Run VarioTest.
2. Open the run detail page once it starts. The Overview tab shows aggregate throughput and latency across all three scenarios.
3. Use the Scenario scope filter to isolate one scenario’s metrics — for example, filter to Checkout — CRUD alone to see whether its latency degrades once browsing and polling traffic share the same backend.
4. Clear the filter to return to the aggregate view.

Look for interference

If one scenario’s latency climbs during the run while its own VU count is flat, check whether another scenario is consuming a shared resource — database connections, caches, or thread pools. The side-by-side Scenario filter is what makes this interference visible; it is the main reason to run a composite test instead of three separate ones.

Verify

• All three constituent scenarios complete with status Finished (or Failed, if you set failure criteria and one breached).
• The relative traffic split roughly matches the 600 / 300 / 100 VU split you configured on each scenario.
• Aggregate p95 latency in the run overview is consistent with a weighted view across the three scenarios — a large divergence suggests one scenario is dominating or being starved.
• Each scenario’s individual metrics are reachable through the Scenario filter.

Variant pattern: A/B comparison

A variant VarioTest compares two versions of the same workload under identical conditions instead of modeling a traffic mix. Build it the same way, with two scenarios instead of three:

1. Create (or reuse) two single tests that run the same script against two different targets — for example, Checkout — API v1 and Checkout — API v2, both pointed at the same scenario file but with different endpoint configuration.
2. Give both the same total virtual users, ramp-up, and duration on their Configuration tabs — equal load profiles make the comparison fair.
3. Compose both into one VarioTest, in either order — order does not matter for a two-way variant comparison, only that both start together.
4. Run it. Use the Scenario filter to flip between Checkout — API v1 and Checkout — API v2 and compare their latency and error curves under identical concurrent conditions.

This directly answers “does the new implementation hold up under the same load as the old one?” — without the noise of running the two versions at different times or under different background conditions.

Where to go next

• Build a VarioTest — the full step-by-step composition guide.
• Runs — read results — the full results-reading guide, including the Metrics and Errors tabs.
• Tests & builders — performance, functional, and browser test builders that VarioTest composes.