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

Performance regression going from 1.6 to 1.8 #168

Open
StabbyCutyou opened this issue Apr 15, 2016 · 2 comments
Open

Performance regression going from 1.6 to 1.8 #168

StabbyCutyou opened this issue Apr 15, 2016 · 2 comments

Comments

@StabbyCutyou
Copy link

Hello,

We're updating the memcached gem as we're fairly out of date at this point, and noticed in some particularly hot areas of code, we're now seeing what looks like double the amount of network hops to our memcached cluster, as well as overall 2x to 3x more time spent in memcached code.

I tracked down the differences in the code between the two versions, and found this:

Original code (1.6.x):
https://github.com/arthurnn/memcached/blob/memcached-1.6.1/lib/memcached/memcached.rb#L519-L524

New code (1.8):

def single_get(key, decode)
value, flags, ret = Lib.memcached_get_rvalue(@struct, key)
check_return_code(ret, key)
cas = @struct.result.cas if @support_cas
value = @codec.decode(key, value, flags) if decode
[value, flags, cas]
end

It seems there was a compare and swap call added to every single-item lookup, if you have cas enabled. We do use cas in some places with our memcached client, but those are explicit calls to compare and swap. It seems odd that just because we want to use cas in some place, it's now being used in others as well.

  1. Would the constant calls to cas be responsible for the performance regression? It seems as though it would account for the 2x hits to memcache itself, as well as the extra time spent in memcached code.
  2. Is there a way to disable it? Would it be harmful to do so?

Thanks

@mikhailov
Copy link

@StabbyCutyou I wonder if you found any workaround for this issue? Thank you!

@StabbyCutyou
Copy link
Author

I no longer work for the company where we were having this issue, sorry! I don't believe we ever found a workaround, we just ate the cost and moved on, iirc.

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

No branches or pull requests

2 participants