you should define different prefix for different site, for example, site 1: uses wp1_, site 2 uses: wp2_
I am referring to WordPress Multisite, not separate, individual WordPress installations. With WordPress Multisite/Network, I cannot add multiple prefixes like wp1_, wp2_, wp3_, etc.
Could you integrate a feature to automatically add IDs for Multisite?
yes, it’s a reasonable feature.
-
This reply was modified 1 week, 1 day ago by
flytomoon.
Thank you so much for creating such a fantastic plugin. I feel like my website loads faster than before. Thanks again.
You’re welcome — and thank you for the report.
1.4.0 is out, and it does exactly what you asked for: on multisite the cache prefix now automatically carries the current blog id, so each blog gets its own namespace and they no longer read each other’s entries. No more manual wp1_ / wp2_ per site.
One honest caveat: my own blog (laruence.com) is not a multisite, so I could only test this on a temporary multisite install. The implementation is straightforward, but I’d appreciate it if you could try 1.4.0 on your network and let me know whether the duplication issue is gone.
Thanks again for the feedback!
I set yac.values_memory_size to 100M, but I notice the statistics in the dashboard now show usage exceeding 100M; will this cause any issues?
Here is my wp-config setup:
define( ‘YAC_OCACHE_KEY_PREFIX’, ‘tut’ );
define( ‘YAC_OCACHE_EMPTY_TTL’, 21600 );
define( ‘YAC_OCACHE_DISABLE’, false );
hmm, don’t worry — this is most likely a bug in my stats/admin display logic, not in the cache itself. The admin panel statistics are computed from Yac::dump(), which scans all entries in the shared memory pool; the cache read/write path is not affected by this. I will review the stats code tomorrow and follow up here.
One more suggestion while you’re at it: set both yac.keys_memory_size and yac.values_memory_size to powers of two, e.g. 64M / 128M. Yac rounds the shared-memory segment sizes down to a power of two internally, so non-power-of-two values just waste the difference.
Thank you for the reminder; I will reinstall it.
I think I know why. One thing to confirm first: does your dashboard show Recycles above zero?
When the value pool fills up, Yac wraps around and overwrites it from the start. Entries whose blocks were overwritten stay in the slot table — a slot is only freed by a kick or a TTL expiry — so dump() still reports them, each carrying the size of a block that no longer exists. Summing those counts the same bytes twice.
So: a stats bug, not a cache bug. Nothing incorrect is served — Yac validates each block by CRC, so a recycled entry reads back as a plain miss, never stale data. Fixed on the plugin side; I’ll probably hold off on a release until I’ve accumulated a few more fixes, so this one won’t reach you in a version right away.
Your pool is genuinely full, so two suggestions:
- Lower yac.compress_threshold to 1024. Compression is already on by default at 4096; this makes 1K–4K values compress too. It’s PHP_INI_SYSTEM, so php.ini, not wp-config.php.
- Raise yac.values_memory_size. Recycles mean live entries are evicted early, so more memory buys real hit rate.
-
This reply was modified 1 week ago by
laruence.
Thank you. I’ll try adjusting the settings and wait for the new version; it feels faster than other Object Cache plugins.
Yes, benchmark says it is above 10x faster than apcu, 100x faster than memcached(local http). laruence/yac: Ultra-fast, lock-free shared-memory user-data cache for PHP 🙂
