You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If application executed lot's of concurrent commands due to peak traffic, redis-py creates lot's of connections with upperbound max_connections. The problem is these massive connections are not reaped off by redis-py even though peak traffic is gone.
Currently we can leverage redis node's timeout, so a socket is closed on the server side if it is idle and the client can notice this and close this socket gracefully. But I think this is very low level and tricky because someone can forget or misconfigure timeout on redis, but the impact will be huge if peak traffic occurs.
It'll be better that redis-py support max_idle, min_idle like other redis client(e.g. Lettuce, Jedis, go-redis, ...). So developer can notice this, configure as they needed, reap idle connections automatically by redis-py.
The text was updated successfully, but these errors were encountered:
Related issue: #445
If application executed lot's of concurrent commands due to peak traffic, redis-py creates lot's of connections with upperbound
max_connections
. The problem is these massive connections are not reaped off by redis-py even though peak traffic is gone.Currently we can leverage redis node's
timeout
, so a socket is closed on the server side if it is idle and the client can notice this and close this socket gracefully. But I think this is very low level and tricky because someone can forget or misconfiguretimeout
on redis, but the impact will be huge if peak traffic occurs.It'll be better that redis-py support
max_idle
,min_idle
like other redis client(e.g. Lettuce, Jedis, go-redis, ...). So developer can notice this, configure as they needed, reap idle connections automatically by redis-py.The text was updated successfully, but these errors were encountered: