Skip to content

Conversation

@phenomax
Copy link

This PR makes a first step, solving the performance issues adressed in #238 by using the redis SCAN command instead of the KEYS command, which does not block the main queue.

Taken from redis documentation

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code.

@phenomax phenomax changed the title Improve performance of redis command - #238 Improve performance of redis command queue - #238 Jan 11, 2018
@zone117x
Copy link
Owner

Thanks for identifying this.
I'm not sure about the arbitrary count limit. Could we make it iterate over scan commands until empty as suggested here https://stackoverflow.com/a/33167701 ?

@phenomax
Copy link
Author

Hey!
I also thought about that, but using a very high count limit does not affect performance at all.
We also would have to send the commands multiple times (until we got a full iteration), instead of just using one command.
So afaik going with a high count value is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants