Worked example: mixed traffic VarioTest

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

Problem: Production traffic on a storefront is not one request pattern. Browsing customers, checkout customers, and background jobs polling order status all compete for the same database connections, caches, and thread pools at once. Testing each one alone misses that interaction effect.

Test type: Load test, composite workload.

Prerequisites

• Three existing single tests, each validated on its own 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. On a typical storefront, browsing is the largest share, checkout is smaller, and background polling is the smallest: 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 each scenario’s own load profile sets the mix, as described 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 gets worse once browsing and polling traffic share the same backend.
4. Clear the filter to return to the aggregate view.

The composite run's Overview tab shows aggregate metrics by default. One filter shows any single scenario's own curves.

Look for interference

If one scenario’s latency climbs during the run while its own VU count is flat, check whether another scenario is using up a shared resource: database connections, caches, or thread pools. The Scenario filter shows this interference side by side. That 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 gap suggests that one scenario dominates or is starved.
• The Scenario filter shows each scenario’s own metrics.

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. Add both to one VarioTest, in either order. For a two-way variant comparison the order does not matter. Both only need to 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 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 guide.
• Runs: read results: the full guide to reading results, including the Metrics and Errors tabs.
• Tests & builders: performance, functional, and browser test builders that VarioTest composes.