Measure it rather than guess. k6's guidance is that a simple test uses roughly 1-5 MB of memory per VU, and more when the script imports large JavaScript modules or loads files, because every VU is its own JavaScript runtime with its own copy of what it loads. To size a machine, run the real script with a small number of VUs, watch memory and CPU, and scale up linearly with some headroom.

Ways to fit more VUs on one machine:

• Load large test data once with SharedArray instead of into every VU.
• Use discardResponseBodies: true and read bodies only for the requests that need them.
• Keep metric cardinality down: dynamic URLs create a new time series per URL, so group them with a name tag.
• Don't use swap, and keep RAM use below about 90%.

CPU and the network interface often run out before memory does, so watch them too: when the load generator is saturated, response times rise because of the generator, not the system under test. If one machine isn't enough, split the load across machines, for example with the k6 Operator on Kubernetes.

Compared with JMeter, k6 is usually lighter per virtual user, but published comparisons are vendor benchmarks, and the figures depend heavily on the script. Run your own before choosing a tool on density alone.

Sources: k6: running large tests, k6: SharedArray