redis-benchmarks-specification 0.2.42__py3-none-any.whl

redis_benchmarks_specification/test-suites/memtier_benchmark-playbook-realtime-analytics-membership.yml

@@ -0,0 +1,56 @@
+version: 0.4
+name: memtier_benchmark-playbook-realtime-analytics-membership
+description: 'This benchmark captures the performance of Redis under realistic **membership analytics** workloads, where frequent set algebra operations (intersection, union, difference) drive personalization, segmentation, and eligibility checks.'
+dbconfig:
+  configuration-parameters:
+    save: '""'
+  check:
+    keyspacelen: 2
+  resources:
+    requests:
+      memory: 1g
+  init_commands:
+  - '"SADD" "set:{org1}:10" "lysbgqqfqw" "mtccjerdon" "jekkafodvk" "nmgxcctxpn" "vyqqkuszzh"
+    "pytrnqdhvs" "oguwnmniig" "gekntrykfh" "nhfnbxqgol" "cgoeihlnei"'
+  - '"SADD" "set:{org1}:100" "vyoomgwuzv" "xamjodnbpf" "ewomnmugfa" "ljcgdooafo" "pcxdhdjwnf"
+    "djetcyfxuc" "licotqplim" "alqlzsvuuz" "ijsmoyesvd" "whmotknaff" "rkaznetutk"
+    "ksqpdywgdd" "gorgpnnqwr" "gekntrykfh" "rjkknoigmu" "luemuetmia" "gxephxbdru"
+    "ncjfckgkcl" "hhjclfbbka" "cgoeihlnei" "zwnitejtpg" "upodnpqenn" "mibvtmqxcy"
+    "htvbwmfyic" "rqvryfvlie" "nxcdcaqgit" "gfdqdrondm" "lysbgqqfqw" "nxzsnkmxvi"
+    "nsxaigrnje" "cwaveajmcz" "xsepfhdizi" "owtkxlzaci" "agsdggdghc" "tcjvjofxtd"
+    "kgqrovsxce" "ouuybhtvyb" "ueyrvldzwl" "vpbkvwgxsf" "pytrnqdhvs" "qbiwbqiubb"
+    "ssjqrsluod" "urvgxwbiiz" "ujrxcmpvsq" "mtccjerdon" "xczfmrxrja" "imyizmhzjk"
+    "oguwnmniig" "mxwgdcutnb" "pqyurbvifk" "ccagtnjilc" "mbxohpancs" "lgrkndhekf"
+    "eqlgkwosie" "jxoxtnzujs" "lbtpbknelm" "ichqzmiyot" "mbgehjiauu" "aovfsvbwjg"
+    "nmgxcctxpn" "vyqqkuszzh" "rojeolnopp" "ibhohmfxzt" "qbyhorvill" "nhfnbxqgol"
+    "wkbasfyzqz" "mjjuylgssm" "imdqxmkzdj" "oapbvnisyq" "bqntlsaqjb" "ocrcszcznp"
+    "hhniikmtsx" "hlpdstpvzw" "wqiwdbncmt" "vymjzlzqcn" "hhjchwjlmc" "ypfeltycpy"
+    "qjyeqcfhjj" "uapsgmizgh" "owbbdezgxn" "qrosceblyo" "sahqeskveq" "dapacykoah"
+    "wvcnqbvlnf" "perfwnpvkl" "ulbrotlhze" "fhuvzpxjbc" "holjcdpijr" "onzjrteqmu"
+    "pquewclxuy" "vpmpffdoqz" "eouliovvra" "vxcbagyymm" "jekkafodvk" "ypekeuutef"
+    "dlbqcynhrn" "erxulvebrj" "qwxrsgafzy" "dlsjwmqzhx" "exvhmqxvvp"'
+  dataset_name: 2keys-set-10-100-elements-org1
+  dataset_description: This dataset contains 2 set keys, one with 10 elements and
+    the other with 100 elements. The smaller set is a subset of the larger one.
+tested-commands:
+- smembers
+- sdiff
+- sunion
+redis-topologies:
+- oss-standalone
+build-variants:
+- gcc:15.2.0-amd64-debian-bookworm-default
+- gcc:15.2.0-arm64-debian-bookworm-default
+- dockerhub
+clientconfig:
+  run_image: redislabs/memtier_benchmark:edge
+  tool: memtier_benchmark
+  arguments: --command="SDIFF set:{org1}:100 set:{org1}:10" --command "SMEMBERS set:{org1}:100" --command
+    "SMEMBERS set:{org1}:10"  --command "SUNION set:{org1}:100 set:{org1}:10" --hide-histogram --test-time 180
+  resources:
+    requests:
+      cpus: '4'
+      memory: 2g
+tested-groups:
+- set
+priority: 131

