Problem/Motivation
Core is doing a more and more setMultiple() calls, the new streamlined approach on cache writes in 2.x should allow to put multiple of them in a single pipeline.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork redis-3570199
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
berdirLooking at profiling data of a cold cache bootstrap, I can see that 208 setMultiple() calls are expanded to 1209 set() calls (that's on 11.x with #3537962: EntityFieldManager::getFieldDefinitions() per-bundle caching can be expensive.
That's 160ms in total. However, only 26% of that time (41ms) is actually PhpRedis::exec(), the other 60% are serializing the data and compressing it. 41ms is around 1.7% of the entire request time (2.3s). It might be a higher percentage without blackfire overhead, it's specifically around 30ms IO wait, but still, not a lot to gain.
Comment #3
catchSerialization overhead can be reduced with https://www.drupal.org/project/igbinary which might make it more of a relative saving - but I haven't actually tried that module and don't know how much difference it really makes.
Comment #4
berdirYes, I am using igbinary, or at least I thought it was, had a configuration error (#3570217: Update docs to clarify that igbinary serializer override must be done after services.redis.yml include), I fixed that yesterday and confirmed that saves around 8% of space in redis after compression (so comparing serialize + compression vs igbinary + compression). Measured with my updated drush redis report. Didn't manage to reliably compare seralize and unserialize speeds, variation is pretty high. It helps, but it's not huge.
I've also done various benchmarks in #3014514: Make igbinary the default serializer, if available some time ago.
Comment #6
berdirComment #8
berdirThis was trickier than expected, but I'm pretty confident in our test coverage, which managed to uncover a weird race condition of a pipeline happening within a pipeline which failed hard.