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.

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

kafka-uretici-tuketici.json ↓Kafkaproduceconsumep95<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