Generate realistic performance test scenarios with load profiles, ramp-up patterns, think times, and acceptance criteria derived from production traffic analysis
Generate realistic performance test scenarios with load profiles, ramp-up patterns, think times, and acceptance criteria derived from production traffic analysis
Performance testing validates that a system meets speed, scalability, and stability requirements under expected and extreme load conditions. The difference between a performance test that provides actionable insights and one that generates misleading data comes down to scenario design. Realistic scenarios mirror actual user behavior, incorporate proper think times, follow genuine navigation patterns, and simulate the mix of operations that production traffic exhibits. This skill guides AI coding agents through generating performance test scenarios that produce trustworthy, actionable results.
Core Principles
Production Traffic as the Source of Truth: Every load profile, user journey, and scenario mix should be derived from production analytics, access logs, or APM data. Guessing at traffic patterns produces misleading test results that give false confidence.
Think Time Realism: Real users pause between actions to read content, fill forms, and make decisions. Tests without think times create artificially aggressive load patterns that stress the system in ways production traffic never would.
Scenario Mixing Reflects Reality: Production traffic is never a single endpoint being hit uniformly. A realistic test combines browsing, searching, purchasing, and administrative actions in proportions that match observed usage patterns.
Incremental Load Application: Applying full load instantly does not represent real-world traffic growth. Ramp-up patterns allow the system to warm caches, initialize connection pools, and reach steady state before measurement begins.
Threshold-Based Pass/Fail Criteria: Performance tests without defined thresholds are observational exercises, not tests. Every scenario must include specific, measurable acceptance criteria tied to business requirements.
Correlation and Parameterization: Tests using hardcoded values do not exercise the same code paths as production requests. Dynamic values extracted from responses and parameterized from data files ensure realistic request variation.
Environment Parity Awareness: Performance test results are only meaningful when the test environment closely resembles production. Document environment differences and adjust expectations accordingly.
A constant load profile maintains a fixed number of virtual users throughout the test duration. This is the simplest profile, useful for establishing baseline performance metrics.
# Basic load test
k6 run src/profiles/load-test.ts
# With environment variables
k6 run --env BASE_URL=https://staging.example.com \
--env TEST_ENV=staging \
src/profiles/load-test.ts
# Output to multiple destinations
k6 run --out json=results/output.json \
--out influxdb=http://localhost:8086/k6 \
src/profiles/load-test.ts
# Cloud execution (k6 Cloud)
k6 cloud src/profiles/load-test.ts
Best Practices
Derive load profiles from production data. Analyze access logs, APM data, and analytics to determine actual peak traffic patterns, user journeys, and endpoint distribution before designing test scenarios.
Always include think times between requests. Without think times, each virtual user generates far more load than a real user. Calibrate think times from session recordings or analytics data.
Use scenario-specific thresholds. A single global response time threshold masks problems. Set separate thresholds for browsing (fast), checkout (moderate), and reporting (slower) flows.
Parameterize all test data. Hardcoded IDs, usernames, and search terms cause cache warming effects that do not represent production. Use CSV files or generators for realistic data variation.
Ramp up gradually before measuring. The first few minutes of a test are warm-up. Do not include ramp-up data in performance analysis. Use k6 stages or JMeter ramp-up periods.
Run tests against a production-like environment. Testing against a single-instance dev environment with mock databases produces meaningless results. Match production topology as closely as possible.
Include background traffic simulation. Production systems handle background jobs, cron tasks, and admin operations alongside user traffic. Include these in scenarios for realistic resource contention.
Track custom business metrics. Beyond HTTP response times, measure business-meaningful metrics: checkout completion time, search result relevance latency, time to first byte for critical pages.
Correlate client metrics with server monitoring. Response time alone does not identify bottlenecks. Combine k6 results with Grafana dashboards showing CPU, memory, database connections, and cache hit rates.
Version and review test scripts like production code. Performance test scripts are code. They should be version-controlled, code-reviewed, and maintained as the application evolves.
Run soak tests regularly. Memory leaks and connection pool exhaustion only manifest under sustained load. Run 4-8 hour soak tests at least weekly in addition to shorter load tests.
Automate performance testing in CI/CD. Run a reduced-scale load test on every PR merge to catch performance regressions early, with full-scale tests on a scheduled basis.
Anti-Patterns to Avoid
Testing without think times. A test with 100 VUs and no think times generates traffic equivalent to thousands of real users. This produces artificially high load and misleading failure thresholds.
Using a single endpoint for load testing. Hitting one endpoint repeatedly tests that endpoint's cache and connection pool, not the system. Always mix multiple endpoints reflecting real usage patterns.
Ignoring ramp-up data in results. Including the ramp-up phase in percentile calculations skews results. Either exclude ramp-up data or use k6 scenarios with separate measurement windows.
Hardcoding authentication tokens. Tokens expire, sessions time out, and rate limiters track per-user. Use the correlation pattern to authenticate dynamically and distribute load across user accounts.
Running performance tests on shared CI runners. Shared infrastructure introduces variability. Performance test clients need dedicated, consistent compute resources to produce reliable, comparable results.
Setting thresholds after seeing results. Define acceptance criteria before running tests, based on business requirements and SLAs. Setting thresholds retroactively to match observed performance defeats the purpose.
Testing only the happy path. Real traffic includes 404s, validation errors, and retries. Include error scenarios in the mix to test error handling performance and verify error responses are not slower than success responses.
Debugging Tips
Start with a single VU to verify the script works. Run k6 run --vus 1 --iterations 1 to catch script errors, authentication issues, and URL problems before scaling up.
Use the k6 HTTP debug flag. Set --http-debug="full" to see complete request and response bodies during development. Remove this flag for actual test runs.
Check for correlation failures. If requests fail with 403 or 422 errors mid-test, a dynamic value (CSRF token, session ID) is likely not being correlated. Add logging to extraction functions.
Monitor virtual user count vs actual requests. If the VU count is high but request rate is low, think times may be too long, or requests are timing out and blocking VUs.
Examine response bodies for error messages. A 200 status does not always mean success. Some applications return 200 with error messages in the body. Add content-based checks to detect soft failures.
Profile the test client machine. If the client running k6 is CPU-saturated, it cannot generate enough load and response time measurements become unreliable. Monitor client CPU during tests.
Compare results across multiple runs. A single test run is not statistically significant. Run the same test 3-5 times and compare results to identify natural variance versus actual performance differences.
Isolate slow transactions. Use k6 groups and custom metrics to identify which specific step within a multi-step scenario is causing elevated response times, rather than only looking at aggregate metrics.
