Re: Adding immutable_cache as a PECL (immutable PHP values/serializations in shared memory)

From: Date: Sat, 19 Nov 2022 14:36:59 +0000
Subject: Re: Adding immutable_cache as a PECL (immutable PHP values/serializations in shared memory)
References: 1  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-17523@lists.php.net to get a copy of this message
Hi, > I'd like to add > https://github.com/TysonAndre/immutable_cache-pecl#immutable_cache > as a PECL. > > This adds functionality similar to https://pecl.php.net/apcu , > but with immutable cache entries of immutable values (either the values themselves or an > immutable serialized copy of mutable values is stored in the shared memory region) > > - The API is > https://github.com/TysonAndre/immutable_cache-pecl#api-reference > - e.g. for a web server with hundreds of worker processes/threads, the entire pool would have > one anonymous singleton shared memory pool only used by > immutable_cache > - The mechanism used is pretty much the same as how opcache internally stores immutable values > (non-reference counted scalars, strings, arrays of immutable values) > > This provides a noticeable performance benefit (e.g. when caching config arrays or large > strings in userland), because: > - There's no copying out of shared memory needed for arrays/strings, unlike APCu, which > has to account for the possibility of full cache clears at any time. >   So it's constant time, and hundreds of times faster than APCu for large arrays (e.g. > 1000+ values) that have immutable representations > - It's easier to adopt fine-grained locks when cache clears are impossible by design. > - This allows reusing values if they're already found in > immutable_cache > > This also makes applications easier to reason about, since an end user would be certain that a > value added to the cache (or preloaded) would remain there (APCu clears the cache when it fills up > and on some other errors). > Applications could use immutable_cache for configs that are never meant to change until a > process group restart, static assets, > results of operations on fixed values, etc., and continue to use APCu for data with a short ttl > or for data that frequently changes. > > This has been an open feature request in APCu since 2016 > https://github.com/krakjoe/apcu/issues/175 and I've had that > problem (large configs that needed to be cached locally, that were generated by merging dozens of > config files, plus templating) > > - I asked about interest in PRs to add this a few weeks ago but didn't hear back > - > https://web.archive.org/web/20170608185145/https://blog.graphiq.com/500x-faster-caching-than-redis-memcache-apc-in-php-hhvm-dcd26e8447adó2; > ŸïÛŽ)§ToÜ describes a similar problem others have had and details about their workaround that give > background knowledge > - This functionality also seems much easier to package and distribute in a separate package, > regardless of which repo it ends up in >   (e.g. for end users or server admins to independently choose which of these to add from > public package repositories, PECL DLLs, etc) > > > Symbols, macros, configure options, and ini settings and supported ways of getting anonymous > shared memory > have been changed to avoid any naming conflicts with APCu that I can think of > (immutable_cache and APCu can be installed, configured, and used independently) > > Any objections? A reminder: I plan to add https://github.com/TysonAndre/immutable_cache-pecl#immutable_cache as a PECL if there are no objections. I plan to add this in 7 days. Thanks, - Tyson

« previous php.pecl.dev (#17523) next »