Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best practices for number of connections #558

Closed
dirkbonhomme opened this issue Feb 19, 2014 · 4 comments
Closed

Best practices for number of connections #558

dirkbonhomme opened this issue Feb 19, 2014 · 4 comments
Labels

Comments

@dirkbonhomme
Copy link

I was wondering what the best strategy would be to connect to a Redis server during the execution of a script:

  • Create one instance and share that across all code that requires Redis (= 1 connection to Redis)
  • Create different instances for read, write and polling requests (= 3 connections to Redis)

Are there any performance gains from having multiple connections?

Apart from that, would it make any difference to have a separate connection for code that relies a lot on BRPOPLPUSH?

Thanks

@brycebaril
Copy link
Contributor

The connections are fairly light, so having a few around is fine. The biggest thing you'll want to avoid is having too many for generic commands where you might end up defeating pipelining. This feature benefits from sending as many commands as possible over the same connection.

Usually one or two clients are sufficient. The typical application I write using Redis has two clients, one for any subscriptions (because once a subscriber the client can no longer send other types of commands), and one for everything else. This covers almost all use cases.

If you rely on the blocking operations (BRPOP, BLPOP, BRPOPLPUSH) but want to do other work in parallel on whatever you're blocked on, you'll want a separate client, as using any of those commands when the queue is empty will prevent that client connection from doing anything else.

If you are using WATCH pretty much at all, you're best off using a separate client, possibly for each WATCH transaction.

There are some other uses cases I'm probably forgetting right now, but these are the most common.

But for the most part, for generic reads/writes a single client should be sufficient.

@dirkbonhomme
Copy link
Author

Thanks for the detailed response. It explains everything I wanted to know :)

@ankitchaudhury
Copy link

I am developing a common caching service which will be used by many micro services(Clients for me). How many number of connections should I create? Is 1 connection per application sufficient?

@BridgeAR
Copy link
Contributor

One connection is perfect. The performance will always be the same no matter if you use more than one client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants