Expected Number of Redis Connections
dotnetnate is experiencing high Redis connection usage across 20 Discourse instances, averaging 17 connections per instance, which is hitting the SKU connection limits. pfaffman advises against sharing a Redis service between instances, citing potential issues with feature leakage between sites. However, dotnetnate disputes this, suggesting that Redis itself does not leak, and the issue lies with the application. david agrees with pfaffman, referencing a meta Discourse topic that recommends using a separate Redis instance for each deployment. dotnetnate acknowledges this and acknowledges that using separate Redis instances would have been a safer approach.
We are running a number of Discourse instances on Azure and are using a shared Redis service for this. For around 20 instances, I see a peak of 350 connections to Redis and it’s hovering around 330-340, averaging out to around 17 connections per instance. This hits the SKU connection limits pretty hard, particularly considering Redis is underutilized in both CPU and memory.
Is this ratio expected?
This is not recommended. There is some redis feature that is used that will leak between sites, I’ve been told more than once. I’m not sure how to find that topic, though.
I ran across one that was counter to that and stated when multisite was used (although these are just individual deployments), using a single Redis instance is fine. Redis doesn’t inherently “leak” - the app would have to be doing that.
You must have a separate redis for each discourse deployment.
Thanks. Yeah, I’ve generally made applications do that by default to avoid such issues - seems that would’ve been a safer default, but it is what it is.