Redis connection pooling - useful or not?

1,823 views
Skip to first unread message

RaR

unread,
Dec 2, 2016, 2:30:05 AM12/2/16
to Redis DB
Hi, 

I am new to Redis. For my application, I am trying to use Redis. The main confusion I am having is whether to use a single connection to Redis or having a connection pool. I searched the internet and I found a lot of discussions on this, having no clear conclusion on the end.

The major advantage as seen in connection pooling pov is that we can execute multiple commands at a single time.
 
 I don't know about the truthiness of this statement. Redis is Single-threaded, so this gives me a confusion. I think that, 

Even if we have multiple TCP connection established with Redis, we can execute one command at a time, since Redis is single-threaded

Which one is this true? 

And another thing to consider is, some operations in Redis are blocking operations. Can we avoid this by using multiple connections? If a connection is blocked by executing such operation, can we make use of other connections to execute commands in normal way? It will be a lot helpful if I get answers to this. Thanks in advance.

Marc Gravell

unread,
Dec 2, 2016, 3:02:14 AM12/2/16
to redi...@googlegroups.com
The core of redis is indeed single threaded. You won't ever be running fully concurrently against a single server. However, it is also true that the blocking operations will cause problems if you are using a single connection - blocking operations block the connection, not the server itself. Even if you aren't using blocking operations, how effective a single connection will be depends on *how* you are sharing the connection.

- if you take an exclusive lock / semaphore / whatever over the region when you send commands *and wait for replies*, then a single connection could be problematic - you will have latency+bandwidth costs that will significantly impact maximum throughout
- if your connection only takes an exclusive lock / semaphore / whatever *when touching the NIC* (and handles tracking which replies go to which thread), then your maximum throughput on a single connection will be much higher, but things like multi/exec and db-changes (select) become much more complex. Some libraries automate this for you (SE.Redis works this way for example)

Does that help?

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

RaR

unread,
Dec 2, 2016, 3:42:26 AM12/2/16
to Redis DB
Yes. That really does help. I am getting some useful points. 

"We can't run operation concurrently against a single server". So having one or more connection don't affect the number of commands executed at a single time.

"blocking operations block the connection, not the server itself". So it would be helpful using connection pooling when we know we are going to use blocking operation some time. But, if we are sure that we are never going to use blocking operations, using connection pooling having any advantage over there?

And I saw an answer in StackOverflow mentioning "Connection pooling will reduce the effectiveness of Redis pipelining, and due to the stateful nature of the Redis protocol, can be problematic with some commands."
here is the link. I don't understand it completely. How can this affect Redis pipelining?

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages