Skip to content

hotfix/v8_conn_pool_check_fd #2431

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

Merged
merged 7 commits into from
Feb 9, 2023

Conversation

hardeyhe
Copy link

@hardeyhe hardeyhe commented Feb 8, 2023

hello, our team hopes to fix this wrong connection problem in v8 and add a tag on this basis
reference mr: #1824

@monkey92t
Copy link
Collaborator

monkey92t commented Feb 9, 2023

Oh, we neglected to port the PR to v8, thanks for the addition.
I did a test at the time, connCheck will cause a 20% performance loss.
If you have any questions, don't hesitate to ask!

@vmihailenco
Copy link
Collaborator

Looks good. Don't forget to remove the Draft label once this is ready.

@hardeyhe hardeyhe marked this pull request as ready for review February 9, 2023 07:05
@hardeyhe
Copy link
Author

hardeyhe commented Feb 9, 2023

Oh, we neglected to port the PR to v8, thanks for the addition. I did a test at the time, connCheck will cause a 20% performance loss. If you have any questions, don't hesitate to ask!

That's really bad, so don't you plan to fix this problem in v8?

@hardeyhe
Copy link
Author

hardeyhe commented Feb 9, 2023

Oh, we neglected to port the PR to v8, thanks for the addition. I did a test at the time, connCheck will cause a 20% performance loss. If you have any questions, don't hesitate to ask!

That's really bad, so don't you plan to fix this problem in v8?

Can I add an option to ConnPool(like strictConnCheck bool)? which is disabled by default but if enabled, it will use connCheck in isStaleConn() method. This way, neither the default behavior will be changed nor the performance loss introduced, and the excellent features of v9 can be introduced, leaving the choice to the user. Thanks reply.

@monkey92t
Copy link
Collaborator

NO, although we lost 20% of performance, go-redis still maintains a high performance, which is not much different from redis-benchmark

20% performance reduction, in exchange for a stable and effective network connection for us, it is worth it.

Copy link
Collaborator

@monkey92t monkey92t left a comment

Choose a reason for hiding this comment

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

Looks very good 👍🏻

@monkey92t monkey92t merged commit f7b3619 into redis:v8 Feb 9, 2023
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.

3 participants