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

Non-blocking Redis calls: optimize pipelines by flushing just once #86

Merged
merged 1 commit into from
Mar 6, 2019

Conversation

davidor
Copy link
Contributor

@davidor davidor commented Mar 6, 2019

This PR improves performance by making sure that we only call .write on the underlying socket just once per pipeline instead of per command.

Pipelines are not implemented in async-redis so we need to add the patch in our codebase. The idea is to contribute the pipelines functionality to the async-redis lib at some point.

Notice that the base branch of this PR is the async integration branch, not master.

Requires need to be reordered to add the method to the RESP class after
it has been defined.
@davidor davidor requested a review from unleashed March 6, 2019 16:49
Copy link
Contributor

@unleashed unleashed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👽 👽 🙅‍♀️ 🤹‍♀️ 👽 👽 💣 💥 💢 😭 🌋 :goberserk: 🔫 🔪 very reluctantly ok.

@unleashed unleashed merged commit 569ab0d into async Mar 6, 2019
@bors bors bot deleted the optimize-pipelines-by-flushing-once branch March 6, 2019 17:50
bors bot added a commit that referenced this pull request Sep 30, 2019
96: Non-blocking redis calls using redis-async lib r=unleashed a=davidor

This is an integration branch. It contains: #77 , #86 , #92 , #93 .
~It cannot be merged yet. We need to drop support for Ruby < 2.2.7 first.~

Co-authored-by: David Ortiz <z.david.ortiz@gmail.com>
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.

None yet

2 participants