view release on metacpan or  search on metacpan

lib/Cache/CacheFactory/Expiry/Size.pm  view on Meta::CPAN

on a regular basis depending on the value of C<auto_purge_interval>.

However, even with the most aggressive values of C<auto_purge_interval>
there will still be a best-case scenario of the cache entry being
written to the cache, taking it over C<max_size>, and the purge
then reducing the cache to or below C<max_size>. This is essentially
unavoidable since it's impossible to know the size an entry will
take in the cache until it has been written.

Also note that for each C<purge()> the cache will need to call
C<size()> once (or more if C<no_cache_cache_size_during_purge> is set),
which on most storage policies will involve inspecting
the size of every key in that namespace. Needless to say this can
be quite an expensive operation.

With these points in mind you may consider setting C<max_size> to
C<$NO_MAX_SIZE> and manually calling C<< $cache->limit_size( $size ) >>
periodically at a time that's under your control.

=item no_cache_cache_size_during_purge => 0 | 1

By default, to reduce the number of calls to C<< $storage->size() >>
during a purge, the size of the cache will be stored locally at
the start of a purge and estimated as keys are purged.

For the most part this is reasonable behaviour, however if the
estimated reduction from deleting a key is wrong (this "shouldn't
happen") the size estimate will be inaccurate and the cache will
either be overpurged or underpurged.

The other issue however is with shared caches, since there is no
locking during a purge, it's possible for another thread or process
to add or remove from the cache (or even C<purge()>), altering the
size of the cache during the purge, and this will not be noticed,
resulting in either an overpurge or an underpurge.

Neither of these cases will cause a problem for the majority of
applications (or even occur in the first place), however you can
disable this caching of C<size()> by setting
C<no_cache_cache_size_during_purge> to a true value
if it does cause you problems.

Please note however that this will mean that C<size()> will need
to be called when every key is inspected (not just removed!) for
pruning. Read the notes for C<max_size> above as this is likely to
have a dramatic performance degredation.

=item no_overrule_memorycache_size => 0 | 1

By default L<Cache::CacheFactory::Expiry::Size> will attempt a
workaround for the problems mentioned in "Memory cache inaccuracies"
in the L</"KNOWN ISSUES AND BUGS"> section.

If this behaviour is undesirable, supply a true value to the
C<no_overrule_memorycache_size> option.

=item no_devel_size => 0 | 1

If the above workaround is in effect it will attempt to use L<Devel::Size>
if it is available, since this module delves into the internals of perl
it can be fragile on perl version changes and you may wish to disable
it if this is causing you problems, to do that set the C<no_devel_size>
option to a true value.

=back

=head1 STORE OPTIONS

There are no per-key options for this policy.

=head1 METHODS

You shouldn't need to call any of these methods directly.

=over

=item $size = $policy->overrule_size( $storage );

This method is used to overrule the usual C<< $storage->size() >>
method when comparing against C<max_size>, it attempts to
analyze every object in the cache and sum their memory footprint
via C<< $policy->guestimate_size() >>.

By default this is used when trying to workaround issues with
the C<size()> method of L<Cache::MemoryCache>.

=item $size = $policy->guestimate_size( $data );

This method provides a rough (very rough sometimes) estimate of
the memory footprint of the data structure C<$data>.

This is used internally by the L<Cache::MemoryCache> workaround.

=item $boolean = $policy->using_devel_size();

Return true or false depending on whether this policy instance
will use Devel::Size in C<< $policy->guestimate_size() >>.

NOTE: this does not imply that C<< $policy->guestimate_size() >>
will itself be being used.

Mostly this is a debug method is so I can write saner regression
tests.

=item $policy->limit_size( $cache, $size );

Called by C<< $cache->limit_size() >>, this does a one-time prune
of the cache to C<$size> size or below.

=back

=head1 KNOWN ISSUES AND BUGS

=over

=item Memory cache inaccuracies

Due to the way that L<Cache::MemoryCache> and L<Cache::SharedMemoryCache>
implement the C<size()> method, the values returned do not actually
reflect the memory used by a cache entry, in fact it's likely to return
a somewhat arbitrary value linear to the number of entries in the cache