valkey + gitea + long build

valkey/config.yaml

@@ -0,0 +1,135 @@
+# Valkey HA chaos/soak config — spicy edition.
+#
+# 13 workers per container. With Zerops scaling to 10 replicas, that's
+# ~130 concurrent connections × short intervals = serious load on
+# HAProxy, Sentinel, and the Valkey master.
+#
+# Each $ZEROPS_Number replica gets its own DB and its own channel suffix
+# (handled in main.go::applyZeropsOverrides), so the 10 containers don't
+# step on each other's keyspace or pub/sub traffic.
+#
+# Topology:
+#   6379 = read/write plaintext (master)
+#   6380 = read/write TLS       (master)
+#   7000 = read-only plaintext  (replicas via HAProxy)
+#   7001 = read-only TLS        (replicas via HAProxy)
+#
+# Roughly half the workers run over TLS so each ingress path gets
+# exercised under load.
+#
+# Workload mix:
+#   - 1× readwriter (write + read-after-write on master)
+#   - 2× pure writer (separate TCP sessions — stress the master)
+#   - 1× master-side reader (does master serve GETs under load?)
+#   - 4× replica-side reader (stress replicas + verify replication catches up)
+#   - 2× publisher on two distinct channels (one slow, one tight)
+#   - 2× master-side subscriber (one per channel)
+#   - 1× replica-side subscriber (topology probe — should receive 0 msgs)
+
+workers:
+  # ---- write path (3 connections) ----------------------------------------
+  - name: rw-main
+    role: readwriter
+    host: valkeyha.zerops
+    port: 6379
+    db: 0
+    interval: 20ms
+
+  - name: rw-burst-1
+    role: writer
+    host: valkeyha.zerops
+    port: 6380
+    tls: true
+    interval: 3ms
+
+  - name: rw-burst-2
+    role: writer
+    host: valkeyha.zerops
+    port: 6379
+    interval: 3ms
+
+  # ---- master-side reader (sanity that master also serves reads) ---------
+  - name: ro-master
+    role: reader
+    host: valkeyha.zerops
+    port: 6380
+    tls: true
+    interval: 5ms
+
+  # ---- replica-side reader fan-out (4 connections) -----------------------
+  - name: ro-1
+    role: reader
+    host: valkeyha.zerops
+    port: 7000
+    interval: 2ms
+  - name: ro-2
+    role: reader
+    host: valkeyha.zerops
+    port: 7001
+    tls: true
+    interval: 2ms
+  - name: ro-3
+    role: reader
+    host: valkeyha.zerops
+    port: 7000
+    interval: 3ms
+  - name: ro-4
+    role: reader
+    host: valkeyha.zerops
+    port: 7001
+    tls: true
+    interval: 3ms
+
+  # ---- pub/sub: two channels at different cadences -----------------------
+  - name: pub-bus
+    role: publisher
+    host: valkeyha.zerops
+    port: 6379
+    channel: "vk:chaos:bus"
+    interval: 5ms
+
+  - name: pub-fast
+    role: publisher
+    host: valkeyha.zerops
+    port: 6380
+    tls: true
+    channel: "vk:chaos:fast"
+    interval: 2ms
+
+  - name: sub-bus
+    role: subscriber
+    host: valkeyha.zerops
+    port: 6380
+    tls: true
+    channel: "vk:chaos:bus"
+
+  - name: sub-fast
+    role: subscriber
+    host: valkeyha.zerops
+    port: 6379
+    channel: "vk:chaos:fast"
+
+  # ---- memory bloater ----------------------------------------------------
+  # Writes 8 KB of random bytes to a fresh key every 10ms with NO TTL.
+  # ~800 KB/sec per container × 10 containers = ~8 MB/sec growth on the
+  # master. Watch used_memory climb. Keys land under vk:chaos:bloat:<seq>
+  # so they don't pollute the durability ledger. To reset, FLUSHDB the
+  # affected DB (or each per-replica DB if running in Zerops).
+  # - name: bloat-1
+  #   role: bloater
+  #   host: valkeyha.zerops
+  #   port: 6379
+  #   interval: 10ms
+  #   valueBytes: 8192
+
+  # ---- topology probe ----------------------------------------------------
+  # Subscriber on the read-only VIP. Valkey 7.2 + Sentinel does not
+  # replicate pub/sub from master to replicas, so this should stay at
+  # msgs=0 the entire run. If it ever ticks up, replication semantics
+  # changed.
+  - name: sub-replica
+    role: subscriber
+    host: valkeyha.zerops
+    port: 7001
+    tls: true
+    channel: "vk:chaos:bus"