← RedisCONTENT HISTORY

Update to Redis

Snapshot Sep 30, 2026 · 23:01 UTC · version 1.4.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Redis client and connection guidance covering connection pooling, multiplexing, pipelining, client-side caching with RESP3, avoiding slow commands (KEYS, SMEMBERS, HGETALL), and tuning socket timeouts. Use when configuring a Redis client (redis-py, Jedis, Lettuce, NRedisStack), batching commands for throughput, eliminating per-request connection creation, iterating large keyspaces with SCAN, enabling client-side caching for read-heavy workloads, or setting connect and read timeouts.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 234
    },
    {
      "relative_path": "references/blocking.md",
      "size_in_bytes": 1817
    },
    {
      "relative_path": "references/client-cache.md",
      "size_in_bytes": 2034
    },
    {
      "relative_path": "references/pipelining.md",
      "size_in_bytes": 1103
    },
    {
      "relative_path": "references/pooling.md",
      "size_in_bytes": 1921
    },
    {
      "relative_path": "references/timeouts.md",
      "size_in_bytes": 1366
    }
  ],
  "name": "redis-connections",
  "skill_md_contents": "---\nname: redis-connections\ndescription: Redis client and connection guidance covering connection pooling, multiplexing, pipelining, client-side caching with RESP3, avoiding slow commands (KEYS, SMEMBERS, HGETALL), and tuning socket timeouts. Use when configuring a Redis client (redis-py, Jedis, Lettuce, NRedisStack), batching commands for throughput, eliminating per-request connection creation, iterating large keyspaces with SCAN, enabling client-side caching for read-heavy workloads, or setting connect and read timeouts.\nlicense: MIT\n---\n\n# Redis Connections\n\nClient-side guidance for talking to Redis efficiently: how to share connections, how to batch commands, which commands not to call in production, when to turn on client-side caching, and how to set timeouts that fail fast without breaking healthy traffic.\n\n## When to apply\n\n- Creating or reviewing a Redis client setup (redis-py, Jedis, Lettuce, go-redis, NRedisStack).\n- Making many small Redis calls and wondering where the latency is going.\n- Iterating large keyspaces, sets, hashes, or lists.\n- Enabling client-side caching for hot keys.\n- Tuning connect / read / write timeouts.\n\n## 1. Pool or multiplex — never one connection per request\n\nThe single biggest mistake in Redis client code is opening a new TCP connection for every operation. Always either:\n\n- **Pool** — keep N persistent connections that the application leases per call (redis-py `ConnectionPool`, Jedis `JedisPooled`, go-redis client).\n- **Multiplex** — share a single connection across all requests (Lettuce, NRedisStack).\n\n| Style | Used by | Note |\n|---|---|---|\n| Pool | redis-py, Jedis, go-redis | Each lease blocks if pool exhausted; size the pool to your concurrency |\n| Multiplex | Lettuce, NRedisStack | Single connection; **cannot** carry blocking commands like `BLPOP` |\n\n```python\n# redis-py — connection pool\npool = redis.ConnectionPool(host=\"localhost\", port=6379, max_connections=50)\nr = redis.Redis(connection_pool=pool)\n```\n\nSee [references/pooling.md](references/pooling.md) for Python + Java + Lettuce examples.\n\n## 2. Pipeline bulk work\n\nFor N commands that don't depend on each other's results, send them as a single batch with pipelining. One round-trip instead of N.\n\n```python\npipe = redis.pipeline()\nfor user_id in user_ids:\n    pipe.get(f\"user:{user_id}\")\nresults = pipe.execute()\n```\n\nUse **non-transactional** pipelining for performance, and `pipeline(transaction=True)` only when you actually need atomicity (see redis-core's transactions guidance).\n\nSee [references/pipelining.md](references/pipelining.md).\n\n## 3. Avoid commands that scan everything\n\nAnything that walks the whole keyspace (or a whole large container) blocks the server. Use incremental variants instead.\n\n| Don't | Use |\n|---|---|\n| `KEYS pattern` | `SCAN` cursor loop |\n| `SMEMBERS large_set` | `SSCAN` |\n| `HGETALL large_hash` | `HSCAN` |\n| `LRANGE 0 -1` on a huge list | Paginate (`LRANGE 0 100`) |\n\n```python\ncursor = 0\nwhile True:\n    cursor, keys = redis.scan(cursor, match=\"user:*\", count=100)\n    for key in keys:\n        process(key)\n    if cursor == 0:\n        break\n```\n\n**Blocking commands (`BLPOP`, `BRPOP`, `BLMOVE`) are different** — they intentionally wait for data and are fine for queue consumers, but always pass a timeout, and don't issue them on a multiplexed connection (Lettuce, NRedisStack).\n\nSee [references/blocking.md](references/blocking.md).\n\n## 4. Client-side caching for hot keys\n\nFor data that's read often and written rarely (config, feature flags, sessions on every request), enable RESP3 client-side caching. The client keeps a local copy and the server invalidates it on writes — saving the round trip for hot reads.\n\n```python\nclient = redis.Redis(\n    host=\"localhost\",\n    port=6379,\n    protocol=3,                                    # RESP3 is required\n    cache_config=redis.CacheConfig(max_size=1000),\n)\n```\n\nSkip it for write-heavy workloads or data that changes constantly — the invalidation traffic overruns the savings.\n\nSee [references/client-cache.md](references/client-cache.md).\n\n## 5. Set explicit timeouts\n\nDefaults vary by client and may be too generous. Pick values that match the *application's* failure model:\n\n```python\nr = redis.Redis(\n    host=\"localhost\",\n    socket_connect_timeout=2.0,   # fail fast on dead nodes\n    socket_timeout=5.0,           # tune to expected operation time\n    retry_on_timeout=True,\n)\n```\n\nRule of thumb: connect timeout shorter than read/write timeout. Tight timeouts + retry-on-timeout for latency-sensitive paths; longer timeouts for batch jobs.\n\nSee [references/timeouts.md](references/timeouts.md).\n\n## References\n\n- [Redis: Connection Pools and Multiplexing](https://redis.io/docs/latest/develop/clients/pools-and-muxing/)\n- [Redis: Pipelining](https://redis.io/docs/latest/develop/use/pipelining/)\n- [Redis: SCAN](https://redis.io/docs/latest/commands/scan/)\n- [Redis: Client-side caching](https://redis.io/docs/latest/develop/clients/client-side-caching/)\n- [Redis: Clients](https://redis.io/docs/latest/develop/clients/)\n"
}

SHA-256 of public snapshot: 3e9b51fa34966ef50a72c8a4000afa349d349ff8de22e63f8bf7930610e99616