Open remicollet opened 3 years ago
So the suggestion is to store compressed serialized data inside the apcu cache?
yes (even if performance will be lower), this is what is done when you use apc.serializer = lz4
yac have build-in copmpression by default
redis have support for configurable compressor
$ php --ri redis
...
Available serializers => php, json, igbinary, msgpack
Available compression => lzf, zstd, lz4
...
IMHO, compression make more sense for network cache than for fast local in memory cache.
I see some extension (brotli, lz4...) start to use it for compression
I looked up what apcu was doing because I noticed today that zstd (by the same compression library author) created a release today that also added support for storing the equivalent of \zstd_compress(\serialize($data))
for objects/arrays in apcu - https://pecl.php.net/package-info.php?package=zstd&version=0.10.0
(I haven't used that and my own use cases for apcu don't require much memory, and I don't plan to use it for my own use cases)
But if a use case was memory intensive it would help to use both a compression algorithm (possibly just for objects/arrays to get the speedup for reusing persistent strings) and igbinary/msgpack for the cpu speed and memory reduction - --enable-mycompressor-apcu-igbinary
and the module dependency is less than ideal for users or packagers of extensions.
For example, a site running on a single web server that uses apcu in a manner similar to using redis for a ephemeral cache in multiple servers, e.g. caching results from a database, storing rate limit objects (ip/user) entirely in APCu, etc.
This would also let apcu ignore the compression if the original data was too small or the compression ratio was too low.
APCu have a nice support for configurable serializer.
I see some extension (brotli, lz4...) start to use it for compression
IMHO serialization (struct to string) is very different from compression (string to string)
It could be nice to duplicate the mechanism for compression, and manage this properly
What do you think ?
Ping @kjdev