A load testing server for k6 that you switch on for the test and release after

What goes wrong when the test machine is too small

The test itself starts to lie. k6 times every request from where it runs, so if its own machine is out of breath, your site looks slower than it really is. Grafana's documentation is direct about it: when k6 uses 100% of the CPU, the response times it reports can come out much larger than reality. Run out of memory and the system starts swapping or kills k6 partway through, and the results of that run can't be trusted.

The same goes for running k6 on the server you are testing. Both programs then fight over one processor and one network card, and you end up measuring the fight. Give the load generator, which is just the machine that sends the traffic, a server of its own.

How big does it need to be?

Smaller than most people expect. According to Grafana, one k6 process can drive 30,000 to 40,000 virtual users (VUs, each one a simulated visitor running your script) on a single machine, and it spreads itself over every core. Here is how to work out your own numbers:

1. Memory: run your script with 100 VUs on your laptop, note how much memory k6 takes, and multiply by the number of VUs you want. Simple scripts need roughly 1 to 5 MB per VU; scripts that upload files or load big JavaScript libraries can need tens of megabytes each. Keep the total under 90% of the server's memory.
2. Processor: pick a size where k6 stays at or under about 80% CPU during the test, so 20% is always free.
3. Connection: watch the traffic while the test runs. If it sits flat at the connection's top speed, the network is what's holding you back, not your site.
4. Swap: switch it off on the test machine, so a memory shortage shows up plainly instead of quietly slowing everything down.

You can cut memory per VU by setting discardResponseBodies: true when your script never reads the page content, and by loading test data once with SharedArray instead of copying it into every VU.

Getting k6 running

Pick Ubuntu or Debian when you order and paste your SSH key, and you can log in as root as soon as the machine is built. Then add Grafana's package source and install k6:

curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

Prefer AlmaLinux or Rocky Linux? Grafana documents a dnf route for Fedora and CentOS that you can follow: add its RPM repository package (repo.rpm from dl.k6.io) with dnf, then install the k6 package the same way. Start with a tiny run, a few VUs for a minute, so you know the script works and your site answers before you turn the load up.

Lift the Linux limits first

Out of the box, Linux allows far fewer open connections than a big test needs, and the classic symptom is k6 stopping with "socket: too many open files". Grafana's guide for large tests suggests running these as root before you start:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_timestamps=1
ulimit -n 250000

The first line gives k6 more local ports to open connections from, the next two let Linux reuse local ports held by recently closed connections (Grafana's tuning page calls this one a last resort), and ulimit -n lets one process hold many more open files. The ulimit lasts only for that shell session, and the sysctl settings go back to normal after a reboot or a network service restart. For a machine you will release after the test, that is usually all you need.

One more ceiling to know: a single Linux machine can open at most 65,535 sockets per IP address, so there is a hard limit to how many requests one server can have in flight at once. Grafana's tuning page also advises changing settings conservatively and re-running the test each time, noting what actually improved.

Pay for the hours your test runs

Load tests come in bursts: a run before a launch, a few rounds after a fix, a night-long check for memory leaks. That's why the elastic option on our Cloud VPS fits so well. Elastic machines are the same sizes as the monthly ones, billed differently:

• While it's switched on, you pay by the second.
• Switched off, you pay only for its disk and its IP address, so you can keep a ready-made test machine between rounds without paying for the processor.
• Every GB you send is billed, with no monthly cap, and what you receive is free. A load test mostly sends small requests and receives the replies, which helps.
• There's nothing to pay today. You save a card, a week of running time is held on it at checkout, and what you used is billed at the end of the month.
• When you're done, release the machine from your dashboard and the last bit goes on a final invoice.

Every size comes with root access, its own IPv4 and an IPv6 /96, and a console in your browser for the day SSH won't answer. You can also pick the Docker app at order time if you'd rather run k6 from its grafana/k6 container image. People are on chat and phone at any hour if something gets in your way.

When you'll want something bigger

A Cloud VPS shares the physical server underneath with other customers, and processor time is shared too. For most tests that's fine as long as you keep k6 comfortably under 80% CPU and run each test twice to see the numbers agree. A few cases call for more:

• You test every day, or run long tests that keep every core busy. A whole server never shares its cores; our dedicated servers start there, and a racked one goes live about half an hour after approval.
• The connection tops out. Each Cloud VPS size has a capped connection speed. Whole servers come on an unmetered port, and you can raise it, for example to 10 Gbps on a dedicated server.
• Your visitors are far from New York. The Cloud VPS runs only there, while whole servers are racked in five cities, two of them in Europe; see the servers ready to go.

When one machine isn't enough, k6 can split one test across several with the --execution-segment option. Each copy then checks its own thresholds and reports its own numbers, so you combine the results yourself.

Questions people ask

Do I really need a separate machine to run k6?

For any test bigger than a quick check, yes. k6 measures response times from its own machine, so if it shares a server with your site, the two slow each other down and the results stop meaning much. A separate server keeps your numbers clean.

How many users can one test server simulate?

Grafana says a single k6 instance can run 30,000 to 40,000 virtual users, depending on the machine and the script. In practice you'll hit CPU, memory or the connection before that. A short trial run with htop and iftop open shows you which one.

How much memory should I give it?

Measure it: run 100 virtual users on your own computer and multiply k6's memory use by the number of users you want. Simple scripts take about 1 to 5 MB each, file uploads much more. Leave enough spare that memory stays under 90% during the test.

What does it cost me when the test server is switched off?

Only its disk and its IP address, which are billed every hour the machine exists. The processor isn't charged while it's off. The Cloud VPS page shows the switched-on and switched-off price of every size, and releasing the machine ends billing.

k6 stopped with "too many open files". What now?

Your server hit its limit on open files, and every connection counts as one. Run ulimit -n 250000 in the same shell before starting k6, as Grafana's guide suggests, and widen the local port range with the sysctl command on this page.