Load tests

A load test runs a scripted user journey many times in parallel against a deployed service, over the network, rather than calling code inside the test process. The tool ramps the number of virtual users up, holds it and records every response time and error, so you can see where latency climbs or errors start. Apache JMeter, a Java application, runs each virtual user as a thread: a thread group sets how many, and each thread runs the whole test plan on its own. Plans are built in a GUI, saved as .jmx files and then run in CLI mode, which writes a results file and an HTML report. For more load, a controller sends the plan over RMI to jmeter-server processes on other machines, and every server runs the same plan.

How the load is generated matters. In a closed model each virtual user waits for its last response before starting again, so a slow server lowers the request rate and hides part of its own slowness, which is known as coordinated omission. In an open model new iterations arrive at a set rate whatever the response times. Grafana k6 offers both through its executors (constant-arrival-rate is open), Gatling recommends the open model when each virtual user makes one request, and JMeter added an Open Model Thread Group that its docs still call experimental.

The tools differ most in how you write tests. k6 scripts are JavaScript, and thresholds such as “95th percentile under 200 ms” are pass/fail criteria that make k6 exit with a non-zero code, so CI can fail the build. Gatling simulations are code in Java, Kotlin, Scala, JavaScript or TypeScript. Locust tests are plain Python, each simulated user a gevent coroutine, so one process can simulate thousands of users, with a web UI or headless. JMeter needs no code for most plans and also speaks JDBC, JMS, LDAP, FTP, mail and raw TCP, but it does not run the JavaScript in pages, so it measures the server, not the browser.