Opened 6 months ago

Closed 6 months ago

#35516 closed New feature (wontfix)

Setting Client Name for Redis Connections

Reported by: Aswin1105 Owned by: nobody
Component: Core (Cache system) Version: 5.0
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I encountered an issue in Django when managing multiple services connecting to Redis. To effectively monitor and maintain the number of connections each service or Django instance has, it would be beneficial to utilize the client_name feature in redis-py.

However, I found that the current documentation does not provide a straightforward method to set the client_name in cache backend settings. After delving into the django.core.cache code, I discovered that we can pass the client_name parameter through the CONNECTION_POOL_KWARGS option within the cache settings. This parameter is then propagated to the base redis-py package.

By enabling the client_name for Redis connections, we can easily reference and manage connections, improving the overall maintainability and monitoring of Redis connections across services.

I propose adding a dedicated key for client_name under the CACHES setting in Django, particularly under the default cache configuration. Furthermore, including this in the documentation as a best practice would save time and effort for developers in the future.

I will raise this django-redis also, But before that we will discuss and find the best change

Change History (3)

comment:1 by Clinton Christian, 6 months ago

Top level keys in the Django CACHES setting are keys that map across all backends. So adding CLIENT_NAME as a top level key would mean having to add this to all backends. However, not all backends support, or have an analogue for, CLIENT_NAME.

Last edited 6 months ago by Clinton Christian (previous) (diff)

comment:2 by Aswin1105, 6 months ago

You are correct, Whatever cache back-end they use, I think if it is external, it will be a good practice to name the connections established. For other backends, i think it wont create any harm in sending extra parameters?, until we are using some external package for supporting that (like in the case REDIS, django-redis).

Also, another case, even for a single service, redis can be connected through different means like channel-redis has its own connection and core.cache has its own connection. These different connections can be differentiated and analysed if we name them.

The reason, why am i enforcing this change is that, i have made multiple django services, each having same redis as a the cache backend. I faced problem, when connection closed by server happened. I tried to find which service is having stale connections or too many connections etc. But i couldnt as these connections are unnamed.

But thanks for the reply and i accept it too. Also, if you feel the change is unnecessary, u can close it. But i think the common cache backend in production in Redis. So it may need this feature.

comment:3 by Sarah Boyce, 6 months ago

Component: UncategorizedCore (Cache system)
Resolution: wontfix
Status: newclosed
Type: UncategorizedNew feature

Hi Aswin1105, thank you for raising this. Sounds like we need some discussion to decide if this makes sense to be added to Django.

For cases like this, the recommended path forward is to first propose and discuss the idea/request with the community and gain consensus. To do that, please consider starting a new conversation on the Django Forum, where you'll reach a wider audience and likely get extra feedback.

I'll close the ticket for now, but if there is a community agreement for the feature request, you are welcome to come back to the ticket and point to the forum topic, so we can then re-open it. For more details, please see the documented guidelines for requesting features.

Thanks!

Note: See TracTickets for help on using tickets.
Back to Top