redis_benchmarks_specification/test-suites/memtier_benchmark-playbook-session-caching-hash-100k-sessions.yml

@@ -0,0 +1,108 @@
+version: 0.4
+name: memtier_benchmark-session-caching-hash-100k-sessions
+description: |
+  Runs memtier_benchmark to simulate a session caching workload for a SaaS application.
+  This benchmark focuses exclusively on hash-based session storage, where each session
+  is stored in a Redis hash (`session:<id>`) with fields like user ID, timestamps, device info,
+  and metadata (total ~400–600B).
+
+  The benchmark models a typical read-heavy cache usage pattern, with an approximate
+  **read:write ratio of 90:10**, reflecting session retrievals and infrequent updates.
+
+  Command groups:
+    - Session cache reads (`HGETALL`): ~90%
+    - Session cache writes (`HSET`): ~10%
+
+  To better approximate real-world access patterns, the benchmark uses a **Zipfian key distribution**
+  (`--command-key-pattern=Z`). This simulates **skewed access** where a small subset of sessions (hot keys)
+  receives a majority of reads — a common pattern in production workloads.
+
+  While Zipfian is technically a power-law distribution, it effectively mimics **Poisson-like behavior**
+  in large-scale systems, where access frequency is uneven but statistically predictable.
+  This access skew mirrors real-life scenarios such as:
+    - Frequently accessed or "sticky" user sessions
+    - Popular user accounts or active devices
+    - Hot caches for trending or recently used resources
+
+  Using Zipfian distribution allows this benchmark to capture **contention**, **cache pressure**, and
+  **read amplification** effects that occur in real SaaS applications under load.
+
+
+dbconfig:
+  configuration-parameters:
+    save: '""'
+  resources:
+    requests:
+      memory: 1g
+  init_lua: |
+    local seed = 12345
+    math.randomseed(seed)
+    local now = tonumber(redis.call('TIME')[1])
+    local function rand_str(len)
+      local chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
+      local res = ''
+      for i = 1, len do
+        local idx = math.random(#chars)
+        res = res .. chars:sub(idx, idx)
+      end
+      return res
+    end
+    for i = 1, 100000 do
+      local session_id = 'session:' .. i
+      local user_id = 'user-' .. i
+      local org_id = 'org-' .. i
+      redis.call('HSET', session_id,
+        'userId', user_id,
+        'organizationId', org_id,
+        'role', 'member',
+        'createdAt', tostring(now - math.random(3600)),
+        'lastAccessed', tostring(now),
+        'ipAddress', '192.168.1.' .. (i % 255),
+        'device', 'device-' .. rand_str(8),
+        'authMethod', 'password',
+        'status', 'active',
+        'metadata', rand_str(200 + (i % 100))
+      )
+    end
+    return 'OK'
+
+tested-groups:
+- hash
+
+tested-commands:
+- hgetall
+- hset
+
+redis-topologies:
+- oss-standalone
+
+build-variants:
+- gcc:15.2.0-amd64-debian-bookworm-default
+- gcc:15.2.0-arm64-debian-bookworm-default
+- dockerhub
+
+clientconfig:
+  run_image: redislabs/memtier_benchmark:edge
+  tool: memtier_benchmark
+  arguments: >
+    --key-prefix ""
+    --key-minimum 1
+    --key-maximum 100000
+    --data-size-range=400-600
+    --pipeline=1
+    --print-percentiles=50,90,95,99
+    --run-count=1
+    --test-time=120
+    --command="HGETALL session:__key__"
+    --command-key-pattern=Z
+    --command-ratio=90
+    --command="HSET session:__key__ userId user-__key__ organizationId org-__key__ role admin email user__key__@example.com name \"User __key__\" permissions \"[\\\"read\\\",\\\"write\\\"]\" lastActivity __key__ ipAddress 192.168.1.__key__ userAgent \"Mozilla/5.0\" createdAt __key__"
+    --command-key-pattern=Z
+    --command-ratio=10
+    --hide-histogram
+  resources:
+    requests:
+      cpus: '4'
+      memory: 2g
+
+priority: 150

redis_benchmarks_specification/test-suites/memtier_benchmark-playbook-session-caching-json-100k-sessions.yml

@@ -0,0 +1,109 @@
+version: 0.4
+name: memtier_benchmark-session-caching-json-100k-sessions
+description: |
+  Runs memtier_benchmark to simulate a session caching workload for a SaaS application.
+  This benchmark focuses exclusively on JSON-based session storage, where each session
+  is stored as a Redis JSON document (`session:<id>`) with fields like user ID, timestamps, device info,
+  and metadata (total ~400–600B).
+
+  The benchmark models a typical read-heavy cache usage pattern, with an approximate
+  **read:write ratio of 90:10**, reflecting session retrievals and infrequent updates.
+
+  Command groups:
+    - Session cache reads (`JSON.GET`): ~90%
+    - Session cache writes (`JSON.SET`): ~10%
+
+  To better approximate real-world access patterns, the benchmark uses a **Zipfian key distribution**
+  (`--command-key-pattern=Z`). This simulates **skewed access** where a small subset of sessions (hot keys)
+  receives a majority of reads — a common pattern in production workloads.
+
+  While Zipfian is technically a power-law distribution, it effectively mimics **Poisson-like behavior**
+  in large-scale systems, where access frequency is uneven but statistically predictable.
+  This access skew mirrors real-life scenarios such as:
+    - Frequently accessed or "sticky" user sessions
+    - Popular user accounts or active devices
+    - Hot caches for trending or recently used resources
+
+  Using Zipfian distribution allows this benchmark to capture **contention**, **cache pressure**, and
+  **read amplification** effects that occur in real SaaS applications under load.
+
+
+dbconfig:
+  configuration-parameters:
+    save: '""'
+  resources:
+    requests:
+      memory: 1g
+  init_lua: |
+    local seed = 12345
+    math.randomseed(seed)
+    local now = tonumber(redis.call('TIME')[1])
+    local function rand_str(len)
+      local chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
+      local res = ''
+      for i = 1, len do
+        local idx = math.random(#chars)
+        res = res .. chars:sub(idx, idx)
+      end
+      return res
+    end
+    for i = 1, 100000 do
+      local session_id = 'session:' .. i
+      local user_id = 'user-' .. i
+      local org_id = 'org-' .. i
+      local session_data = {
+        userId = user_id,
+        organizationId = org_id,
+        role = 'member',
+        createdAt = tostring(now - math.random(3600)),
+        lastAccessed = tostring(now),
+        ipAddress = '192.168.1.' .. (i % 255),
+        device = 'device-' .. rand_str(8),
+        authMethod = 'password',
+        status = 'active',
+        metadata = rand_str(200 + (i % 100))
+      }
+      redis.call('JSON.SET', session_id, '$', cjson.encode(session_data))
+    end
+    return 'OK'
+
+tested-groups:
+- json
+
+tested-commands:
+- json.get
+- json.set
+
+redis-topologies:
+- oss-standalone
+
+build-variants:
+- gcc:15.2.0-amd64-debian-bookworm-default
+- gcc:15.2.0-arm64-debian-bookworm-default
+- dockerhub
+
+clientconfig:
+  run_image: redislabs/memtier_benchmark:edge
+  tool: memtier_benchmark
+  arguments: >
+    --key-prefix ""
+    --key-minimum 1
+    --key-maximum 100000
+    --data-size-range=400-600
+    --pipeline=1
+    --print-percentiles=50,90,95,99
+    --run-count=1
+    --test-time=120
+    --command="JSON.GET session:__key__"
+    --command-key-pattern=Z
+    --command-ratio=90
+    --command="JSON.SET session:__key__ $ \"{\\\"userId\\\":\\\"user-__key__\\\",\\\"organizationId\\\":\\\"org-__key__\\\",\\\"role\\\":\\\"admin\\\",\\\"email\\\":\\\"user__key__@example.com\\\",\\\"name\\\":\\\"User __key__\\\",\\\"permissions\\\":[\\\"read\\\",\\\"write\\\"],\\\"lastActivity\\\":__key__,\\\"ipAddress\\\":\\\"192.168.1.__key__\\\",\\\"userAgent\\\":\\\"Mozilla/5.0\\\",\\\"createdAt\\\":__key__}\""
+    --command-key-pattern=Z
+    --command-ratio=10
+    --hide-histogram
+  resources:
+    requests:
+      cpus: '4'
+      memory: 2g
+
+priority: 150

redis_benchmarks_specification/test-suites/memtier_benchmark-playbook-session-caching-string-100k-sessions.yml

@@ -0,0 +1,98 @@
+version: 0.4
+name: memtier_benchmark-session-caching-string-100k-sessions
+description: |
+  Runs memtier_benchmark to simulate a session caching workload for a SaaS application.
+  This benchmark focuses exclusively on **string-based session storage**, where each session
+  is stored in Redis as a serialized JSON string (`session:<id>`) containing fields like
+  user ID, timestamps, device info, and metadata (total ~400–600B).
+
+  The benchmark models a typical read-heavy cache usage pattern, with an approximate
+  **read:write ratio of 80:20**, reflecting session retrievals and infrequent updates.
+
+  Command groups:
+    - Session cache reads (`GET`): ~80%
+    - Session cache writes (`SET`): ~20%
+
+  To better approximate real-world access patterns, the benchmark uses a **Zipfian key distribution**
+  (`--command-key-pattern=Z`). This simulates **skewed access** where a small subset of sessions (hot keys)
+  receives a majority of reads — a common pattern in production workloads.
+
+  While Zipfian is technically a power-law distribution, it effectively mimics **Poisson-like behavior**
+  in large-scale systems, where access frequency is uneven but statistically predictable.
+  This access skew mirrors real-life scenarios such as:
+    - Frequently accessed or "sticky" user sessions
+    - Popular user accounts or active devices
+    - Hot caches for trending or recently used resources
+
+  Using Zipfian distribution allows this benchmark to capture **contention**, **cache pressure**, and
+  **read amplification** effects that occur in real SaaS applications under load.
+
+dbconfig:
+  configuration-parameters:
+    save: '""'
+  resources:
+    requests:
+      memory: 1g
+  init_lua: |
+    local seed = 12345
+    math.randomseed(seed)
+    local now = tonumber(redis.call('TIME')[1])
+    local function rand_str(len)
+      local chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
+      local res = ''
+      for i = 1, len do
+        local idx = math.random(#chars)
+        res = res .. chars:sub(idx, idx)
+      end
+      return res
+    end
+    for i = 1, 100000 do
+      local session_id = 'session:' .. i
+      local session_data = string.format(
+        '{"userId":"user-%d","organizationId":"org-%d","role":"member","createdAt":"%d","lastAccessed":"%d","ipAddress":"192.168.1.%d","device":"device-%s","authMethod":"password","status":"active","metadata":"%s"}',
+        i, i, now - math.random(3600), now, (i % 255), rand_str(8), rand_str(200 + (i % 100))
+      )
+      redis.call('SET', session_id, session_data)
+    end
+    return 'OK'
+
+tested-groups:
+- string
+
+tested-commands:
+- get
+- set
+
+redis-topologies:
+- oss-standalone
+
+build-variants:
+- gcc:15.2.0-amd64-debian-bookworm-default
+- gcc:15.2.0-arm64-debian-bookworm-default
+- dockerhub
+
+clientconfig:
+  run_image: redislabs/memtier_benchmark:edge
+  tool: memtier_benchmark
+  arguments: >
+    --key-prefix ""
+    --key-minimum 1
+    --key-maximum 100000
+    --data-size-range=400-600
+    --pipeline=1
+    --print-percentiles=50,90,95,99
+    --run-count=1
+    --test-time=120
+    --command="GET session:__key__"
+    --command-key-pattern=Z
+    --command-ratio=90
+    --command='SET session:__key__ "{\"userId\":\"user-__key__\",\"organizationId\":\"org-__key__\",\"role\":\"member\",\"createdAt\":\"1754905396\",\"lastAccessed\":\"1754906472\",\"ipAddress\":\"192.168.1.36\",\"device\":\"device-2T8YGLbl\",\"authMethod\":\"password\",\"status\":\"active\",\"metadata\":\"wDVmiQsSe2oSEPfhhvYN6jbVxVykSCzQXmnsqCIv5MEmpslD1LMgwJcUe8Wmhvhh56dgTDhH4o3M9vYa6JyAS3Axs2zufVVPWtTsCRVbNGjMmumy7j5vIM0OuclgbHBOxtGDtCU88YBc9IP5oNYiycXXCmq5s7mWAdmRhFrmFxOy3VKlrXJz4ZrtF6KHEflGhoF1FzXtLO8Dckg3B34kdxGsnNiRjNIEtWVxeXekUSDyrxcnwiIy29Zx8SxX2g8ZUrz3sTpEwX7KQZFpIi7XoSKZywvC6I63VMNpZcAO\"}"'
+    --command-key-pattern=Z
+    --command-ratio=10
+    --hide-histogram
+  resources:
+    requests:
+      cpus: '4'
+      memory: 2g
+
+priority: 150

redis_benchmarks_specification/test-suites/memtier_benchmark-playbook-session-storage-100k-sessions.yml

@@ -0,0 +1,205 @@
+version: 0.4
+name: memtier_benchmark-playbook-session-storage-100k-sessions
+description: |
+  Runs memtier_benchmark to simulate a session-based SaaS application.
+  The workload mimics user session CRUD, session tracking, organization-level analytics,
+  and rate limiting. It includes realistic key sizes and command mixes representative
+  of production traffic (e.g., 400–600B session hashes, ZSETs for analytics, and SETs for tracking).
+
+  Rate limiting is modeled using an atomic Lua script, inspired by the Upstash Redis example:
+  https://github.com/upstash/examples/tree/main/examples/ratelimit-with-redis
+
+  Each user has a dedicated key in the form of `ratelimit:user-<id>:/api/resource`, which is
+  used to track usage under a fixed window. The logic is evaluated atomically with the following script:
+
+      local key = KEYS[1]
+      local limit = 100
+      local window = 60
+      local current = redis.call("INCR", key)
+      if current == 1 then
+        redis.call("EXPIRE", key, window)
+      end
+      if current > limit then
+        return 0
+      else
+        return 1
+      end
+
+  This ensures that rate enforcement and usage tracking are done without race conditions, and
+  mirrors a real-world API quota model.
+
+  The workload emphasizes read-heavy patterns to reflect common SaaS access behavior. The overall
+  **read:write ratio is approximately 85:15**, with read operations covering session access, user-session
+  lookups, org analytics, and rate limit enforcement, while writes handle session updates, activity tracking,
+  and quota increments.
+
+  Command groups by use-case (approximate ratio of total operations):
+    - Session CRUD (HGETALL, HSET): ~55%
+    - User session tracking (SMEMBERS, SADD): ~21%
+    - Organization analytics (ZRANGE, ZADD): ~12%
+    - Rate limiting (EVAL-based quota check): ~12%
+
+exporter:
+  redistimeseries:
+    break_by:
+    - version
+    - commit
+    timemetric: $."ALL STATS".Runtime."Start time"
+    metrics:
+    - $."BEST RUN RESULTS".Hgetalls."Ops/sec"
+    - $."BEST RUN RESULTS".Hsets."Ops/sec"
+    - $."BEST RUN RESULTS".Smemberss."Ops/sec"
+    - $."BEST RUN RESULTS".Sadds."Ops/sec"
+    - $."BEST RUN RESULTS".Zranges."Ops/sec"
+    - $."BEST RUN RESULTS".Zadds."Ops/sec"
+    - $."BEST RUN RESULTS".Evals."Ops/sec"
+    - $."BEST RUN RESULTS".Totals."Ops/sec"
+    - $."BEST RUN RESULTS".Totals."Latency"
+    - $."BEST RUN RESULTS".Totals."Misses/sec"
+    - $."BEST RUN RESULTS".Totals."Percentile Latencies"."p50.00"
+    - $."BEST RUN RESULTS".Totals."Percentile Latencies"."p99.00"
+    - $."ALL STATS".Hgetalls."Ops/sec"
+    - $."ALL STATS".Hsets."Ops/sec"
+    - $."ALL STATS".Smemberss."Ops/sec"
+    - $."ALL STATS".Sadds."Ops/sec"
+    - $."ALL STATS".Zranges."Ops/sec"
+    - $."ALL STATS".Zadds."Ops/sec"
+    - $."ALL STATS".Evals."Ops/sec"
+    - $."ALL STATS".Totals."Ops/sec"
+    - $."ALL STATS".Totals."Latency"
+    - $."ALL STATS".Totals."Misses/sec"
+    - $."ALL STATS".Hgetalls."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Hsets."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Smemberss."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Sadds."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Zranges."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Zadds."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Evals."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Totals."Percentile Latencies"."p50.00"
+    - $."ALL STATS".Totals."Percentile Latencies"."p99.00"
+
+
+dbconfig:
+  configuration-parameters:
+    save: '""'
+  resources:
+    requests:
+      memory: 1g
+  init_lua: |
+    -- Use a fixed seed for reproducibility
+    local seed = 12345
+    math.randomseed(seed)
+
+    local now = tonumber(redis.call('TIME')[1])
+
+    local function rand_str(len)
+      local chars = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
+      local res = ''
+      for i = 1, len do
+        local idx = math.random(#chars)
+        res = res .. chars:sub(idx, idx)
+      end
+      return res
+    end
+
+    for i = 1, 100000 do
+      local session_id = 'session:' .. i
+      local user_id = 'user-' .. i
+      local org_id = 'org-' .. i
+
+      redis.call('HSET', session_id,
+        'userId', user_id,
+        'organizationId', org_id,
+        'role', 'member',
+        'createdAt', tostring(now - math.random(3600)),
+        'lastAccessed', tostring(now),
+        'ipAddress', '192.168.1.' .. (i % 255),
+        'device', 'device-' .. rand_str(8),
+        'authMethod', 'password',
+        'status', 'active',
+        'metadata', rand_str(200 + (i % 100))
+      )
+
+      redis.call('SADD', 'user:' .. i .. ':sessions', session_id)
+
+      local org_key = 'org:' .. i .. ':sessions'
+      for j = 1, 10 do
+        local uid = 'user-' .. ((i + j) % 1000 + 1)
+        local sid = 'session:' .. ((i + j) % 1000 + 1)
+        local zmember = uid .. ':' .. sid
+        local zscore = now - math.random(86400)
+        redis.call('ZADD', org_key, zscore, zmember)
+      end
+
+      local endpoint = '/api/resource'
+      local rate_key = 'ratelimit:' .. user_id .. ':' .. endpoint
+      redis.call('INCR', rate_key)
+      redis.call('EXPIRE', rate_key, 60)
+    end
+
+    return 'OK'
+tested-groups:
+- hash
+- sorted-set
+- set
+- scripting
+
+tested-commands:
+- hgetall
+- hset
+- smembers
+- sadd
+- zrange
+- zadd
+- incr
+- expire
+- get
+- eval
+
+redis-topologies:
+- oss-standalone
+build-variants:
+- gcc:15.2.0-amd64-debian-bookworm-default
+- gcc:15.2.0-arm64-debian-bookworm-default
+- dockerhub
+
+clientconfig:
+  run_image: redislabs/memtier_benchmark:edge
+  tool: memtier_benchmark
+  arguments: >
+    --key-prefix ""
+    --key-minimum 1
+    --key-maximum 100000
+    --data-size-range=400-600
+    --pipeline=1
+    --print-percentiles=50,90,95,99
+    --run-count=1
+    --test-time=120
+    --command="HGETALL session:__key__"
+    --command-key-pattern=R
+    --command-ratio=50
+    --command="HSET session:__key__ userId user-__key__ organizationId org-__key__ role admin email user__key__@example.com name "User __key__" permissions "["read","write"]" lastActivity __timestamp__ ipAddress 192.168.1.__key__ userAgent "Mozilla/5.0" createdAt __timestamp__"
+    --command-key-pattern=R
+    --command-ratio=5
+    --command="SMEMBERS user:__key__:sessions"
+    --command-key-pattern=R
+    --command-ratio=18
+    --command="SADD user:__key__:sessions session-__key__"
+    --command-key-pattern=R
+    --command-ratio=3
+    --command="ZRANGE org:__key__:sessions 0 -1 WITHSCORES"
+    --command-key-pattern=R
+    --command-ratio=10
+    --command="ZADD org:__key__:sessions 1 user-__key__:session-__key__"
+    --command-key-pattern=R
+    --command-ratio=2
+    --command='EVAL "local key=KEYS[1];local limit=10;local window=60;local current=redis.call(\"INCR\",key);if current==1 then redis.call(\"EXPIRE\",key,window) end;if current>limit then return 0 else return 1 end" 1 ratelimit:user-__key__:/api/resource'
+    --command-key-pattern=R
+    --command-ratio=12
+    --hide-histogram
+  resources:
+    requests:
+      cpus: '4'
+      memory: 2g
+
+priority: 150