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

Switch from deadpool-redis to a home-grown alternative #482

Closed
aumetra opened this issue Jan 31, 2024 · 0 comments · Fixed by #485
Closed

Switch from deadpool-redis to a home-grown alternative #482

aumetra opened this issue Jan 31, 2024 · 0 comments · Fixed by #485
Labels
enhancement New feature or request

Comments

@aumetra
Copy link
Member

aumetra commented Jan 31, 2024

The next version of redis-rs will deprecate aio::Connection in favour of its multiplexed counterpart.
With that deprecation there is no benefit of using a traditional pooling system like deadpool since these systems are built on the premise of quickly "borrowing" something from a pool and then returning the object.

These borrows are exclusive since they give you temporary ownership, which isn't utilizing a multiplex-ready connection optimally.


Solution

A new custom solution which internally looks something like this:

trait Strategy<Obj>: Send + Sync {
    fn choose(&self, objs: &[Obj]) -> &Obj;
}

struct PoolInner<Obj> {
    strategy: Box<dyn Strategy<Obj>>,
    objects: Box<[Obj]>,
}

pub struct Pool<Obj> {
    inner: Arc<PoolInner<Obj>>,
}

impl<Obj> Pool<Obj> {
    pub fn acquire(&self) -> Obj {
        let chosen = self.inner.strategy.choose(&self.inner.objects);
        chosen.clone()
    }
}

Something like that. This will use a strategy to choose an object from a slice of objects which is then subsequently cloned.
An example strategy could be a round-robin strategy using an atomic integer to increment modulo the pool length so you don't have to reset the counter ever.

That way you can ensure an optimal utilization of all connections since in a highly contented scenario, connections can serve N in-flight requests at the same time.

@aumetra aumetra added the enhancement New feature or request label Jan 31, 2024
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

Successfully merging a pull request may close this issue.

1 participant