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

Command icon 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

berdir created an issue. See original summary.

berdir’s picture

Looking 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.

catch’s picture

Serialization 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.

berdir’s picture

Yes, 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.

berdir’s picture

Status: Active » Needs review

  • berdir committed a3289ad5 on 2.x
    feat: #3570199 Allow to execute multiple cache sets in a single pipeline...
berdir’s picture

Status: Needs review » Fixed

This 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.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.