Performance

An open-source Java-based performance testing tool for measuring the behaviour of systems under load. Supports HTTP, JDBC, FTP, JMS, and other protocols. Widely used in enterprise and regulated industries (banking, insurance, government) due to its maturity, GUI-based test authoring, and rich plugin ecosystem. Test plans are stored as .jmx XML files and can be run headlessly from the command line for CI/CD integration.

Establishing a reference performance profile under known conditions. Future runs compare against this baseline to detect regressions or improvements introduced by code or infrastructure changes.

Storing the result of an expensive operation (a database query, an API call, a rendered page) so subsequent requests can be served faster without repeating the work. Caching introduces a class of test-specific bugs: stale data shown after an update, cache invalidation failures (old data persists after it should have been evicted), and CDN edge-cache inconsistencies where different users see different versions. Test strategy: verify freshness after writes, verify cache is bypassed when it should be (e.g. authenticated vs. public), and test behaviour when the cache layer is cold or unavailable.

Forecasting the infrastructure needed to handle expected load — CPU, memory, database connections, network. Performance test results feed the model that decides how much hardware to provision.

The number of users actively interacting with the system at the same moment. A primary input to load and stress test design.

The process of extracting dynamic values from server responses (session tokens, transaction IDs, CSRF tokens) and injecting them into subsequent requests. Essential for testing stateful applications where each session contains unique identifiers. In JMeter, correlation is achieved with JSON Extractors, Regex Extractors, and XPath Extractors.

The XML file format used by Apache JMeter to store test plans. A .jmx file encodes the complete test plan — Thread Groups, Samplers, Assertions, Listeners, and Config Elements — in a portable, version-controllable format. JMX files can be created and edited in the JMeter GUI and executed headlessly in CLI mode using `jmeter -n -t test.jmx`.

The time between sending a request and receiving the first byte of response. Lower is better. Often reported at percentiles (p50, p95, p99) since averages hide tail behaviour.

Verifying system behaviour under expected production load. Confirms the application meets performance targets at typical concurrent-user counts before release.

A statistic that reports the value below which a given percentage of measurements fall. p95 means 95% of requests were faster than this number — and 5% were slower. Performance teams report tail percentiles because averages hide the slow long tail.

The duration over which virtual users gradually start hitting the system at the beginning of a load test. A short ramp-up can mimic a flash crowd; a longer one models steady traffic growth.

Testing that a system degrades gracefully and recovers correctly under adverse conditions: slow networks, service timeouts, partial failures, high load, and dependency outages. Covers retry and timeout verification, circuit-breaker triggering, failover, and recovery-after-crash scenarios. Broader than chaos engineering (which targets production-level fault injection) — resilience testing is conducted in controlled test environments.

Total time from request initiation to response completion. Includes latency plus transfer and processing time. The end-user-perceived performance metric.

The load level at which adding more users no longer increases throughput — a resource (CPU, DB, queue) is fully utilised. Past this point, response times rise sharply while requests per second flatten.

A formal, often contractual commitment about service performance — e.g. "99.9% uptime" or "p95 response under 500ms" — with consequences (credits, penalties) if missed. The SLA is the externally-promised number; it's what the business has told customers it will deliver.

An internal target for service performance — usually stricter than the SLA, giving an early-warning buffer before the contractual line is crossed. If the SLA promises 99.9% uptime, the SLO might be 99.95%, so the team reacts before customers are affected. SLOs are paired with "error budgets" — how much you're allowed to miss.

Running the system at expected load for a prolonged period (hours to days) to surface memory leaks, connection exhaustion, and slow degradation that short tests miss.

Subjecting the system to sudden, sharp load increases to verify it can absorb traffic surges (flash sales, news mentions) without collapsing or losing data.

Pushing the system beyond its limits to find the breaking point and observe failure modes. Asks: where does this fall over, and how does it recover?

Pauses between user actions in a load test that simulate real reading, scrolling, or decision time. Without think time, a load script generates an unrealistic, machine-gun request pattern that doesn't match production traffic.

The core configuration element in a JMeter test plan that defines the number of virtual users, the ramp-up period, and the test duration. Each thread in a Thread Group simulates one virtual user running through the sampler sequence. Specialised variants include the Stepping Thread Group (gradual increment) and Ultimate Thread Group (arbitrary load shapes).

The amount of work completed per unit of time — requests per second, transactions per second. Higher is better.

A simulated user in a load test — an independent thread that follows a scripted journey (log in, browse, check out) with its own session and think-time, mimicking one real person's load. "1,000 VUs" means a thousand concurrent simulated journeys. VUs are the unit you scale to model traffic.