Create JMeter Performance Test Plans

This skill designs Apache JMeter test plans for load and performance testing of web applications and APIs. It covers Thread Group configuration as the core execution unit (thread count, ramp-up time, loop count, scheduler-based duration, and error-handling behavior), HTTP Request Defaults for shared domain/protocol/timeout settings across samplers, and data-driven testing via CSV Data Set Config (parameterizing variables from a file with configurable delimiter, recycling, and thread-sharing mode).

<ThreadGroup ...>
  <stringProp name="ThreadGroup.num_threads">100</stringProp>
  <stringProp name="ThreadGroup.ramp_time">300</stringProp>
  <boolProp name="ThreadGroup.scheduler">true</boolProp>
  <stringProp name="ThreadGroup.duration">1800</stringProp>
</ThreadGroup>

Advanced samplers and processors cover a JSON Post-Processor extracting a value (like an auth token) via JSONPath with a default fallback if not found, and a Response Assertion validating HTTP status codes with a custom failure message. Real-time performance monitoring integrates a Backend Listener pushing metrics to InfluxDB via an HTTP metrics sender. Test execution best practices cover gradual ramp-up strategies, warm-up periods, disabling listeners during actual load runs, non-GUI (-n) execution, and JVM heap tuning for large tests. Error handling is shown with a BeanShell post-processor that logs and flags a stop condition when a 500 response is detected.

Common load-testing patterns include a full API authentication flow (login, extract token via JSON Extractor, attach it via Header Manager to subsequent requests, refresh with timers) and a JDBC Connection Configuration for database-backed load tests (pool size, timeout, driver, connection URL). Command-line execution covers basic non-GUI runs, custom property overrides (-Jusers, -Jrampup), and distributed testing across remote JMeter engines (-r -Gusers). Reporting guidance covers generating HTML dashboards (-e -o), monitoring response time/throughput/error rate, percentile analysis (90th/95th/99th), and SLA-based pass/fail assertions.

Use this skill when designing or extending a JMeter test plan for load/performance testing - configuring thread groups and ramp-up strategy, parameterizing requests with CSV data, extracting and reusing dynamic values like auth tokens, asserting on response correctness, or wiring real-time metrics into InfluxDB/Grafana dashboards.

It is not the right tool for functional/UI testing (JMeter is protocol-level, not a browser automation tool) or for teams already standardized on a different load-testing tool (Gatling, k6, Locust) where JMeter's XML-based .jmx format and Java-based execution model don't fit the existing toolchain.

Input: the target application/API endpoints, expected load pattern (concurrent users, ramp-up, duration), and any parameterized test data or database dependencies. Output: a JMeter .jmx test plan with configured thread groups, HTTP defaults, CSV-driven parameterization, JSON extraction and response assertions, optional database connection pooling, real-time InfluxDB metrics reporting, and command-line execution scripts producing HTML performance reports.

Built on Apache JMeter's XML-based test plan format, with real-time metrics reporting to InfluxDB via the Backend Listener, JDBC connectivity (shown with PostgreSQL) for database-backed tests, and BeanShell scripting for custom error-handling logic within the test plan.

Performance engineers and QA teams building load tests for web applications and APIs - particularly those needing parameterized, correlated multi-step test flows (like token-based authentication) with real-time monitoring and SLA-based reporting.