Skip to content

Multi-region edge performance

A CDN’s entire value proposition is geographic proximity: users in Frankfurt should be served by a Frankfurt edge node, not one in Virginia. A load test from a single cloud region cannot validate this. If your Virginia-based test shows 15 ms TTFB, that tells you nothing about what a user in Sydney sees. Multi-region load tests from MaxoPerf generate traffic simultaneously from multiple geographic locations, so you measure edge latency as it is experienced in each region — and surface any routing or caching anomalies that only appear when traffic arrives from a particular geography.

  • Confirm your MaxoPerf workspace has access to at least two cloud load locations. Check the Locations dropdown in the Configuration tab of any test.
  • Run a smoke test from a single region first to validate the test file and confirm the CDN URL is reachable.
  • Review Cache hit/miss testing to understand how to assert on cache state — multi-region tests should include cache-header assertions so you can see if edge nodes in specific regions are serving from cache.

What to expect from per-region edge latency

Section titled “What to expect from per-region edge latency”

CDN edge latency depends on:

  • Geographic distance to the nearest edge node — a user 50 km from the edge sees < 5 ms RTT; one 5,000 km away may see 50–80 ms.
  • Cache state — a cache miss from any location adds origin RTT on top of edge RTT.
  • HTTP version — HTTP/2 and HTTP/3 connection reuse reduces per-request overhead for subsequent requests from the same VU.
  • Asset size — large assets (> 1 MB) show more variation in TTFB across regions due to bandwidth differences.

Typical healthy CDN TTFB by region pair (cached, small assets):

Region to edge distanceExpected TTFB
Same continent, major metro5–20 ms
Cross-continent (e.g. EU → North America)30–80 ms
Transcontinental (e.g. EU → Asia Pacific)60–150 ms

If your measured TTFB is significantly higher than these ranges, traffic is not being served from the nearest edge — investigate DNS routing or CDN PoP configuration.

  1. Upload a test file that targets your CDN URL. The test file does not need to specify locations — MaxoPerf injects location at the runner level, not at the scenario level.

    execution:
    - concurrency: 100
    ramp-up: 1m
    hold-for: 5m
    scenario: cdn-edge-test
    scenarios:
    cdn-edge-test:
    default-address: https://cdn.example.com
    requests:
    - label: js-bundle
    url: /static/app.js
    method: GET
    assert:
    - equals:
    subject: http-code
    value: '200'
    - label: hero-image
    url: /static/hero.webp
    method: GET
    assert:
    - equals:
    subject: http-code
    value: '200'
  2. Open the Configuration tab of the test. Under Locations, click Add location to add a second and third region.

    Common multi-region setups for CDN testing:

    • us-east-1 + eu-west-1 — transatlantic coverage
    • us-east-1 + ap-southeast-1 — Americas + Asia Pacific
    • eu-west-1 + ap-southeast-1 + us-east-1 — three-continent coverage

    Set the weight (percentage of total VUs) for each location. For a symmetric comparison, use equal weights. For testing a user-distribution that matches your real traffic, weight by region share.

  3. Save and run the test. The run will spin up runners in each region simultaneously. Open the run detail.

  1. Use the Locations filter in the run overview to view per-region metrics. Select one region at a time to see throughput and latency for that region in isolation.

  2. Compare p95 TTFB across regions. A difference greater than 20 % between regions warrants investigation. Check:

    • Whether both regions are resolving to geographically proximate edge nodes (use dig or nslookup from each region’s IP range).
    • Whether one region is generating more cache misses (higher Age: 0 rate, assertion failures on X-Cache: HIT).
    • Whether a specific region has consistently higher error rates, which may indicate a CDN PoP issue or firewall rule blocking that source IP range.
  3. Check the Runners tab to confirm runners from all regions are active and carrying proportional VU counts.

Sometimes a CDN serves a cache hit from one region but a miss from another. This can happen because:

  • Edge node isolation — each geographic PoP maintains an independent cache. An asset popular in Europe may be warm in Frankfurt but cold in Singapore.
  • DNS failover routing — if your CDN has routing rules, traffic from one region may be directed to a farther PoP than expected.
  • Shield configuration per region — if your CDN’s origin shield only covers some regions, non-shielded regions may see higher miss rates.

To detect this, include X-Cache header assertions in your test and use the MaxoPerf Log tab to see which regions are generating assertion failures:

scenarios:
cdn-edge-test:
requests:
- label: js-bundle
url: /static/app.js
method: GET
assert:
- contains:
subject: headers
value: 'HIT' # fails for cold-cache regions

Assertion failures filtered by runner location (visible in the Log tab) pinpoint which region is seeing cache misses.

Before drawing conclusions, confirm:

  • All expected regions appear in the Runners tab with Running status.
  • VU counts in the Runners tab are proportional to the configured weights.
  • The Locations filter in the Overview tab shows distinct per-region charts.
  • p95 latency values differ between regions by an amount consistent with geographic distance (intercontinental pairs should differ by at least 20–40 ms for a properly distributed CDN).

If two geographically distant regions show identical TTFB values, both may be resolving to the same CDN PoP — investigate DNS geo-routing.

Do:

  • Use equal VU weights when your goal is a fair per-region latency comparison.
  • Warm the cache from all regions before measuring steady-state edge performance.
  • Check the Runners tab to confirm all regions are active before the test ends.

Don’t:

  • Infer global CDN performance from a single-region test — it only tells you about that specific PoP.
  • Use multi-region tests to generate load against an origin without verifying origin capacity first — if the CDN is cold in multiple regions simultaneously, you are effectively running an origin load test.
  • Ignore inter-region latency differences below 10 ms for cached small assets — these are within normal PoP variation and do not require action.