Example load tests

Log in, browse, cart, checkout

Every virtual user logs in once, lists products with the returned token, adds the first one to the cart and checks out. Think times mimic a real user; adding to the cart and checking out change data, so the run asks for approval first. The checkout step has its own p95 threshold.

giris-sepet-odeme.json ↓HTTPramping-vusextractmodifiesData

Constant request rate and a spike

200 requests a second whatever the response time; at minute four a second scenario climbs to 800 requests/s in 30 seconds. The run stops itself if the error rate passes 2%; iterations skipped because the system could not keep up have a threshold too.

sabit-istek-hizi.json ↓HTTPconstant-arrival-rateramping-arrival-rateabortOnFail

Kafka: produce and consume

Produces 500 order events a second (key, JSON body, header) while 10 consumers read the same topic and check the body. The produce acknowledgement's p95 must stay under 50 ms. With Spitfire 0.17.0 and later, the records' end-to-end latency and the test's consumer group lag are measured too.

Needs: a Kafka connection named "kafka" under Connections.

kafka-uretici-tuketici.json ↓Kafkaproduceconsumeconsumer lagp95<50ms

PostgreSQL read load

Single-order reads with random ids and an hourly summary query. It only reads; add a write and Spitfire asks for approval before the run.

Needs: a PostgreSQL connection named "orders-db" under Connections, and an orders table.

sql-okuma-yuku.json ↓SQLrowCountp95<20ms

PostgreSQL query mix

One SQL step runs four queries weighted by their production call counts: an order by id, a customer's latest orders, the pending order count and an hourly summary. Each query has its own p95 threshold; the run page and the report show each query's p50, p95, p99 and error rate. It only reads.

Importing your own query profile from pg_stat_statements or MySQL statistics: the SQL guide.

Needs: a PostgreSQL connection named "orders-db" under Connections, and an orders table.

sql-sorgu-karisimi.json ↓SQLquery mixweightsql_query_duration

Version comparison: test and dev

A test with two environments: test (arm A, the release in production) and dev (arm B, the candidate). Each carries its own address, its declared resources (CPU, memory, instances, database version, data volume, cache) and the address its version is read from ({{base}}/version, $.version). On the test's page, Run ▾ → Comparative run runs both arms at the same time with the same load. The load ramps up in the first minute; the warm-up is set in the dialog, and its default 60 s leaves that ramp out of the comparison. It only reads, so no write confirmation is needed.

Environments, the warm-up and running it from CI: installation guide · version comparison.

surum-karsilastirma.json ↓HTTPenvironmentsA/Bwarm-up