Business Cache

cache only controls business-data caches: small objects such as users, rooms, usernames, and permissions. It reduces database reads. It does not cache media bytes.

Media proxy Range-slice caching is configured separately in Proxy Slice Cache.

Example

cache:
  l1_capacity: 5000
  l1_ttl_seconds: 300
  l2_ttl_seconds: 300
  username_cache_capacity: 10000
  username_cache_ttl_seconds: 3600
  permission_cache_capacity: 20000
  permission_cache_ttl_seconds: 300

Fields

Field	Default	Change when	Risk
cache.l1_capacity	5000	One node has enough memory and user/room cache churn is visible	Too low increases database reads; too high increases memory use
cache.l1_ttl_seconds	300	In-process entries should expire faster or stay longer	Too long delays visible changes; too short increases database pressure
cache.l2_ttl_seconds	300	Redis is configured and business cache reuse should last longer	Has no effect without Redis
cache.username_cache_capacity	10000	Login, member lists, or display paths frequently resolve usernames	Too low repeatedly falls back to the database
cache.username_cache_ttl_seconds	3600	Username update frequency and lookup pressure do not match defaults	Too long delays username changes; too short lowers hit rate
cache.permission_cache_capacity	20000	Permission cache capacity needs explicit tuning	Too low increases permission-read overhead
cache.permission_cache_ttl_seconds	300	Permission changes should propagate faster or slower	Too long delays permission visibility

Single-Node Production

Defaults are suitable for most single-node production deployments. Confirm PostgreSQL, Redis, and indexes first, then tune cache capacities if database read pressure is still high.

If Redis is not configured, SyncTV still works. L2 cache is simply inactive.

Restart Required

Yes. cache is startup configuration; restart SyncTV after changing it.