Apache JMeter

The workhorse of load testing for over two decades. JMeter remains the most protocol-complete open-source option and the de facto standard in enterprise environments.

Where it shines

Protocol breadth is unmatched among free tools: HTTP(S), JDBC, JMS, FTP, LDAP, SMTP, TCP and — via plugins — almost anything else. The plugin ecosystem (notably the jmeter-plugins.org collection) covers custom thread shapes, advanced listeners and protocol extensions. For organisations with years of accumulated JMeter assets, continuity itself is a feature.

Working around its weaknesses

JMeter's GUI-and-XML model makes diffs and code review painful; we mitigate with disciplined project structure, parameterised test fragments and treating the JMX as generated artefact where possible. Memory consumption per virtual user is high relative to k6 or Gatling — we plan generator fleets accordingly and always run distributed tests in non-GUI mode with tuned JVM settings.

# Distributed run, non-GUI, tuned heap
JVM_ARGS="-Xms4g -Xmx4g -XX:+UseG1GC" \
jmeter -n -t peak-load.jmx \
  -R gen-01,gen-02,gen-03,gen-04 \
  -Gthreads=625 -Gramp=1200 \
  -l results/peak-$(date +%Y%m%d-%H%M).jtl \
  -e -o results/report

Our JMeter practice

Version-controlled JMX with externalised configuration; CSV data sets generated by scripted pipelines; backend listeners streaming live metrics to InfluxDB/Grafana during runs; and JTL post-processing in Python for percentile analysis beyond the built-in report.