Pool vs Mutex

[rif]

Are there any advantages of using a pool in a single redis - multiple goroutines context vs using a Mutex to protect access to it? (I am asking this considering redis is using a single thread to respond)

[mediocregopher]

My understanding of redis' internals is that modifications to the data-set itself is done single-threaded, but not necessarily the reading/writing from the connections. So one thread might read and decode a command, pass that command to the data-set thread, and the result would then be passed back to the first thread to be encoded and written to the client.

This could be wrong, and if it is then you're right there's probably not a whole lot of benefit, but if it is then for large commands/responses there's definitely a decent benefit. I'll try and look into it more in the next couple days.

[rif]

Thanks a lot for your response, indeed any additional information would be very interesting.

[mediocregopher]

I did some research into this, you are correct that redis is entirely single-threaded (although I saw some mentions of it doing async-io with the kernel, which might be what confused me in the past).

The response to this question is really good and is worth reading: http://grokbase.com/t/gg/redis-db/12caz7aceg/clients-that-are-multi-threaded-benefits

The gist of it is that pooling connections allows you to not have to wait on the round-trip time over the network. So if you have two requests to do, if you lock on the connection your timeline will look like:

• client -> network -> redis
• redis reads off socket, does command1, and writes back to socket
• redis -> network ->- client
• client -> network -> redis
• redis reads off socket, does command2, and writes back to socket
• redis -> network -> client

While if you're using a connection pool it would look like:

• client1 -> network -> redis || client2 -> network -> redis
• redis reads off socket, does command1, and writes back to socket
• redis reads off socket, does command2, and writes back to socket || redis -> network -> client1
• redis -> network -> client2

In a high qps scenario saving those round-trip-times can definitely help.

Hopefully this answered your question, let me know if you have any more!