Make it possible to use setOption to set Memcached::OPT_COMPRESSION_LEVEL which
was missed in the original zstd PR #539
zlib compression was using the default zlib compression level of 6. With this PR
it is now possible to choose other levels for zlib as well. The default remains
at 6 so nothing will change for people upgrading unless they explicitly set a
different level.
Here is some more benchmarking data using php serialized data
https://gist.github.com/rlerdorf/b9bae385446d5a30b65e6e241e34d0a8
fastlz is not really useful at any value size anymore. Anybody looking for
lightning quick compression and decompression should use zstd at level 1.
compression_level is not applied to fastlz because it only has 2 levels and
php-memcached already switches from level 1 to 2 automatically for values larger
than 65535 bytes. Forcing it to one or the other doesn't seem useful.
Add a configuration option to enforce an item size limit on the client side. This avoids sending large items
over the wire and getting rejected by the server which can cause delays. The default is 0 for no limit.
The same error code RES_E2BIG is used for the client side limit as for the server side limit.
This adds zstd compression support.
The current two options, zlib and fastlz is basically a choice between performance and compression ratio.
You would choose zlib if you are memory-bound and fastlz if you are cpu-bound. With zstd, you get the
performance of fastlz with the compression of zlib. And often it wins on both. See this benchmark I ran
on json files of varying sizes: https://gist.github.com/rlerdorf/788f3d0144f9c5514d8fee9477cbe787
Taking just a 40k json blob, we see that zstd at compression level 3 reduces it to 8862 bytes. Our current
zlib 1 gets worse compression at 10091 bytes and takes longer both to compress and decompress.
C Size ratio% C MB/s D MB/s SCORE Name File
8037 19.9 0.58 2130.89 0.08 zstd 22 file-39.54k-json
8204 20.3 31.85 2381.59 0.01 zstd 10 file-39.54k-json
8371 20.7 47.52 547.12 0.01 zlib 9 file-39.54k-json
8477 20.9 74.84 539.83 0.01 zlib 6 file-39.54k-json
8862 21.9 449.86 2130.89 0.01 zstd 3 file-39.54k-json
9171 22.7 554.62 2381.59 0.01 zstd 1 file-39.54k-json
10091 24.9 153.94 481.99 0.01 zlib 1 file-39.54k-json
10646 26.3 43.39 8097.40 0.01 lz4 16 file-39.54k-json
10658 26.3 72.30 8097.40 0.01 lz4 10 file-39.54k-json
13004 32.1 1396.10 6747.83 0.01 lz4 1 file-39.54k-json
13321 32.9 440.08 1306.03 0.01 fastlz 2 file-39.54k-json
14807 36.6 444.91 1156.77 0.01 fastlz 1 file-39.54k-json
15517 38.3 1190.79 4048.70 0.02 zstd -10 file-39.54k-json
The fact that decompression a dramatically faster with zstd is a win for most common memcache uses
since they tend to be read-heavy. The PR also adds a `memcache.compression_level` INI switch which
currently only applies to zstd compression. It could probably be made to also apply to zlib and fastlz.
It's wired that store commands would be auto-retry implicitly while the default value of store_retry_count was 2, as well as the timeout, would be 3 times in those store commands which may confuse users. IMHO, the retry should be set explicitly instead of implicitly.
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
Provides a new INI option to select the same consistent hash behavior as
older versions of php-memcached, to aid in migration from PHP 5.x to PHP
7.x. When `memcached_sess_consistent_hash_type` is set to `ketama` or
`ketama_weighted`, that sets either MEMCACHED_BEHAVIOR_KETAMA or
MEMCACHED_BEHAVIOR_KETAMA_WEIGHTED, respectively.
Resolves#344
This feature is fully supported in libmemcached 1.0.18 and higher,
but has a notable bug in the original implementation in libmemcached
versions 1.0.6 - 1.0.17 that the encryption key, once set, cannot be
changed otherwise all further get/set operations fail.
