#Config Redis lifetime in .NET project

4 messages · Page 1 of 1 (latest)

timber tree
#

Do you guys know why when we config lifetime for redis service in .NET project, we always using singleton lifetime, why not using transient or scope. What's the advantage of using it ? Does it only by redis mostly support single thread processing or any other reasons? Thank you

timber tree
#

@next oasis Hi Steve, do you know about this

empty kettle
#

It's not only about .NET but the common sense for most Redis Clients (node, python, c++...)

  • the client connect is very slow operation (and quite heavy for the server itself, when multiplied by thousands of connections), so if you configure to use temporary connection you do 2 bad thing - you app will be awaiting for responses from the server, and the server will have a spike in CPU usage -not visible when low number of users but could be significant on a bigger scale.
  • another reason - some operations tend to have a constant connection (blocking reading, pubsub...) so you bound to be connected all the time otherwise you miss something.
  • it's possible to have a case when temporary (or scoped) connection is reasonable,e.g. - when starting up your app you only need to read a session configuration from redis and when shutting down - you might want to save it back, so you can connect-read/write-close in this case just to save resources.
next oasis
#

As @empty kettle said, the connection process is very expensive. In our case here, we have two connections per Redis Server that your client is configured to connect to. One for your interactive commands (SET/GET etc. . .) and one for subscriptions. And yes, everything is multiplexed over one connection. However the client is very much not single threaded, each thread in your application can enqueue requests to Redis both synchronously and asynchronously, those commands are all handled in parallel within the client, even if they. end up going over the same connection, Redis allows you to send multiple commands over the same connection at the same time (even within the same packets), the wire protocol is flexible enough that can parse out what it's supposed to do across multiple commands. So, while it might be a single connection to Redis ( and Redis itself is single-threaded ) the client can execute multiple commands concurrently.