Load Testing

The template ships a k6 script at bin/load-test/launch.js. It tells you how many visitors your site can serve and how quickly. It also tells you whether those visitors got the page cache or a fresh server-side render (SSR), because the two differ by orders of magnitude.

It is a manual tool. It is not part of CI, on purpose. A load test sends real traffic and costs money on an autoscaled cluster, so someone should decide to run it.

Install k6

brew install k6                      # macOS
sudo apt-get install k6              # Debian/Ubuntu, after adding Grafana's apt repo

Or skip the install and use Docker. Pass the variables with -e and the script on stdin:

docker run --rm -i -e BASE_URL=https://staging.example.com -e CONFIRM=yes \
  grafana/k6 run - < bin/load-test/launch.js

See the k6 install guide for other platforms.

Run a test

# The local stack has a self-signed certificate. Local hosts need no confirmation.
BASE_URL=https://localhost INSECURE=true k6 run bin/load-test/launch.js

# Any other host needs CONFIRM=yes.
BASE_URL=https://staging.example.com CONFIRM=yes MODE=capacity k6 run bin/load-test/launch.js
BASE_URL=https://www.example.com CONFIRM=yes MODE=surge PEOPLE=300 k6 run bin/load-test/launch.js

Start with smoke. It checks the script, the target and the cache headers before you point real load at anything.

By default the pages come from /sitemap.xml, read the same way as the cache warm after a deploy. Set PAGES=/,/about to test specific paths instead.

Modes

Each visitor loads a page and its /_nuxt files, then reads for 2–6 seconds. Next it makes one client-side navigation, which in CWA is two /_api calls (the route and its resource manifest), not another server render. Then it reads for 3–9 seconds more.

Environment variables

Only BASE_URL is required.

Cached or rendered: CACHE

Page HTML and /_api responses are served by the Souin cache in front of Nuxt and php. A test that only hits the cache says nothing about SSR, and the reverse is true too. So choose what you are measuring:

• warm sends plain anonymous requests, as a visitor does. After the first request for each page, these should be cache hits. This is what your visitors get.
• cold adds a unique k6cb= value to each page request, so every one misses the cache and is rendered by Nuxt. This is the cost of SSR, and the worst case after a purge or a deploy.
• mixed makes COLD_RATIO of page loads cold and the rest warm.

The navigation's /_api calls stay cacheable unless you set COLD_API=true.

Flush the cache after a cold run

Every busted request is stored as its own cache entry. With the default in-memory store, those entries stay until they expire, the cache is flushed or the pod restarts. After a cold test against a real site, flush the cache from the API pod through Caddy's admin port:

kubectl exec -n <namespace> deploy/<release> -- \
  curl -s -X PURGE http://localhost:2019/souin-api/souin/flush

Caddy's admin API listens only inside the container, so run the request there. Locally, that's docker compose exec php curl -s -X PURGE http://localhost:2019/souin-api/souin/flush. The silverback:api-components:purge-http-cache command does the same flush. See Purging all cached data.

Reading the summary

The script replaces k6's default summary with this:

=== smoke against https://localhost (CACHE=cold) ===
Time to first byte
  Pages (HTML)         avg 116ms  med 83ms  p95 244ms  max 273ms
  API (/_api)          avg 19ms  med 1ms  p95 108ms  max 113ms
  Static (/_nuxt)      avg 6ms  med 6ms  p95 11ms  max 11ms
Souin cache
  Pages                0% hits  (hit 0, miss 6, bypass 0, no header 0)
  API                  83% hits  (hit 10, miss 2, bypass 0, no header 0)
  => page latency above is mostly SSR rendering (cache misses)
Totals
  ...

• Time to first byte is split into pages, API calls and static files. A cache hit, a render, an API call and a static file differ too much to average together. Read p95, not the average.
  • Pages measures the cache when hits are high, and Nuxt's SSR when they are low.
  • API is php behind Souin. Once warm, almost all of these are hits.
  • Static is Nuxt serving the build's /_nuxt files. Souin does not cache these.
• Souin cache counts each response's Cache-Status header.
  • hit was served from the cache.
  • miss was forwarded and stored.
  • bypass means Souin gave up, for example a render slower than its 10-second backend timeout.
  • no header means the request never went through the cache: an excluded path, a cookie, or no Souin in front.
• The => line tells you whether the page numbers measured the cache or SSR.
• Thresholds: page p95 under PAGE_P95_MS, 99% of pages returning 200, API and static p95 under 1 second, and under 1% failed requests. k6 exits non-zero if any of them fail.

Requests are tagged kind=page|api|asset, and pages also get cache_mode=warm|cold. The per-kind numbers are available in any k6 output, such as --out json=results.json.

Traps

Next steps

• Page caching: what a cached page carries and how long it is kept.
• Warming the cache after a deploy: run a warm test after it, so you measure what visitors get.
• Auditing performance after a deploy: the load test tells you how much traffic the site can take. The audit tells you what a single visitor experiences.