Clarification on apc.entries_hint runtime setting

[MichaIng]

I have a few questions about the apc.entries_hint, I hope its okay to ask them here, else advise me where to better ask them.

The technotes contain some words on it: https://github.com/krakjoe/apcu/blob/master/TECHNOTES.txt#L206-L207
And the PHP documentation: https://www.php.net/manual/en/apcu.configuration.php#ini.apcu.entries-hint
But I'm not sure whether I understand it correctly, probably those docs can be enhanced to give a better idea how to tune this setting.

This setting defines the number of pre-defined "slots" in a cache segment, right?

Since on our server with the default value 4096, the apc.php script cache entry list currently indicated ~17,500 entries, multiple entries can be in a single slot?

Do slots have a fixed size of (( apc.shm_size / apc.entries_hint )), a bid comparable to filesystem block sizes, or is it variable/dynamic? In case of a fixed size, large entries would then be stored in multiple slots.

I guess for optimisation, the value should moreless match the number of cache entries, or should it better match the maximum number of cache entries?

Can cache entries be denied when there are no empty slots available?

[nikic]

entires_hint is the number of hash table slots. Each slot contains a linked list of entries. As such, it's possible to have more than entries_hint total entries. It just means you may need to spend more time walking the linked list. It's good to match your actual utilization, but I don't think it's critical.

Cache entries can be denied if the entry cannot be allocated due to a fragmented cache, but this is unrelated to the number of slots.

[MichaIng]

Ah okay, so it is not related to the actual data size but an index. The downside of a (too) high value is, I guess memory usage (for the hashes) while a too lower number decreases access times?

Cache entries can be denied if the entry cannot be allocated due to a fragmented cache, but this is unrelated to the number of slots.

I recognised the first fact, and that I fail to avoid fragmentation with phpBB and Wordpress (making both use APCu for caching). It's 100% quickly and after a while larger files are not cached anymore. Luckily memory is currently not an issue and I can enhance the situation by increasing apc.shm_size notably. But that's off-topic.