It's not clear if the wallclock savings was consistent over multiple runs.
And by moving one look-up out of redis into ruby, doesn't seem like the right thing to do. That increases complexity by now requires an application layer to process the data source.
I'd like to see how this compares with just simply increasing list-max-ziplist-entries.
The times were consistent, clone the repo and run `rake bm` to try it. max-ziplist cannot be set to the order of millions, since redis does have to unzip it on every access and you wouldn't get any range lookup boost. You can implement this in redis lua if app layer separation is a concern.
Comments
It's not clear if the wallclock savings was consistent over multiple runs.
And by moving one look-up out of redis into ruby, doesn't seem like the right thing to do. That increases complexity by now requires an application layer to process the data source.
I'd like to see how this compares with just simply increasing list-max-ziplist-entries.
The times were consistent, clone the repo and run `rake bm` to try it. max-ziplist cannot be set to the order of millions, since redis does have to unzip it on every access and you wouldn't get any range lookup boost. You can implement this in redis lua if app layer separation is a concern.
Ah in that context, this makes more sense. Thanks for the reply.