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

connection pooling #84

Closed
tanner0101 opened this issue Feb 26, 2018 · 8 comments
Closed

connection pooling #84

tanner0101 opened this issue Feb 26, 2018 · 8 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@tanner0101
Copy link
Member

Allow connections to be pooled and re-used.

@tanner0101 tanner0101 added the enhancement New feature or request label Feb 26, 2018
@tanner0101 tanner0101 self-assigned this Feb 26, 2018
@tanner0101 tanner0101 added this to Backlog in Vapor 3 Feb 26, 2018
@John-Connolly
Copy link
Contributor

I think pooling would only be useful with pub/sub or blocking commands, which is probably not the most common scenario. It would be nice if this was opt in, so it doesn't exhaust connection limits on cloud providers.

@jdmcd
Copy link
Member

jdmcd commented Feb 27, 2018

Exhausting connection limits on cloud providers is actually what I was worried about. I use Redis to store session tokens and I don't my whole massive setup to come down just cause the caching service is out of connections (and is only used on session lookup). I see what you're saying though. I'd love to see a middleground

@tanner0101
Copy link
Member Author

Maybe we can have it configurable such that if you set max connections to ‘nil’ it will just create a new connection each time. Note also the connection pooling is for the KeyedCache impl. Creating a Redis client manually will not be affected by this.

@Joannis
Copy link
Member

Joannis commented Feb 27, 2018

I don't see a reason to pool redis connections since they support pipelining. There's little to no performance gain. Actually, I think it'll worsen the performance very slightly.

@John-Connolly
Copy link
Contributor

Yeah the only way I see it being useful is for blocking commands. I believe blocking commands put the client in a blocked state and the client is unable to send or receive other commands until that blocking call returns or times out.

@Joannis
Copy link
Member

Joannis commented Feb 27, 2018

I agree, but we don't support blocking operations in the Redis Client. We have a separate static method for setting up a blocking client for pub/sub.

@John-Connolly
Copy link
Contributor

I see, creating a new RedisClient instance for those commands makes more sense anyways. The only problem I see is there is no way to send commands before subscribe is sent, like AUTH or SELECT for instance.

@tanner0101
Copy link
Member Author

Fixed by #95

@tanner0101 tanner0101 added this to the 3.0.0-rc.2.1 milestone Mar 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants