I am using the Yii framework for a site that will get a lot of hits (hopefully) because each client will be polling every 250 milliseconds. I want to limit the hits to my database and cache the data, but it needs to be close to real time (about 250 milliseconds). I noticed that the $expire parameter in CCache->set() takes an integer for seconds. I tried to go directly to apc_store() and found the same issue. Memcache seems to also define TTL in seconds.
Does anyone know of a PHP data cache that can work with TTL values less than 1 second or another workaround?
Redis has sub-second expiration. See https://github.com/antirez/redis/issues/169.
Related
Is it possible to modify the ttl (timeout) of an APC entry?
For example if I do
apc_store($cache_key, $productInfo, 100);
but within 100 seconds, I want to increase to 200. I want it to be 200 seconds from the original creation date, while maintaining a hit count.
My assumption is that this is possible because there is a last_modified time in the APC cache viewer, but I only know of apc_store.
I don't want to overwrite the entry with another apc_store as this will reset the hit count and creation date. So at time 0 if I did TTL of 100, at time 33 I would have to now make the TTL be a 167 if I wanted it to expire at time 200 (which is what going from 100 to 200 would do), this requires looking up a creation date and overwriting the data (not needed).
Looking for a solution that avoids those issues.
This is not possible unless you store the TTL as part of the data in the key and write your own logic, you will still have to overwrite the entry each time though.
Consider using Memcached instead and you can use touch to achieve this.
UPDATED
So I am running into another problem that I think is pretty much the same thing. I am using silex and I want the session to be stored for 5 days. I give the have the following values:
session.cookie_lifetime: 432000
session.gc_maxlifetime: 432000
session.gc_probability: 100
session.gc_divisor: 100
So from my understanding since probability and divisor are the same number, gc should happen every page load and the session file (using php native file handler for sessions) should be kept around for 432000 (60 * 60 * 24 * 5) seconds without any activity on them. This issue is even with these value, my session seems to expire between 1-2 hours of no activity.
I even tried seeting the gc_maxlifetime to 5 and that seemed to work fine so it makes me think something else is being triggered before gc_maxlifetime is.
Are there any other values I am missing?
The server decides when to clear up stale sessions.
This happens at certain times, depending on a random number and the chance you gave it (in php.ini).
Look for session.gc_divisor.
So in your situation, your cookie with the PHPSESSID is still there, and your browser sends it as it should to the server, but the server cannot find a corresponding session.
You also need to change a couple more variables in your php.ini
.check this link
I have implemented memcache in my PHP-MySQL based app and it gets updated regularly from a backend process.
Due to this some data is conflicting with the expiration time and other backend processes, so I came up with a solution but for that I would have to make the TTL = infinite.
Easy - just write 0 there.
expire
Expiration time of the item. If it's
equal to zero, the item will never
expire. You can also use Unix
timestamp or a number of seconds
starting from current time, but in the
latter case the number of seconds may
not exceed 2592000 (30 days).
You can set the TTL to 0, which means that it should 'never' expire.
But remember that it will never really be infinite. The data is stored in memory and will be lost under some circumstances, the most obvious being the server being rebooted. :)
You should always have the possibility to reconstruct that data when the memcache fails.
More details to be found here.
As far as I know, if you don't set a ttl, it will never expire.
However, there are replacing policies for keys, about which you can read here
I am trying to make a semi-realtime notification system sort of like on Facebook and for that I am looking forward to using long polling instead of mindless polling (polling every N seconds).
Yes, I am not using Apache, I am on Nginx which can handle this type of polling.
Now a question arose, all the tutorials I read about this subject matter of long polling show examples where the ajax request timeout in 30-50 seconds if no data is returned and then poll again, that made no sense to me because previously I used to poll the server every 30 seconds to check for notifications, how does the long polling make the situation any better? it will still be reconnecting every 30 - 50 seconds.
For that reason I considered that it might be an option to change max_execution_time from the default 60 to 300 or 400, then poll with a request that waits for at least 5 mins before timing out and reconnecting.
Can I expect any bad side effects of doing so? Is this approach flawed? Or is there a better approach?
Thank you.
The better approach would be using a backend optimized for tasks like that, e.g. node.js.
However, if you want to use PHP, there's no reason against raising the max execution time.
I'm caching tweets on my site (with 30 min expiration time). When the cache is empty, the first user to find out will repopulate it.
However, at that time the Twitter API may return a 200. In that case I'd like to prolong the previous data for another 30 mins. But the previous data will already be lost.
So instead I'd like to look into repopulating the cache, say, 5 minutes before expiration time so that I don't lose any date.
So how do I know the expiration time of an item when using php's memcache::get()?
Also, is there a better way of doing this?
In that case, isn't this the better logic?
If the cache is older than 30 minutes, attempt to pull from Twitter
If new data was successfully retrieved, overwrite the cache
Cache data for an indefinite amount of time (or much longer than you intend to cache anyway)
Note the last time the cache was updated (current time) in a separate key
Rinse, repeat
The point being, only replace the data with something new if you have it, don't let the old data be thrown away automatically.
don't store critical data in memcached. it guarantees nothing.
if you always need to get "latest good" cache - you need to store data at any persistent storage, such as database or flat file.
in this case if nothing found in cache - you do twitter api request. if it fails - you read data from persistent. and on another http request you will make same iteration one more time.
or you can put data from persistent into memcache with pretty shor lifetime. few minutes for example (1-5) to let twitter servers time to get healthy. and after it expired - repeat the request.
When you are putting your data into memcache - you are setting also how long the cache is valid. So theoretically you could also put the time when cache was created and/or when cache will expire. Later after fetching from cache you can always validate how much time left till cache will expire and decide what you want to do.
But letting cache to be repopulated on user visit can be still risky at some point - lets say if you would like to repopulate cache when it reaches ~5 min before expiration time - and suddenly there would be no visitors coming in last 6 minutes before cache expires - then cache will still expire and no one will cause it to be repopulated. If you want to be always sure that cache entry exists - you need to do checks periodically - for example - making a cronjob which does cache checks and fill-ups.