enable compression by default with memcached extension

Thanks for the patch; I'll do some new load testing to compare and confirm it's a win.

Here are some observations using Gzip compression with Database backend.

@Jeremy pointed me over to https://github.com/tag1consulting/drupal-loadtest which is what they use for load testing, if anyone is game to do this.

Maybe following points can improve the significance of the test results regards performance impact by compression:

• Set size threshold to 0. Currently at 100 bytes as its documentation points out, but it seems Memcached does not have an option to change this threshold :( Memcache does though.
• Ensure a 0% eviction rate by setting the Memcache size to a very high limit )if not yet done.

I'm trying to find some time playing around with the compression functions provided by the zlib extension inside the Memcache backend service, instead of using Memcached's built in compression. Probably worth checking out in case serialization is not the problem there...

I'm sorry that I can't deliver well-defined test results here atm, but I took some time playing around a little bit on a D8 project using 180+ modules. On its frontpage - not using page and dynamic page cache - 1582 config items, 135 discovery items, 7 bootstrap items, 87 entity items, 148 data items, 61 render items, 65 default items and 8 menu items are being loaded from the cache when cache items are valid. My findings on that:

1. Overall, I had a very high volatility (up to 10%) on loading times due to varying environment processes, regardless whether compression was enabled or not. Yet I could see that ...
2. ... When having a small Memcache size of 64M, enabled compression significantly improved performance due to the reduction of evictions. Loading time was reduced from about 700 ms down to 500 ms on average (read).
3. ... Cache writes with enabled compression are visibly slower, but the volatility on this project's loading time is still so high that this makes barely a difference. For me, this difference is subjectively negligible.

I estimate (2.) for not being true at production mode, as the Memcache size would still be too small to handle all variants of cached items. I think the eviction rate would still be too high at this size. Luckily the Memcache size is way larger in production mode, yet having many evictions due to a very busy render and data cache bin. I already have worked against that with the help of the Cache Split module. Especially the render cache can be split up very well.

I also tried with zlib compression by adding a serialization+gzcompress (level 6 and level 3) and unserialization+gzuncompress step before get/sets, not using Memcached's built in compression. But this was visibly slower than Memcached's built in compression (up to 300 ms difference, but I could not exclude the volatility), maybe because it compresses all items including those which are smaller than 100 bytes. So I think my zlib approach from above is not a valuable alternative.

Next time I will try to reduce the volatility, and analyze the method's overhead with the help of Xhprof.

AS a result from my observations: For this project, using PHP 7.1, I would enable Memcached's built in compression in favor of

• reduced network overhead, as there is a lot going on with PHP, Memcache and Database communications.
• reduced eviction rate (would need to observe though at busy times)
• negligible performance loss (subjectively, will see what Xhprof says)

Edit: I fetched some numbers via Xhprof - 3 times - out of Drupal\memcache\MemcacheBackend::getMultiple regards the above mentioned frontpage (all numbers are milliseconds):

Compression disabled:
(1) Request after drush cr: 183, 267, 262
(2) Request after (1): 170, 137, 195
Compression enabled:
(1) Request after drush cr: 198, 244, 250
(2) Request after (1): 192, 135, 135
So still the volatility thing here.

Then, looking at Drupal\memcache\DrupalMemcached::set I was quite surprised:

Compression disabled:
(1) Request after drush cr: 700, 765, 509
Compression enabled:
(1) Request after drush cr: 533, 520, 451
I'm not sure, it could be that the environment processes were going wild when I looked at disabled compression. It just seems to me that compression is a completely negligible performance impact.
I guess, the more complex the project, the higher its volatility and by this, I would recommend using compression.

I think a big benefit of using compression is that it's less likely you'll exceed the default memcache item size limit of 1MiB. The D7 version of this module accounts for items larger than that by splitting up the data into multiple chunks and then re-constructing them. There's some work to get that same procedure into the D8 branch as well but it's not committed yet.

I did a short benchmark on two quite big D8 sites (local memcached). The difference with compression was not huge and for my test cases it even seemed to be a little faster and consistent without compression.

Compression offers an advantage when the memcache server(s) are not installed on the same machine as the webserver and network throughput becomes more important.

I guess it is not really important if compression becomes the default or not. It is more important to document the options (with advantages and disadvantages). For really big sites owners should do benchmarks and compare for themselves anyway.

@bkosborne: This was missing for D8 a long time - happy to see this is on the way now.

I want to re-iterate my point in #9. I recently found out that the PHP "memcache" extension has had compression enabled by default since version 3.0.3. Users that switch to PHP 7 and must use the Memcached extension will likely suddenly stop using compression, since the memcached extension does NOT enable it by default.

As a result, much less data will be available for storage, so evictions will be higher.

bkosborne, you are correct. We are on the safer side if compression is on as a default.

The 8.x patch didn't apply. I've re-rolled it, and also instead of removing all the mentions of compression, changed the default to TRUE and updated the documentation to reflect the choice.

Also, generally agreed on enabling compression by default. 8.x stores things like entities which potentially have a lot of long text fields that are very compressible as well as render caching in general, so the ratio of items that will benefit from compression should be higher as well as there just generally being a lot more stuff to cache and therefore space/memory being more of an issue.

Given this is something that can be enabled and disabled in settings.php, should we be adding the setting as a bit to memcache keys? That way changing it doesn't require a flush. Not sure what memcache does if it encounters compressed/uncompressed data when the setting is flipped.

I would just add something like "when changing this setting you need to empty the cache..." to the readme. It is not a setting that you change often.

RTBC + 1, let's get this committed

Given that we did not document changing it that much before, I'd suggest people should have an idea what they do when changing that setting.

In other words:

I do not think the key space we waste for storing the setting is worth the trouble of how less this will be changed in practice - especially if this sneakily is the default in memcache-3.0.3 anyway.

I have been following along, and had a couple of discussions about this too. I agree with the conclusions above. Going to commit this one. Thanks everyone for your input.