About this Redis / Valkey / KeyDB / Dragonfly load test
Covers the common Redis, Valkey, KeyDB and Dragonfly workload patterns over the RESP protocol: strings, counters, hashes, lists, sets, sorted sets, transactions, Lua scripts, pub/sub, streams, big values, key scans, replication wait, connection churn and ramps.
It holds 39 ready-made jobs: 23 single scenarios and an enterprise test plan of 16 stages to run in order, 11 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include PING, connect, PING, QUIT (connection churn), AUTH then PING, SET (string write) and GET (string read).
How to load test Redis / Valkey / KeyDB / Dragonfly
Open the template in BLASTA.
Set host to point at your own Redis / Valkey / KeyDB / Dragonfly system, ideally a staging copy.
Pick a job and choose the rate and duration.
Start the run and watch requests per second, latency percentiles and errors live; the result is saved to your history.
What you set before running
host
Redis host name
port
Redis port
authPassword
A credential, supplied as an environment variable and never typed into the form. Password for the AUTH jobs. Read from REDIS_PASSWORD by the CLI.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. The simplest write; includes AOF/replication cost.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Two commands in one round trip, the way client libraries pipeline.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Typical cache fill. Many keys expiring together create an expiry storm: raise the rate and watch latency spikes.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Rate limiters and counters. Contention on a single hot key shows the single-threaded ceiling.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Session and object storage.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Simple job queue pattern (Sidekiq, Resque, RQ).
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Tags, unique visitors, membership checks.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Sorted sets cost O(log n) per write; the range read is the part that grows with size.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Atomic block: replies +OK, +QUEUED, +QUEUED, then the results.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Event log pattern. Streams grow without bound unless trimmed: add MAXLEN in real use.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. Large values stress the network buffers and replication. Latency grows with size, and values over 1 MB are a known cause of latency spikes.
Writes keys named blasta:*, so they are easy to delete (redis-cli --scan --pattern 'blasta:*' | xargs redis-cli del). Use a test instance. WAIT blocks until a replica acknowledges, so this measures replication lag directly. Needs at least one replica, else it returns :0 after the timeout.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Ramps new connections per second to ten times normal: a fleet reconnecting after an outage, a deploy that restarts every pod, a network blip. Shows accept-queue, file descriptor and handshake limits. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Five times normal reads for 10 minutes: the application's busiest hour with a warm cache. p95 should stay in single-digit milliseconds. Reference request: GET (string read).
Every request increments the SAME counter at high concurrency, like a global rate limiter or a page-view counter. Redis is single-threaded, so one hot key caps throughput however many cores you have. Reference request: INCR (counter). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Three times normal write-then-read for 10 minutes: session stores and write-through caches. Reference request: SET then GET (pipelined). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Applications without a connection pool reconnect for every operation. Ramps to ten times normal. Watch maxclients, file descriptors and TIME_WAIT sockets. Reference request: connect, PING, QUIT (connection churn).
Client libraries pipeline: 100 SETs in one network write, as bulk loaders and batch workers do. Checks the reply only starts correctly; throughput is 100 commands per request, so the command rate is 100 times the request rate. Reference request: SET (string write). This job WRITES or creates data on every request: staging only, and expect a lot of rows.
Frequently asked questions
What does the Redis / Valkey / KeyDB / Dragonfly load test cover?
The Redis / Valkey / KeyDB / Dragonfly template has 39 jobs: 23 single scenarios and an enterprise test plan of 16 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include PING, connect, PING, QUIT (connection churn), AUTH then PING and SET (string write). 11 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
How do I load test Redis / Valkey / KeyDB / Dragonfly with BLASTA?
Open the template in BLASTA and set host, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new redis with your address.
Is it safe to run the Redis / Valkey / KeyDB / Dragonfly load test against production?
Of the 39 jobs, 11 are read-only, 28 write data and 0 change state. Run the writing and state-changing jobs against a staging system, never against production data. Only test systems you own or have permission to test.
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Load generator resources
CPU used by BLASTA % of capacity
RAM used by BLASTA
Requests per second
Latency p95 lower is better
Response time
Status codes
Errors
Pick a template
Ready-made jobs for common systems. Search by system, protocol or what you want to test
(wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.