Execute k6 Load Tests for API Performance

k6 Load Testing covers writing and executing performance tests for HTTP APIs, WebSocket endpoints, and browser scenarios with k6, a developer-centric load testing tool - configuring test scenarios (smoke, load, stress, spike, soak), analyzing results, and integrating with CI/CD pipelines to validate system performance, find bottlenecks, ensure SLA compliance, and catch performance regressions before deployment.

A basic test file exports an options object (virtual users, duration or ramp-up/down stages) and a default function that runs per virtual user, using http.get/http.post and check() assertions on status code and response time, run via k6 run test.js. Test configuration supports fixed vus/duration or staged ramps, thresholds for SLA enforcement (e.g. p(95)<500 on http_req_duration, rate<0.01 on http_req_failed), and distributed load-zone configuration. Five test types are distinguished by purpose and configuration: smoke (low VUs, short duration, verify basic functionality), load (target VUs matching expected traffic), stress (ramp beyond capacity to find the breaking point), spike (rapid increase/decrease to simulate sudden traffic), and soak (extended duration for long-term stability).

HTTP testing covers basic GET/POST requests with JSON bodies and auth headers (reading tokens from __ENV), request chaining (logging in, extracting a token from the response, and using it in subsequent authenticated requests), and parameterized testing that indexes into a data array by __VU to distribute different test data across virtual users. Browser testing (k6 Browser, requiring k6 install chromium) uses browser.newPage() to navigate, read the page title, click elements, and wait for selectors within a constant-vus scenario executor. WebSocket testing uses ws.connect() with open/message/close event handlers, periodic message sending via setInterval, and a timed close via setTimeout.

Data handling covers loading CSV or JSON test data once and sharing it efficiently across virtual users via SharedArray, indexing by __VU or randomly. Thresholds support multiple percentile/average conditions on the same metric (p(90), p(95), p(99), avg), custom metric thresholds, and thresholds scoped to a specific request tag (e.g. http_req_duration{method:GET}). Custom metrics use k6's Counter, Trend, Rate, and Gauge types to track arbitrary values like total API calls, response time distributions, error rates, and active user counts, plus request tagging (tags: { endpoint: 'users', env: 'prod' }) for granular result breakdown.

CI/CD integration is shown for GitHub Actions (using grafana/k6-action, running on push and a nightly cron schedule, uploading JSON results as an artifact, and failing the job if thresholds are breached) and GitLab CI (running the grafana/k6 Docker image with JUnit-format result reporting). Results analysis covers k6's built-in text summary, JSON output for programmatic parsing, and streaming results to InfluxDB+Grafana, Prometheus remote write, or k6 Cloud - with a reference table for interpreting key metrics: p95 response time (good under 300ms, warning 300-500ms, bad over 500ms), error rate (good under 0.1%, warning 0.1-1%, bad over 1%), requests/sec relative to target, and VU count stability.

Best practices: start with a smoke test (1-5 VUs) before scaling up; parameterize with realistic user data and behaviors; set thresholds that actually match SLA and business requirements; include ramp-up time in staged tests to warm up the system; monitor downstream/external dependencies, not just the API under test; tag requests for granular analysis; and keep one test file per scenario for clarity. Common pitfalls: tests passing locally but failing in CI (check CI environment resources/network parity), inconsistent results between runs (check for external dependencies, random data, or test-data pollution), k6 running out of memory (use SharedArray for large datasets, reduce VUs, or set --max-memory), and overly strict thresholds (start relaxed and tighten based on historical data).

Use this skill when load testing HTTP APIs, WebSocket endpoints, or browser scenarios, setting up performance regression tests in CI/CD, analyzing system behavior under various load conditions, comparing performance between code changes, or validating SLA requirements and performance budgets. Do not treat the output as a substitute for environment-specific validation, testing, or expert review, and stop to ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Engineers who need to validate API/WebSocket/browser performance under load - smoke, load, stress, spike, or soak testing - with SLA thresholds and CI/CD integration to catch performance regressions before they ship.