Welcome Guest, Not a member yet? Register   Sign In
Cache Functions Suggestions
#21

[eluser]Edemilson Lima[/eluser]
Code:
fwrite($fp, $expire.'TS--->'.$output);

Instead of putting the expire information inside the cached file, couldn't the expire be placed in the file modification time?
Code:
// after fclose($fp), put this:
touch($cache_path, $expire);
Then to get the expire time, just:
Code:
$expire = filemtime($cache_path);


By the way, could any expert here take a look into my suggestion below and make it happen? Smile

http://ellislab.com/forums/viewthread/69213/
#22

[eluser]Jared Farrish[/eluser]
This might be a radical solution, but why not a repository backend that offers atomic commits? It would introduce complexity at the write stage, but you could limit it to cache state only.
#23

[eluser]Jared Farrish[/eluser]
For instance, here is a documentation management system (Perforce) that uses RCS (from the GNU group) for file revisions (and to keep a constant state going for users):

Quote:[url="http://kb.perforce.com/UserTasks/ManagingFile..Changelists/UsingRcsKeywords"]http://kb.perforce.com/UserTasks/ManagingFile..Changelists/UsingRcsKeywords[/url]
#24

[eluser]Jumper[/eluser]
[quote author="Edemilson Lima" date="1205015017"]
Instead of putting the expire information inside the cached file, couldn't the expire be placed in the file modification time?
[/quote]
I've been thinking the same thing lately ! Can' someone from CI developers answer this ? why not just use filemtime() ?? I am sure it would boost performace greatly
#25

[eluser]Edemilson Lima[/eluser]
I heard that filemtime is not reliable, that some process in the server could touch the file and change it... I really don't know. This needs more investigation.
#26

[eluser]Paul Burdick[/eluser]
I recall that years ago that there were reports of problems with filemtime, but I cannot find anything about that now nor have experienced any problems myself in recent memory. Perhaps the biggest problem with filemtime() is that a great number of requests can happen in a second. My original idea to solve this problem was similar to this.

Eliot's last suggestion on page one is a helpful change and we were thinking of including it in the next version of CI. However, we want to try some other approaches (like the link above and Eliot's suggestion on page 2) with rigorous testing first before we put in a solution. Like Edemilson Lima says, this requires more investigation.
#27

[eluser]Jumper[/eluser]
The expensive process of
1. preg_match("/(\d+TS---&gtWink/", ..) and
2. str_replace($match['0'], '', $cache)
on each cache hit can be avoided easily with filemtime - so if there is no real problem with filemtime(), you should use it.

About file_get_contetns() and file_put_contents () - they should be used. They are much faster and file_put_contents() can be provided with "LOCK_EX" lock. (not to mention that php doesn't guarantee the fread($fp, filesize($filepath) would read the entire file in a single read, and I don't see any check in CI about the actual number of bytes read
#28

[eluser]Edemilson Lima[/eluser]
file_put_contents() is only available in PHP5.
#29

[eluser]Jumper[/eluser]
It can be implemented in 5, this is not an issue.
#30

[eluser]Macros[/eluser]
One note about filemtime... it's cached!

So you have to combine a clearstatcache before every request to filemtime.

Also, the lockfile method has a issue in that the (very) brief time between checking existence of the file and creating the file has the same problem with cache corruption.

Would opening the lock file with "w" and then checking that there is something in the file, if not then the lock file was created. Otherwise it was there beforehand. Then simply put a single character in the file & do your thing. The OS will lock the file for writing, so it shouldn't cause an issue... as far as I can see.

Macros.




Theme © iAndrew 2016 - Forum software by © MyBB