Partner and Community Forums
Windows Cache Extension for PHP
User Cache TTL Not Working
Last post Feb 20, 2014 11:12 AM by DropPhone
Feb 18, 2014 02:22 PM|laurin1|LINK
I have a value in the cache right now, that should be expired. Here is the info value:
Array ( [total_cache_uptime] => 86440 [is_local_cache] => [total_item_count] => 118523 [total_hit_count] => 2906916 [total_miss_count] => 427072 [ucache_entries] => Array (  => Array (
[key_name] => Apps_Home::getLists [value_type] => string [value_size] => 881 [ttl_seconds] => 300 [age_seconds] => 20703 [hitcount] => 729 )
As you can see, age_seconds is WAY over the ttl_seconds value. Why it entry still being returned??
Feb 19, 2014 08:20 AM|laurin1|LINK
We cleared the cache (wincache_ucache_clear()), and put the value back and it's still not working:
Array ( [total_cache_uptime] => 46978 [is_local_cache] => [total_item_count] => 6629 [total_hit_count] => 813496 [total_miss_count] => 27906 [ucache_entries] => Array (  => Array (
[key_name] => Apps_Home::getLists [value_type] => string [value_size] => 881 [ttl_seconds] => 300 [age_seconds] => 843 [hitcount] => 10
) ) )
Feb 19, 2014 08:31 AM|laurin1|LINK
So is it possible that I'm mis-reading this? If the value is set again before the ttl expires, then age_seconds just keeps growing? That's fine if that is the case, but we have an issue with a value that is not being updated and this seems to be the problem.
Feb 19, 2014 08:42 AM|laurin1|LINK
No, it's definitely not expiring.
Feb 19, 2014 12:55 PM|DropPhone|LINK
Which version are you using? If you're using the latest-and-greatest from the dev directory on sourceforge, then I'm pretty sure I know why you're seeing this change in behavior.
When fixing Bug 65838 [Session unexpectedly expires], a fix was taken to calculate the expiration time as the difference between the "last used" and "now". Previously, it was calculated between "added" and "now". Calculating from "last used" seemed more
in-line with the existing comments in the code, as well providing the expected behavior (LRU cache).
I can now see that the place where this fix was made affects *all* of the Wincache caches (File, User, Session), each of which may have a different expectation of when items in the cache should expire. I have opened bug 66741 (https://bugs.php.net/bug.php?id=66741)
to track this issue. I can't give you an ETA for a fix at this moment.
Thank you for reporting the issue!
Feb 19, 2014 01:09 PM|laurin1|LINK
Hate to throw a wrinkle in this, but we are using the same version in development as we are in production (latest, as you indicated), however, we are not seeing this issue in development. This simple test works in development (expires after 20 seconds) and
fails in production:
6 //echo "Set: ".wincache_ucache_set("xxxx", 555, 20)."<br />";
Feb 19, 2014 01:13 PM|laurin1|LINK
This is a huge problem for us, I'm going to try a previous version.
Feb 19, 2014 01:16 PM|laurin1|LINK
The link to Wincache on SourceForge is not working!
Feb 19, 2014 01:20 PM|laurin1|LINK
I've got a 18.104.22.168 build from 07/11/2013. I guess I'll try that one.
Feb 19, 2014 04:06 PM|DropPhone|LINK
After looking at the docs on php.net, and looking through the source code, I believe the wincache.ttlmax (integer) setting is supposed to be calculating using the last used timestamp, and that bug fix 65838 is, in fact, the correct behavior. The documentation
integer Defines the maximum time to live (in seconds) for a cached entry
without being used. [emphasis added --E.] Setting it to 0 will disable the cache scavenger, so the cached entries will never be removed from the cache during the lifetime of the IIS worker process.
The ttlmax setting applies to all caches (File, User & Session).
I hate to say this, but if you need a more aggressive expiry on items in any of the caches, or any other kind of policy on cache expiry, that's up to the PHP application using Wincache.
Feb 19, 2014 04:36 PM|laurin1|LINK
I don't understand. Then what is the purpose of the ttl for wincache_ucache_set()? And why does this work fine in development? The documentation for wincache_ucache_set($key, $value, $ttl) states:
Time for the variable to live in the cache in seconds.
After the value specified in ttl has passed the stored variable will be deleted from the cache. This parameter takes a default value of
0 which means the variable will stay in the cache unless explicitly deleted by using
But the part in bold is not happening (at least not in production.)
Feb 19, 2014 05:37 PM|DropPhone|LINK
You're right! The docs say that wincache_ucache_set is supposed to behave like ttl is from creation.
Okay, so we're back to where we started the morning: The fix for 65838 has definitely broken user cache ttl. I can't give you an eta, but I'll get on that quickly.
Feb 19, 2014 06:16 PM|laurin1|LINK
And to confirm, we rolled production back to the version we discussed just now and the test I presented works in production.
Feb 20, 2014 11:12 AM|DropPhone|LINK
Fix is now available (after SourceForge finishes propagating):
Normal caveats apply: This is dev release, use at your own risk, no guarantees implied or conferred, etc., etc.
That said, it was just a two-line fix from the 22.214.171.124 version. I'll push the change to SVN in a bit.
Thank you, Laurin, for your patience and assistance in resolving this issue!