Back up your assumptions with data
We often assume that changes to code or infrastructure will improve performance. Something simple like caching a block in Drupal might seem like an easy win. But without data, it’s just a guess.
Extra code makes your system more complex, harder to read, and harder to maintain. So what if the change you made didn’t help, or even made things worse? Would you still keep it?
Now apply that thinking to a bigger change like switching from Memcache to Redis. What if the result was a 5% slowdown on every page load? You’d want to know that before going live.
That’s where K6 comes in. It helps validate assumptions with real-world simulations—from basic page loads to full user journeys like submitting a form and viewing a success screen.
We’ve talked about this before in our intro to load testing with K6.
What we changed
We’ve updated our K6 starterkit to make load testing easier and more flexible.
You can now define multiple test cases and combine them into realistic scenarios. Whether you’re simulating a quick health check or running thousands of users over hours, it’s now easier to set up and scale your tests.
Want to isolate a known issue? Create a targeted scenario to track performance over time.
{
"scenarios": {
"pageNotFound": {
"exec": "pageNotFound",
"executor": "constant-vus",
"vus": 1,
"duration": "10m"
},
"basic": {
"exec": "basic",
"executor": "constant-vus",
"vus": 10,
"duration": "10m"
}
},
"thresholds": {
"http_req_duration{scenario:pageNotFound}": [],
"http_req_duration{scenario:basic}": []
}
}
We’ve reduced the steps required to get started, making it more likely that development and ops teams will run tests regularly, not just before launch.
What’s next
We’re planning to support config files for things like base URLs and environment settings, and we’re exploring options for distributed test runners.
If you’ve got ideas or improvements, we’d love your input. Send us a pull request and help shape the next version of the K6 starterkit.