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.
Tests in the experimental/ folder were not executed on CI. The ones that work move up, the few
that remain in experimental/ need further investigation to get working or remove.
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.
The Windows SDK does not define `ssize_t`, so libmemcached does not
define `HAVE_SSIZE_T`. However, PHP's config.w32.h has
`#define ssize_t SSIZE_T`, so building memcached fails. We fix this by
defining `HAVE_SSIZE_T` via the extension's `CFLAGS`.
travis-ci.org builds have ceased, so this patch adds a GitHub Actions
workflow to build and test the extension, as well as a Dependabot
configuration file to keep the referenced actions up to date.
I've opted to slightly simplify the workflow compared to the Travis
build script. For one, I have not included libmemcached protocol
support, as most distros do not supply a libmemcached compiled with
server protocol support, and previous discussion suggests its usefulness
in the context of this extension may be limited.[1] I've also opted to
remove multiversion libmemcached testing in favor of using the system
libmemcached, as the referenced other versions seem to be old enough for
this to hopefully not be a problem. These could conceivably be
reintroduced if needed.
---
[1] https://github.com/php-memcached-dev/php-memcached/issues/418#issuecomment-449587972
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.
