Re: Adding immutable_cache as a PECL (immutable PHP values/serializations in shared memory)
| From: | tyson andre | 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