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

Is it not possible to use pipeline in get_many #614

Open
debugger22 opened this issue Jun 28, 2022 · 3 comments
Open

Is it not possible to use pipeline in get_many #614

debugger22 opened this issue Jun 28, 2022 · 3 comments
Labels

Comments

@debugger22
Copy link

I am using get_many to retrieve multiple keys at the same time. Surprisingly unlike set_many, it calls the Redis individually for each key in the list.

Is there a way to optimize this behavior?

@WisdomPill
Copy link
Member

it is using pipeline so it sends one command to the server.

Have a look here.

Do you think it is slow?

Probably using MSET is faster but it complicated things because of preprocessing of keys and versioning.

Do you fancy opening a PR for switching over to MSET

@tony
Copy link
Member

tony commented Nov 25, 2022

Thank you

Have a look here.

That's just a link to redis docs - I find their docs a bit tricky to connect to real world scenarios 😆. When I opened this issue I was more curious about django-redis.

It would be great to see more: e.g. links to the current source / explanation of the codepath for django-redis' implementation of that.

@WisdomPill
Copy link
Member

get_many (source here) uses MGET command which has a complexity of O(1) from django-redis perspective and a complexity of O(N), the complexity is all on redis side so if you are asking for many keys then it can be slow because of size of values and number of values.

While set_many (source here) just recently started using PIPELINE in order to improve total RTT.

Are you having issues reading many keys of writing?

To be honest I don't see a reason why it could be slow and a way to make it faster,
but I would be happy to be proven wrong.

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

3 participants