Cache Functions Suggestions

[eluser]Lewis[/eluser]
[quote author="TheFuzzy0ne" date="1209489308"]Perhaps I am way out of my depth here, but please bear with me, and let me know if I have overstepped my boundaries.

Why not follow a process similar to this.

There can be a subdirectory within the cache directory - I will call it "tmp" for the sake of simplicity.

The cache class could check the tmp directory first, for the cache file it needs. If it's in there, then that file is rendered. If it's not, then the file is read from the cache directory.

A file is copied over to the tmp directory when the cache is being updated in the cache directory. Once the file has been cached in the cache directory, the file in the tmp directory can be deleted, so the cache is then pulled from the newly cached file.

The only problem I can see here is that there may be race conditions which need to be ironed out, but the idea is very simple, and I feel it can work. What's more, you don't even need to bother with locking the file that's being written to, as it's not even looked at so long as the copied file exists in the tmp directory. The cache file in the tmp directory is being read from and rendered even before the original file is written to, and continues to be read from until it's deleted shortly after the main cache file has been written.

Now I know you guys are a bunch of tech-heads, and I'm sure my idea is flawed somewhere, but in my mind, I can't see how. If that is the case, could someone please explain what I'm missing (or just tell me to shut up and go away).

Another suggestion would be to allow database caching as an alternative. I'm not sure how much more/less efficient it could be, but I am sure it's doable. Obviously, I'm not saying scrap the disk caching, but rather, it could be an alternative.

Thanks.[/quote]

Well actually, your solution is pretty good. It is essentially the same as the original one suggested and the one I back. Except instead of putting the file in a directory and moving it, you only really need to rename the file. I'm not sure if moving it would have much/any performance differences as renaming, but it means you have to have another folder chmoded so I'd say the rename is a slightly more elegant approach. But the theory was spot on, so well done!

Update: I will explain the main downside though, just so you know:

- If more than one person visits a site before a temporary cache file is generated, they will all generate their own versions and overwrite each other. This is not so much a problem, but having all those people regenerate the content means the cache is not in use and resource usage could go up if this happens in quick succession. With a flock the PHP script would wait until the last one is done, but it still would overwrite the cache anyway so you wouldn't get the users all using the resources at once, but they'd use them one after each other and plus you'd keep them waiting. So it's not so much of a downside as there's no real work-a-round for this.

@Lone, That will always happen with cache. The idea of cache is to cache static or semi-static data. A blog is a perfect example. Lets say you write an article and it gets Dugg. You have thousands of people visiting your blog at one time, and your blog software is working out the entry, what categories it's in, the name of the author, the sidebar etc. and chances are the output of this is going to be exactly the same for all these people visiting. Instead of regenerating it every time and using up all your server's resoures, you can simple save this generated version of it and keep serving up that for all these requests. Then you save all that extra overhead and your server doesn't die under all these requests. Data that is user-input dependant you just wouldn't cache as the chances are you'll never serve that exact same page enough times to make it worth while.