You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If APCu is used to permanently store individual config values, then the current behavior of respecting the TTLs makes sense, for predictability
If APCu is used in front of redis/memcached or a fast enough database/service/etc, then users should have a way to indicate that it's fine to evict keys to make room for new keys (it may make sense to prefer evicting keys with an older last accessed time, fewer hits vs time unit, etc)
(Aside: Internally, memcached always allows for early eviction, when I last checked)
This would also allow APCu to safely start being used as a short-lived cache in front of memcached in places that didn't use it that way before (though Fine-grained locking #337 may become a bottleneck if that results in many more calls to APCu and hundreds of CPU cores)
Example use cases:
If APCu is used to permanently store individual config values, then the current behavior of respecting the TTLs makes sense, for predictability
If APCu is used in front of redis/memcached or a fast enough database/service/etc, then users should have a way to indicate that it's fine to evict keys to make room for new keys (it may make sense to prefer evicting keys with an older last accessed time, fewer hits vs time unit, etc)
(Aside: Internally, memcached always allows for early eviction, when I last checked)
This would also allow APCu to safely start being used as a short-lived cache in front of memcached in places that didn't use it that way before (though Fine-grained locking #337 may become a bottleneck if that results in many more calls to APCu and hundreds of CPU cores)
Related to #369
The text was updated successfully, but these errors were encountered: