Adding immutable_cache as a PECL (immutable PHP values/serializations in shared memory)
| From: | tyson andre | Date: | Sun, 13 Nov 2022 23:39:05 +0000 |
| Subject: | Adding immutable_cache as a PECL (immutable PHP values/serializations in shared memory) | ||
| Groups: | php.pecl.dev | ||
| Request: | Send a blank email to pecl-dev+get-17522@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
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?
Thanks,
- Tyson